By Juergenkress-Oracle on Aug 19, 2015
this article I will talk about my first conclusions and my point of
view regarding Microservice Architectures. As there is still quite a lot
of confusion and debate out there on this topic, I will try to describe
with my own words what Microservice Architecture is, how does it differ
from typical Service Oriented Architectures (SOA) and what design
principles and practices governs it.
What is a Microservice Architecture?
In the article http://martinfowler.com/articles/microservices.html written by Fowler and Lewis, Microservice Architecture is described as following::
Microservice architectural style is an approach to developing a single application as a suite of small services, each running in its own process and communicating with lightweight mechanisms, often an HTTP resource API. These services are built around business capabilities and independently deployable by fully automated deployment machinery. There is a bare minimum of centralized management of these services, which may be written in different programming languages and use different data storage technologies
article overall it’s a fantastic piece of work (really suggest you read
it). The way Microservice Architectures it’s defined opens up a few
pandora boxes (in a good way I think) which I will talk about
First of all, if you are familiar with SOA and it’s guiding principles this will seem very familiar (read for example: http://en.wikipedia.org/wiki/Service-oriented_architecture or http://www.soa-manifesto.org/). Yet, if you noticed the highlighted texts, it’s not quite the same as what we are used to in traditional SOA. The truth is, wether we accept it or not, SOA architectures evolved around the adoption of certain design patterns (such as Enterprise Service Bus (ESB), canonical schemas, centralised contracts, -see http://www.soapatterns.org/ for more) and the use of SOA specific infrastructures to build and deploy services and APIs became the approach of choice (note that the service vs API topic it’s not discussed in this post. For my view on this read http://www.soa4u.co.uk/2013/09/restful-is-also-soa.html).
From my perspective, I would define Microservice Architecture’s as both 1) a design pattern and 2) a discipline for delivering services and APIs. To elaborate further based on my conclusions I can highlight the following guiding principles:
- Delivering business focused and lightweight services/APIs that are truly design, built, deployed and executed independently of each other (meaning that in terms of infrastructure dependencies, they share very little)
- Strong focus on people collaboration and communication as the main mechanism in the adoption of best practices and standards rather than common set of strict guidelines and standards that constraint the way services are define, built, deployed and maintained
- DevOps (config management, deployment automation, CI, Continuous Delivery) as a fundamental building block rather than a value add
- Scalability should be easy as services are very lightweight and stateless (The same service can run in many servers and DevOps makes the deployment process automatic and easy)
- Doesn’t encourages the use of monoliths to deploy services (a monolith is for example an application server or an ESB). Services should run almost as demons
One can argue that SOA architectures can also satisfy the listed requirements as SOA it’s really an architecture paradigm that can be realised in different ways. I personally think this myself and I would regard Microservice Architecture as a SOA design pattern, however as per my previous point, comparing it with traditional SOA architecture’s there is a difference.
Microservices vs SOA Read the complete article here.
For regular information on Oracle SOA Suite become a member in the SOA & BPM Partner Community for registration please visit www.oracle.com/goto/emea/soa (OPN account required) If you need support with your account please contact the Oracle Partner Business Center.