A Word About Microservice Architectures and SOA

In 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

The 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 subsequently.
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
To make my point more clearer, I created the following diagram to compare the system layers in a traditional SOA infrastructure to a Microservice one:

As it’s visible in the diagram, there are many similarities between the two, however there are three key differences, two of which are very obvious but one that is not  (there are more that you can deduce from the digram and all the links I’ve provided):

• First of all, traditional SOA implementations have been built around the use of monoliths ( or as Microservices calls it: Monolithic Architecture pattern -read http://microservices.io/patterns/monolithic.html)
• In a Microservice Architecture on the other hand, services and APIs are built and deployed without almost any dependency on an underlying application server or application. This means that services run as processes of the OS and share very little in terms of underpinning application infrastructure. This is because in Microservices (as per the highlighted text in Fowler’s / Lewis's definition) services and APIs should ideally run independent from each other. Another good article for this is http://microservices.io/patterns/microservices.html
• The third one -not obvious, is around composition of services. Traditional SOA promotes the use of orchestration (i.e. BPEL) whereas Microservices encourages the use of choreography. The fundamental difference here is that in Orchestration you need an “orchestra director” that defines and manages the interaction logic between all services (basically the BPEL code that executes or even in SOA composites, the SCA file like composites.xml that dictates at runtime how components interact). Choreography is different. Is a design time mechanism to model service interactions and behaviours but then once a service is built and deployed they should “know what to do”. Think of it as a protocol. A good analogy: "Dancers dance following a global scenario without a single point of control" (http://en.wikipedia.org/wiki/Service_choreography)

The following forum thread also provides a good point of view on the commonalities and differences of the two http://stackoverflow.com/questions/25501098/difference-between-microservices-architecture-and-soa
Now that I’ve described some of the key differences, I want to make it more obvious by showing a piece of code for a service built following the Microservice Architecture pattern. The snipped is based on Node.JS (https://nodejs.org/)  Express (a lightweight app for Node -http://expressjs.com/). Do note that Microservices can b built in any technology (i.e. Java) so long that the guiding principles are adhered to. 

var express = require('express');

 

var app = express();

 

app.get('/wines', function(req, res) {

   res.send([{name:'wine1'}, {name:'wine2'}]);

});

app.get('/wines/:id', function(req, res) {

   res.send({id:req.params.id, name: "The Name", description: "description"});

});

 

app.listen(3000);

console.log('Listening on port 3000...');

(full example on http://coenraets.org/blog/2012/10/creating-a-rest-api-using-node-js-express-and-mongodb/)
As it’s visible, this simple REST API is fully self-contained. It not only defines the resources that the API will provide and the HTTP verbs to use, but also defines the port the API will listen to. This basically means that this API will be self-contained and running in it’s own process. Fascinating isn’t it?
In regards to people, Microservice Architectures encourages the creation of multi-disiplinary teams that are organised around the capabilities that specific micro services will support, rather than creating different teams based upon for example the different technologies and layers involved in the creation of a single microservice. As per Conway’s law, the systems you build will be a reflection the organisation and communications structures you followed ( I’ve about this in http://www.soa4u.co.uk/2013/11/9-tips-for-organizational-maturity-in.html). In addition it is encouraged to have strong communication and collaboration mechanisms as this becomes the preferred way to share best practices and standard documents written ages go and available in somewhere in a forgotten content management system.
Furthermore DevOps/Contionus Delivery in Microservices really is a must-do rather than a value add. At the end of the day, DevOps main objective is to bridge the gap between development and operations team therefore delivering high degree of agility into the main software development lifecycle (SDLC) stages. For automation aspects of DevOps, below a nice diagram that can serve as inspiration on what tools can be used for each phase.


Microservice Architecture is NOT a silver bullet! - ESBs are still needed
I personally think ESB’s still have a role to play to bridge application integration gaps in large enterprises as “choreography” alone all become streamy challenging in such large landscapes. The need for a robust tool to handle message routing, complex transformation, enrichment, throttling, and virtualisation tasks is still very valid and needed. The truth is that large organisations have many systems, many of which are commercial of the shelf (COTS), others are legacy, and others bespoke. Solving this integration challenge its not an easy tasks and a combination of technologies and architectural approaches is usually needed.


I can see this same issue occurring with Microservices as inevitably the number of microservices will grow exponentially and without a doubt governance will become challenging. This is the reason why SOA Governance and API management tools exist. it is one choice to define the right governance model (strict or lose). Also common problems such as visibility, lack or reusability, dependency management, amongst other will still be there in micro services. Therefore leveraging SOA governance and API management tools such as service and API catalogs and enterprise repositories will add a lot of value in they will help solve some of the common governance challenges.
I personally think that Microservice Architectures add most value when use for the right use case. For example, to build systems and applications with a very well define system boundary. Not necessarily to address all of the integration needs in an organisation. In other words, I don’t think Microservice Architecture is a silver bullet. I see it as another very good pattern that can be used when it applies, but as everything if overuse, challenges will come for sure.

Another excellent use case where Microservice Architectures can apply nicely is around Internet of Things (IoT) and Machine to Machine (M2M). This is because by default devices are constrained by default on it’s hardware capacity and although at the moment focused is mainly in sensors, there is a lot of value in also having devices expose functionality and data via lightweight APIs (using protocols like MQTT or AMQP). This will allow devices to either interact amongst them (and this can be modelled using choreography languages like WS-CDL for example) or take part in a broader IoT ecosystem where the device can take part in a broader business process.

Conclusions
I definitely see a lot of benefits and value adds in Microservice Architectures. I like the fact that there is very clear boundary between services not only logically but also physically. I never liked the fact that if an ESB goes down all services running in it also get affected…For this reason I think that major SOA and ESB’s vendors will embrace the Microservice Architectures way and might end up extending existing tools somehow to support or partly support this paradigm  or creating additional tools into their suites to support the creation of micro services.

Finally I think that some of the forgotten specifications such as WS-CDL (http://www.w3.org/TR/ws-cdl-10/) will get traction again as they do have a role to play in the Microservices world, or at least that is what I would like to think.

Hope you enjoyed the article :)