Much has been talked about Microservices in recent times and invariably that discussion ends up becoming a discussion of “how it is different from traditional SoA”?
Many have touted Microservices as being “SoA done the right way”. Some say “SoA is for enterprise-scale where as Microservices apply at application-scale”, where as some in a very agitated tone would say “What’s new? Isn’t that exactly what we’ve been doing for over a decade now?

Well, in my opinion – the two really aren’t very different – One can be seen as a natural progression of the other in terms of technological evolution and advancement. For the record – There’s absolutely NOTHING that Microservice architecture talks about, that is either contrary to, or different than what SoA said, many years ago!

Both essentially are just to do with breaking down application functionality into smaller functions known as services, that are independent of each other, such that they are agnostic to the technology in which they are implemented, and they could be invoked in a technology-agnostic, open-standards way.

Ok, so then what’s different?

Interpretation! As with most successful, ground-breaking ideologies, there is always an element of “grey” involved that leaves behind some open-ended-ness that can vary depending on one’s own interpretation of that ideology. Hence the varying implementations that give us different flavours of SoA – be it Microservices, be it ESB, or be it something as simple as Service Orchestration.

Firstly, when we talk about smaller functions, the obvious question that arises is – how small?
Is Microservices really meant to break it down to a level, any smaller than what SoA did?
SoA always talked about service granularity as being a key factor in designing effective service oriented architectures. There was always a tradeoff  between designing fine grained services to enhance reuse vs. designing coarse-grained services as a means to improve performance by eliminating multiple back-and-forth trips over the network. And seldom people got this right.
On the other hand, Microservices definitely does not imply that we break it down to a micro-level functionality, although the name might suggest so. And I have seen instances where teams have taken this term literally and gone ahead and broken down functionality into actual micro-sized services – which eventually led to performance issues – but that’s just an incorrect implementation of Microservices.
But, keeping these examples of “incorrect” implementations aside – both SoA and Microservices are very much aligned in this aspect of granularity. There is never a black-and-white answer for this, and the only correct answer here is “it depends”. We have to take the context of the business functionality into consideration and define your service boundaries around it – irrespective of whether you are a SoA fan or a Microservices guru. 

Another area open to interpretation is the notion of “breaking down” – what exactly do we mean by breaking down application functionality – and this is probably one area where, I think Microservices leverages the evolution of technology in the area of Cloud and DevOps, and applies that to the more traditional SoA approach to create a different flavour of it – and that to me, is THE only difference between the two.
SoA never really got into the specifics of this and most implementations assumed that there has to be a logical breaking down of functionality rather than more of a physical breaking down. But Microservices very clearly involves a physical isolation of these services – packaged and deployed separately onto different servers.
Now, To have an un-biassed discussion on this, it is important to take the “time” aspect into consideration. And it is only fair to realise that over a decade ago, we never had the liberty of spinning out servers at the click of a button – thanks to DevOps and Cloud, that is very much a reality today. Not surprising then, that in those days, physical separation would not have been that feasible given it would take months to get a new server into production. The natural choice was thus to build a monolithic deployment that would just scale by replicating that deployment onto multiple servers as a replica.
However, in today’s era of virtual servers, we can easily break the services down into separate physical packages that can be deployed separately on individual servers – and we now have the ability to scale specific modules that may be more critical, at runtime! Hence it is very natural for us to leverage this benefit and to tie this into SoA.
Note that SoA in the first place, was never against the notion of physical isolation. It’s just that the implementation in those days, seemed to take the path of logical isolation – just because that seemed more practical then.
Having said that, I worked for a customer almost 8 years ago (when Microservices did not exist), but even then we had implemented this physical isolation very much under the pretext of SoA!
So, you can argue it’s only an appetite for degree of complexity in terms of implementation more than anything else – and it is the technology advancements that help us cross this bridge of complexity rather easily today, than it was yesterday.

Anyway, coming back to the original question… is Microservices any different from SoA??? – I’ll give you this example and then leave it for you to decide.

The car has been around for years. When it was first invented, it ran only on coal dust as the fuel. As fuel technology evolved, we saw cars coming out with diesel and petrol engines – (or gasoline for my American friends)… but that was STILL A CAR. More recently, we see CNG and LPG being used as fuel and the latest innovation being cars that run on electricity. But end of the day, THEY ARE ALL CARS, that have evolved by leveraging the technology innovations in energy domain.

Similarly, Microservices leverages the technology innovations in cloud and DevOps areas, but it is essentially still SoA – Now, does that technology leverage qualify for a new hype? A new jargon?

Hype or not! Jargon or not! End of the day, how does it matter? As long as we understand the nuances and that helps us architect the right solutions to the right problems – it’s happy day!

And to help us make those right decisions, it is important to highlight some of the “merits” and “gotchas” that would enable us making these decisions –

  1. Physical breaking down of the application allows us utmost control in terms of our ability to scale specific modules of the application that are more in demand.
  2. It requires a lot more detailed understanding of the business context and domain model early on in the project lifecycle, because it’s a lot more difficult to refactor and reorganise the application structure once it has been physical decomposed into isolated deployments.
  3. It gives seemingly more “availability” for your system – when one service goes down or needs to be restarted, other services can continue to process requests hence improving the overall availability at the application level. 

Both topics are far more involved and deep-rooted for me to cover adequately in this one blog, but I would encourage avid readers to follow link below to Martin Fowler’s very interesting take on this subject –