When comparing SOA vs. microservices, keep in mind that fads are a fact of life in the software business. They build, usually around the core of a good concept; crest; and then die, collapsing back into the ocean of ideas from whence they came. The really strong fads, the ones that seem for a time to inhabit the center of every technical conversation, often end in a backlash or counter trend of some sort. If the front half of the curve is characterized by, "Everyone has to do this!" then the back half is often marked by, "You might not have to do this at all!"
So it has been with the idea of microservices, and if that fad is fading a bit, perhaps to be replaced by chat bots, machine learning or big data, then when it is gone, architects and developers will still be confronting the same hard choices they faced before it emerged. How should we compose our next solution? Where should the pieces live, and how should they communicate with each other?
Truth vs. fiction
As people, we have a thirst for dramatic developments and transfiguring concepts. But fads often do us a disservice by establishing false dichotomies. In the present case, the comparison is between monolithic SOA versus microservices architectures, the former being bad and the latter good, with nothing in between.
The truth is always more nuanced. It may well be that if you try to carry on with a monolithic architecture too far into your growth curve, you'll hit a nasty brick wall, but it may also be the case that adopting microservices when you're in the early stages will make your work a lot harder. There are good reasons for that, but before setting them out, it's worth revisiting a little history. Why? Because microservices aren't new, and this isn't the first time we've gathered as a tribe to chuck rocks at the monolith.
The concept of microservices is, at heart, about breaking large complex things into simpler, more comprehensible pieces. That idea is not a new one. Decoupling, modularity and cohesiveness were topics of technical conversation among programmers 30 years ago. Then, it was because monolithic programs written mostly in compiled languages had become large and difficult to work with. Now, it is because monolithic server applications written mostly in dynamic languages have become large and difficult to work with.
The drive to compartmentalize and organize is born of a sincere and reasonable desire for simplification, and it usually makes things better. This was the case when we began decomposing big, hairy Web applications into front-end components and APIs back when SOA was all the rage. It remains the case today when the back-end services supporting those APIs have grown in complexity and scale. In one sense, we're getting back some of that decoupling and modularity that we had in the 1990s before Web servers ate the world. You might say that microservices are SOA done right.
What drives architecture?
Looking at the SOA vs. microservices choices today, it seems obvious that a new project should adopt a microservices architecture; but there's another way to look at this. The architecture of a system is driven not just by the scale of use -- requests per second, data reads and writes, and more -- but also by the scale of the team that creates and maintains it.
A small team trying to manage 10 different services may be in as much trouble as a huge team trying to make updates to 10 services running on the same application. This is a case where the fad dichotomy clearly is false. For a small team, a monolithic services architecture, or one with just a few services -- i.e., the classic SOA model -- is a lot easier to manage and can scale very well if the middle pieces are stateless, sessions are handled intelligently and you're prepared to keep throwing stuff at the databases.
Yes, in SOA, you have to deploy and scale at a larger level of granularity, and this will constrain your practices in some respects, but small teams often have other priorities, such as getting live and seizing a business opportunity.
The benefits of granular service implementations -- micro, macro or somewhere in between -- begin to be realized when both the volume of activity and the size of the team increase beyond a certain level. Just where or when is hard to measure and is probably different for every business. When you get there, you'll know, and then breaking your services up into independent code bases running in their own applications can solve a lot of hard problems. You can develop, iterate, deploy and scale such services independently of one and other, which at that level is probably also a decent description of how you want your teams organized and how you want them to interact with each other.
Ultimately, Conway's Law holds up: The design of a system often reflects the design of the organization that creates it. At the same time, adopting an architecture of microservices presents other challenges: You have more code bases to manage, and the need to adopt build and deployment automation tools is all the more pressing, simply because there is a lot more to remember and do to make it all work right.
So, how do we choose?
The challenge for managers in evaluating SOA vs. microservices, then, is the same old problem of making the right choice at the right time for the current needs of a business. A few takeaways that might help are:
- Keep in mind that modern monolithic architectures can take you a long away down the growth path if best practices are adhered to.
- When considering decomposing into services, also consider the organization of the teams that will support the code bases.
- It's OK to design around a few key services, and get to the right decomposition iteratively; there is no standard for "micro-ness."
Choosing between SOA vs. microservices architectures presents managers with the same old problem of making the right choice at the right time for the current needs of a business. Ignoring popular professional interest in an idea like microservices would be as ill-advised as immediately adopting all of the principles espoused by the legions of the faithful for your startup team of four engineers. I've seen exactly that done by eager CTOs in the recent past, and the results were not what they hoped for. As always, what is required is to take the good, dispose of the bad and apply the right solutions to the right problems in the right order. Therein lies the path to wisdom and success, if there is success to be found.
Quiz yourself on SOA vs. microservices
Making microservices big in 2016
What are space-based microservices?