This content is part of the Essential Guide: SOA tutorial: Trends, governance and the microservice impact
Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

SOA vs. microservices: Is a service by any other name a fad?

Comparing SOA vs. microservices architecture, a veteran developer sees evidence that the latter is a fad. Even small biz should consider SOA, he advises.

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.

Next Steps

Quiz yourself on SOA vs. microservices

Making microservices big in 2016

What are space-based microservices?

SOA vs. microservices: What you need to know

Dig Deeper on Distributed application architecture

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.

Do you think microservices will be replaced by chat bots, machine learning or another type of services architecture? Why?
I think that they'll be certainly be replaced by something, I'm just not sure what; the next fad that comes along down the road. 
I don’t see it so much as being replaced as they will be evolve into something more than microservices.
Forgive me if I misunderstand the meaning of SOA and Monolithic Architecture - but they are not the same thing. In this article you keep referring to monolithic architecture as SOA.... Please explain your understanding of the 2. I have read up and these are not the same thing.
Microservice architectures are not so much as fad as they are a refinement of SOA, which the majority of us got wrong the first time around.
CarolVdB, SOA stands for service-oriented architecture, which at it's simplest refers to decomposing an application into collections of related API calls (typically implemented as RESTful interactions over http/s). How those APIs are implemented is not really covered by the definition, and many, if not most, initial efforts used monolithic services to implement many APIs or one large API on a single process. As scalability, durability and granularity of change becomes an issue the pressure to decompose that monolithic service implementation into micro-services becomes greater.

mcorum, I fully agree. Microservices are definitely a refinement of SOA. I'm not sure whether we got it wrong, or whether it was simply that we hadn't gotten to where it was an issue yet. Either way you end up in the same place.
Good point - I suspect “wrong” was the wrong word to use there.
The title of this article and its thesis are unfortunate.  People reading the title only (as many do) will now question the validity of micro-services, when in fact micro services are an implementation of a SOA.  When SOA was first described, there was no agreed upon standard for services, which is why SOAP/WSDL were designed.  Since that time, the RESTful interface has achieved consensus.  Micro Services are simply RESTful services.  I'm not sure by what measure one defines micro-services as opposed to any other RESTful service. Perhaps the only "fad" involved is the word micro.  I like the word micro, because it gives people, (i.e., developers), the notion that web services should be broken down into small, reusable portions.  Maybe that will improve the development community by reintroducing the concept of functional decomposition, which has fallen by the wayside as a decade of entrants into the workforce have learned to develop using WYSIWYG tools.
Hi, Patrick. Your comment " Micro Services are simply RESTful services.  I'm not sure by what measure one defines micro-services as opposed to any other RESTful service." sums up my feelings completely. I think the title and link with SOA were not good choices, but they came out of editing and I had no say in it.