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).
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
- 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)
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
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.
SOA & BPM Partner Community
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.
Blog Twitter LinkedIn Facebook Wiki