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:


Microservices Vs SOA System Layers
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.

DevOps Tools
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.

ESB based SOA
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.


Coexistance of SOA and MIcroservices
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.
Microservices for IoT
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.
Microservices Bus
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 :)

Comments

  1. Luis I like your article and agree with your conclusion. What is interesting is that I can see how Microservices help businesses achieve a "fail fast" approach without impacting the current set of services within the enterprise. Following on from this though comes a questions, when or should a Microservice or set of microservices become a SOA service exposed on an ESB?

    ReplyDelete
  2. Andy, nice to hear you liked the article!! :). Answering your question, my view is that you define a system boundary, for example a web application. The UI of the application, middletier (i.e. the microservice) and backend, they all can be within the system boundary. I don't see the need to stick an ESB between the the UI and the API. In fact as per Fowler's and Lewes's article, these 3 components should actually be part not only of the same Microservice boundary (basically inside the system boundary) but also the teams delivering it should be one not 3 (a team per tier) hence avoiding Conway's law..... Now, this self-contained system, will have to interact with other systems (i.e. Legacy, ERP's, etc) and here is where I see ESB adding more value.

    Another example is in IoT. You may have several devices talking to each other (choreographed communication) thru interfaces such as CoAP, MQTT or AMQP. However IoT to really be IoT the device really has to take part in a broader business process and therefore other sets of systems, so either if it's to gather information from the device (pull), an event triggered by the device by a sensor (a callout form the device), or a push made to the device, the bottom line is that implementing an ESB pattern will make it a lot easier for the device to interact with backend systems (specially when these can be onpremise, on the cloud or both). Note that in this use case, you will need an API gateway to front the ESB to ensure there is enough security (authn, authz, integrity and confidentiality).

    The bottomline is we now that ESB pattern adds value when use correctly, but when not, can be a nightmare. In some of these use cases Microservice Architecture pattern will make things easier. Nor are silver bullets, it will be down to us to deliver hybrid architectures that combine the right patterns for the right use cases that deliver the best benefits for the business!!

    ReplyDelete
  3. Soa vs microservice

    Interesting article. Nice to see some clear thinking in amongst the microservice are the way cool new thing in town that my twitter timeline us full of...!

    My team are in the process of building something that owes a lot to a microservice style of architecture, and I'm already seeing a plethora of point to point interfaces starting to emerge that my gut tells me should be being orchestrated by something ESB-like - where the line is drawn that says "all interactions via an ESB" and "this is an api exposed via an api gateway" is something I struggle with - what's your view?

    Also - I really struggle with the "every microservice has its own data store" - my natural inclination is to reduce the number of databases and consolidate onto a small number of systems of record with well defined masters of the truth... However the microservice approach suggests that I should split up my data and have sync processes between the data stores that duplicate data... Again, I'd be interested in your experience in this...

    Thanks again.

    ReplyDelete
    Replies
    1. Dave,

      The challenges you're describing are exactly the type of issues I expect will occur more and more and exactly why I explicitly said that "Microservices Architecture is not a silver bullet" as it's not really solving the applications integration challenges, in fact if enough thinking it's not put into its implementation (as you highlighted) one might end up with tons of Microservices and databases and probably having to integrate them via traditional data integration techniques and tools (i.e. ETL or ELT tools) which in my view is going backwards not forward... I don't want that... I want to move away from batch style integration or data replication as that's against the digital vision where all systems interoperate via a flexible integration stack that supports event driven integrations, choreography and or choreography when applicable, decoupled and independent services and that can be composed and presented in multiple formats (i.e. REST, COAP, SOAP, AMQP, MQTT, etc etc)

      So my answer to your question, based on what I think, not necessarily what the mainstream is doing:

      1) Make sure you define system boundaries. A system can be either a COTS system, bespoke or legacy. By bespoke I mean a system build from scratch following any architectural style, for example Microservices (in this case you will have different independent services with its DBs). Each system boundary will have its own multi-disciplinary team

      2) Each system should expose standard APIs of key functionality. The APIs should provide access to events, data objects with standard CRUDS. If a system was built with Microservices architectural style then these will be REST URLs (with its supporting RAMLs, WADLS, Swaggers or documentation), if web services then WSDLs

      3) Until a suitable alternative to an ESB and its transformation, enrichment, orchestration and routing capabilities is out there, inter-system integration should be made via the ESB. You may opt for patterns like canonical schemas, centralised schemas, boundedContext, and so when implementing the service bus. There are pros/cons on these

      4) I would implement robust API management/SOA Governance tools and ensure all developers use it. Purpose is to: a) ensure there is visibility of all APIs out there, its functionality, owners, communities, versions, features, to promote reuse not reinvent. b) Dependencies between services and APIs is understood. c) APIs and services are link to its relevant documentation. d) Management of communities / users of APIs. e) metering and/or monetisation if applicable

      5) Implement real DevOps targeting continous delivery (not only for microservice APIs but for all services and standard APIs)

      6) If you don't like proliferating small databases, note that Microservices is an evolving paradigm and part of what it promotes is loose governance enforced by strong communication between teams rather than documents defining the "way you have to do it". You can realise this pattern in different ways I think, but the key thing here is remove dependency in monoliths. At the end of the day if you put all eegs in one basket and the basket breaks.... what then?

      Delete

Post a Comment