This is unsurprising, because it’s rooted in fact. For all of its other faults, SOA was a vision of enterprises that looks remarkably like what progressive organizations are building today with cloud native architectures composed of, among other things, microservices. Stripped to its core, SOA was the idea that architectures should be composed of services rather than monolithic applications.
Popular as that vision is today, however, SOA was from the start an uphill battle. It gained hype and currency, which in turn led inevitably to furious messaging and branding pivots, but even in an industry which tends towards the ephemeral SOA’s moment in the sun by the standards of technologies that preceded it comparatively brief.
If SOA and microservices have at least some common ground from a functional perspective, then, why was the former rejected and the latter embraced?
Many would point to size as the critical differentiator. Services as described by SOA were insufficiently granular, it’s been argued, and therefore difficult to build and harder to manage. Setting aside the obvious fact that this glosses over the management overhead associated with taking large services and breaking them up into large numbers of smaller alternatives, it also misses the far more critical distinction: SOA was primarily a vendor led phenomenon, microservices is by contrast largely being driven from the bottom up.
Given the success of platforms such as AWS, it’s difficult to make the argument that service driven platforms are not an effective way of building platforms that scale or that they’re not the dominant approach at present. But notably, service-based platforms are generally developer constructs at present. The SOA-driven world originally envisioned by large vendors, one in which services were built out upon a byzantine framework of complex (and frequently political) “standards” never came to pass for the simple reason that developers wanted no part of it.
To be sure, microservices has benefitted from the lessons learned by various SOA practitioners, and indeed the effort to popularize and socialize the latter term has simplified the adoption of the former. But the most important takeaway from SOA was arguably that developers would play a decisive – and in many cases, deciding – role on what would get used and what would not. Microservices are easier for them to develop than monolithic alternatives, and come without the vendor standards baggage of SOA, which is why even if it’s still outpaced by SOA on a volume basis its trajectory looks a lot more positive.
Too often in this industry we look for explanations for success or failure based on technology or function, while the real causative factors for success or failure are much simpler: do those would make kings want to use it, or not?
IMHO, microservices is subset of SOA.
SOA intent is to provide reusable services for service consumers. From service consumer perspective microservice looks exactly the same way.
So, microservice is fine grained SOA with ability of independent (well.. more independent) deployment and scalability of particular services. Over time that approach yielded big amount of toolsets, framework, approaches and practices, but conceptually microservice is still SOA.
Good article. So as for me one of the main issues in SOA is that it is build to serve enterprise. So if you want to make SOA you need to use some vendors SOA suites, like Oracle, etc. In microservices you can take various things put them here and there and it will work. For real SOA (SOA 2.0) it is more likely you will spend 2-3 weeks on setup ESB, and some other things around. Unlikely microservices allows you to skip some requirements and restrictions that should be guaranteed in SOA as SLA. So I would say that microservices is a very light version of SOA with various things that can be skiped by developers or ignored.
Hadn’t realised this before but as soon as I read the title I realised ithe truth of it.
Though I’d like to suggest that advances in simplicity of deployment and management which the cloud has brought as played a significant role in the adoption of microservices. In the past spinning up a new “node” was a laborious task – with vendor lockin as you point out – so developers were forced into building monoliths. Now that barrier has been removed, it has enabled the microservice to become viable.
The forward SOA thinkers I worked with long ago thought in terms of primitives, not SOA-enabled APIs of enterprise apps.
SAP consultants have made a 10 year career out of simplifying SOA-enabled functions in SAP ERP.
I agree with you of the benefits of this being adopted by developers rather than application vendors.
I believe that problem with traditional SOA was the roadmap fron ideation to industry implementation, bad innovation management, I believe nowaday the change management is more madure that 10 year ago, the standars as SOA- RA, and the implementation and commercialization of IBM, Oracle, inclusive service level WSO2 had found a resistence in organizational changing management. It not is happening with microservices because is lightweight and agile.
I totally agree. I think the view on developers and their importance for the company success changed massively over the last years, which is really great thing for everybody.
the current trend of microservices as shown in your graph very closely matches the left hand side of the SOA hype curve. I guess time will tell in terms of when this hype curve flattens out and then plummets.
Hi Stephen, thank your for this article. In general I agree with your vision but, honestly, I never seen any contradiction in viewing microservices as an evolution of SOA. Indeed, I think that such an idea is not completely wrong. If we just take into consideration the main principles which govern service oriented computing, there are no so many differences between SOA and Microservices.
The real difference, as you point out, is that you can program microservices but you can only design SOA. This is a very big difference from an engineering point of view and this is the reason why microservices were born from the bottom and SOA are governed from the top.
But the main point here is that both of them are exploiting the service oriented paradigm. So where is the real difference? In my personal opinion the main difference between them is the cloud computing: the computational support. When SOA were conceived, cloud computing did not actually exist. They were born for integrating systems which was a need for those companies which had to deal with complex systems populated by several vertical applications. This was the ground of SOA. Now, there is the cloud which is the new ground for service oriented applications. Computational resources are easy to access and the service oriented paradigm is shifting to microservices. Instead of limiting the usage of services by designing system integration flows you can directly program applications using microservices. As you said, it is easier to develop a microservice than following all the SOA rules and developing a Web service or an orchestrator. Try to imagine this: take a DeLorean and go back at the beginning of 2000 when SOA was born. Are you so sure that introducing a microservice approach at that time was so feasible? Even if it was possibile in specific cases, there were not a solid ground where they could grow. Today you have this natural ground in the cloud. This is why they become so popular I think.
As in an Isaac Asimov novel, SOA just represent “Robbie”, the first robot 🙂 and microservices the next evoluted version!
Thanks for the article. I’d like to dive a bit deeper into your graphs. Can you tell me how you created the set of points used in the graphs. I’m not able to reproduce your results, but I’m sure it’s my naïve use of Google Trends.
@Don: Nothing fancy. Queried Google Trends for each term, maximized the timeline and downloaded the results as a CSV.