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. Read the complete article here.
For regular information become a member in the WebLogic Partner Community please visit: http://www.oracle.com/partners/goto/wls-emea ( OPN account required). If you need support with your account please contact the Oracle Partner Business Center.