Undeniably, microservices is an extremely hot term. A bandwagon almost every product team at Oracle seems eager to be jumping on to. It is hard to give a concise and objective definition of what microservices are. Through microservices, organizations try to achieve more agility, quicker and more reliable application development and delivery at scale. This is especially relevant for the systems of innovation – where change in functionality and scale is the main constant – as opposed to systems of record that run the existing business operations and do not require that same breakneck pace of change.
Microservices are standalone components with a single responsibility, owned by a single team and can be built, tested, deployed and scaled on their own. They are stateless – although they certainly can use a data store for their own data. Ideally, communication between microservices is done as decoupled as can be: through events or at least through asynchronous calls routed through proxy endpoints.
Microservices are products, not projects – they have a life cycle but not a project end date. Teams are small, can own multiple microservices and not only build them but also run them: full responsibility for Dev & Ops, through the entire lifecycle of the microservice. Teams are very independent as well: for example enterprise wide canonical models and a central corporate database are very much not part of the philosophy, and at least some leeway in making technology decisions and certainly to pick development tools is required. Standardizing is very useful on mechanisms for common tasks such as defining and cataloging APIs, doing source code control and handling incoming requests and inter-service communication.
To make microservices work – a lot of automation is required, around build, test (if nothing else then at least regression testing) , delivery, scaling and monitoring. In a microservice, there is no clear distinction between the custom built functionality and custom configured platform components – whether you reuse or buy or build the pieces that together make up the microservice is irrelevant. The team that assembles the microservice in its box has ownership of the entire box.
Very valuable are the slides from the presentation by Luis Weir (Oracle ACE Director, CapGemini) and Robert Wunderlich (Senior Principal Product Management at Oracle Corporation) at Oracle OpenWorld 2016.This next figure was taken from this presentation. It visualizes the operating model for a microservices architecture – showing many of the aspects discussed overhead:
The format of the microservice box is frequently a container – especially a Docker container – that contains all required pieces to run and manage the microservice. The container can easily be imported into a container management system where it can be configured – wired up to its dependencies, exposing its entry points, feeding its logging and runtime metrics – and dynamically scaled. Instead of a Docker container, the microservice box format can also be VM or even a self-contained self-describing application running in a standardized application container such as a Java EE server. Note that the more the microservice has to rely on its runtime environment, the higher the risk of configuration drift across the many instances of that environment. To mitigate that risk, a very high degree of automation in provisioning and managing these environments would be crucial.
More on Microservices and their importance in this article by my colleague Lykle Thijssen.
Oracle and Microservices
Oracle does not offer a service called Microservice CS per se. However, several Oracle cloud services are poised to help establish a microservices architecture and way of working; two slides testifying to that effect:
- the soon to be released Container Cloud Service runs Docker images and provides automated service discovery, scaling, monitoring and management of the microservices running through Docker containers. This article on our blog discusses the Oracle Container Cloud Service. Of course organizations can run any form of containerization or virtualization on top of Oracle Cloud Compute services – as shown below. The Container CS provides the infrastructure to run and manage Docker containers. The Application Container CS finally runs applications (and uses Docker under the covers to do so).
- the Application Container CS (ACCS) provides a standardized runtime environment into which self-contained applications can be deployed. Applications built in Java SE, Node.js or PHP – and soon also Java EE, Ruby, Python and Go – can be packaged with a little metadata and run on ACCS. Binding to Oracle cloud services such as DBaaS, MySQL CS and Messaging CS is provided. ACCS provides automated scaling (up and down) based for example on traffic volume or response times and provides load balancing across instances.
ACCS can manage multiple mutually related applications in a stack – for template based, easier management for example of scaling. The roadmap for ACCS includes a Data Cache and NoSQL CS integration, leveraging the new Identity CS, support for A/B testing and integration with Management CS for Application Performance Monitoring and Log Analytics. High availability and zero down time deployments and other management operations are also part of the short term focus. Read my article on ACCS for more details and some pictures. The next figure shows the main themes on the near term roadmap for ACCS:
- Oracle Functions – a new, very low-key announced cloud service for running server less operations, triggered for example by direct API calls, Messaging CS requests, Database events, WebHooks and the Kafka Event Hub – provide another stateless and auto scaling implementation of microservices ; see this article for more details on these Functions.
- the Developer CS supports agile team collaboration around software development as well as automated, continuous build and delivery, including testing, and automated building of Docker container images and pushing them to the Container Cloud Service registry; Developer CS can also deploy applications to Application Container CS. This article will introduce you to [the current state of] Developer CS.
- WebLogic Server and its cloud based equivalent JCS have the concept of partitions, somewhat wistfully dubbed ‘microcontainer’, that can be used as a deployment vehicle as well as a management and scalability unit for Java EE applications including their compete application server configuration – and as such can be seen as a box format for microservices using a standardized WebLogic Server as their runtime host environment
- the API Platform CS can publish – perhaps gathered through auto-discovery – the public API details for microservices and front these services with a gateway that can do smart routing, authorization, metering traffic monitoring and logging and decouple consumers from implementation details; my previous article discusses the API Platform CS in some detail.
- the Messaging CS and the newly announced Apache Kafka-based Event Bus provide a communication backbone that microservices can leverage for decoupled interaction
- the DBaaS, MySQL CS and NoSQL CS as well as the Storage CS can be used from microservices to handle the persistent business data – and the newly announced Data Cache and Data Grid PaaS infrastructure facilities provide faster memory based data save and retrieve
- Support for microservices – the architecture principles, the automation of build, deploy, scale tasks, the decoupled interaction – is announced for Java EE 8 and especially Java EE 9, although it yet has to be decided what this support will entail.
Luis Weir and Robert Wunderlich outlined what they called the SOA 2.0 architecture – with traditional SOA (fairly monolithic, associated with the Systems of Record) and microservices, primarily for Systems of Innovation.
They mapped this SOA 2.0 architecture to the Oracle Public Cloud services like this:
Download the AMIS OOW16 Highlights for an overview of announcements at OOW16.
