Apparently simple questions like “how are microservices related to SOA?” are a common cause of heated arguments. Let’s assume we’ve at least managed to separate the core concepts of APIs and microservices discussed in our previous post we’re now moving on to some much more complex questions. Are microservices an evolution of SOA, or are they completely different concepts?
The article Microservices, “SOA, and APIs: Friends or enemies?” discusses this in some detail but for those who don’t want to wade through 15 pages of text, or for that matter the related full webinar, we’ve created a quick 10 minute video and this short post to guide you through some of the key points.
What is microservices architecture?
Microservice architecture might have been better named “micro-component” architecture, because it’s really about breaking applications up into smaller pieces. The aim of a microservice architecture is to completely decouple application components from one another. This is typically with the aim of improving agility; the velocity at which functionality can be delivered. This is primarily because these components should be well decoupled and can therefore be changed independently. Many other potential benefits follow from that including opportunities for more elastic individual scalability, especially in cloud native deployments, and more creative resilience models enabling each component to provide the its own unique up-time model based on its specific business needs. Microservices architecture is a new, more flexible way to build applications.
Could we just say that SOA and microservices relate to different scopes?
A very simplistic view would be that services oriented architecture (SOA) relates to exposing business functions and data via standardized interfaces for re-use across the enterprise. If we then compare this to our definition of microservices, they are an alternative way of building applications.
With this view, microservices and SOA appear to be completely separate concepts, one at the enterprise scope and the other at the application scope. You well might wonder what all the fuss is about!
What was SOA really about, integration or component decomposition?
The real challenge is that there are very different views out there on what SOA was really about. Let’s take a look at how two very different views could evolve.
For large enterprises, with a multitude of aging systems of record, an SOA programme is likely to spend a significant amount of time solving hard integration problems in order to surface complex back end systems of record as re-usable interfaces. After a while, it may start to feel like SOA was all about integration.
However, the original aims of SOA were broader. The desire was to re-landscape the systems of record into business services more applicable for the applications of the future.
For a perhaps smaller company with fewer, more modern systems of record, the integration aspect of SOA might be comparatively trivial, and most of the time might be spent on this re-landscaping, probably creating an intermediate layer of “service components” that represent those valuable business services.
As technology moves forward, and we create more lightweight runtimes and methods for building those components, we can create smaller, more independent service components. You can see where this is going. We could call these “microservice components”, and now suddenly microservices looks more like an evolution of SOA rather than something completely different to it. Both view have merit, depending on your definition of SOA in the first place.
How pervasive are microservices?
The other reason for the wildly differing opinions is how much of your estate is likely to become microservices based. In a mature large enterprise such as a bank or insurance company with IT systems created and acquired over multiple decades, microservices architecture is just another option for now to build an application. Microservices not going to take over a large enterprise’s IT landscape any time soon any more than SOA did. It’s just an alternative application architecture, well suited to a particular set of solutions.
Now if we compare that to the other extreme, a green field online start-up. They might use microservices as their fundamental architectural style, and everything they build, is done in that way. In their situation, they could describe their entire estate as “(micro)services oriented architecture”. We can see now that for this company, microservices could look very much like an evolution of service oriented architecture, and they might well see it as an enterprise wide architectural pattern.
We should recognize that this second situation isn’t limited to small start-up. However, it is inevitably more common in “modern” companies with less IT legacy.
Some microservices principles are really different to SOA
It’s also worth knowing that microservices architecture introduces some principles that will be pretty surprising to someone from an SOA background. Here are some key examples:
- Re-use: Microservices is about creating small truly independent components. So for example, for SOA re-use was one of the primary perceived benefits. The ability to re-use data and function from one application in another. However, for microservice components, re-using a component, especially at runtime, and perhaps even at design time results in dependencies that make the resulting solution fragile, so re-use is often discouraged.
- Inter-communication: SOA typically resulted in the exposure of synchronous web services such as SOAP/HTTP. In microservices, a synchronous protocol such as HTTP, whether SOAP or REST based causes a real-time dependency between components, so messaging is the preferred transport between microservices wherever possible. REST is used, but generally reserved just for exposing the microservice beyond the bounds of the application, or to the outside world.
There’s more too, for example with issues relating to service discovery, and data duplication and more. For all their similarities, when it comes to the detail the two are very different in some fundamental ways.
Microservices are certainly more focused on application architecture. Whether you can use those concepts at the enterprise level strongly depends on the shape and size of your enterprise. SOA is unquestionably an enterprise level concept. You can certainly bring microservices techniques in to help how you build that out, but be careful when the two overlap as some of the core principles are very different.
How to start an argument
I promised you I’d tell you how to start an argument! Debates typically get rolling when things are being compared that don’t match. For example asking people to compare ”Microservices and SOA” is itself misleading as a microservice is a component and SOA is, well, an architecture obviously. Now if we were to compare microservices architecture with service oriented architecture, we’d at least have a fair comparison, and we could discuss whether each of them are application architecture or enterprise architecture.
Final thoughts
The core concepts for this were taken from the article “SOA, and APIs: Friends or enemies?” so feel free to get the full story from there. There is also a full length webinar covering the broader points in that article.
In future posts we’ll go on to look at how the products within IBM’s hybrid integration portfolio are typically used to complement SOA and microservices architecture, and how to decide what is most appropriate for your organization.