SOA versus Microservices?

| by Mark Little Follow 14 Followers on Dec 13, 2015. Estimated reading time: 8 minutes |

Over the last year or so we've seen a lot of articles and presentations on microservices including some on anti-patterns, various principles and how microservices relates to SOA. Recently Matt Brasier, Head of Consulting at C2B2 joined the latter category of discussion.

There is much discussion recently regarding the concept of microservices, and much discussion of how this fits in with SOA – whether it is the final nail in the coffin of SOA, or the latest cure-all panacea that will save software engineering.

Matt's article gives a basic outline of the reasons behind the drive towards microservices as well as SOA principles. The overall aim of the article is to show that these two are very similar in principle but products that are either targetting SOA or microservices do have differences which make them suitable for different use cases. In his microservices overview Matt has this to say:

Separating out components allows them to have separate lifecycles, and to scale as required, it also breaks many of the technology dependencies between components, allowing each service to be implemented in the most appropriate technology. Breaking down the larger problem into several smaller ones makes each individual problem easier to analyse, making it easier for developers to come up with the most suitable solution.

However, there are various disadvantages with microservices and whilst these may well be understood by many people working in the area, they are much less publicised and discussed:

Breaking down the problem like this increases the complexity of the overall solution, especially if different technologies or approaches are used to build different services. By pushing the integration points to be at interfaces between services, it is important that these interfaces are well defined, and have agreed service levels and other non-functional requirements defined.

Now it is true that because of the relative recency of microservices, tools that would normally assist architects and developers are in the infancy so some of these problems will probably be addressed sooner or later. However, there is one key problem with microservices for Matt, and that's data management and ownership:

When something that would previously have been a monolithic application is broken down into a number of smaller services, it often becomes the case that data that would be stored in one place in the monolithic application is stored in multiple places for the microservice applications. This presents challenges in maintaining data consistency.

Matt notes that microservices-related products tend to focus on the lifecycle of service components, encouraging developers to continue to use a range of implementation approaches for the actual service, such as docker, and protocols used to interact with them, which typically are RESTful in nature.

While RESTful services are generally best focussed on providing CRUD operations for a data model, it is often the case that the services in a microservice architecture can easily be broken down into these CRUD type services where RESTful is a good fit. For other services, it is often still appropriate to look at RESTful-like services, where HTTP is the transport protocol, but the service doesn’t necessarily stick 100% to the RESTful principles.

In terms of SOA, he immediately dives into the associations with microservices:

It is common to talk about the disadvantages of SOA these days, but when you really look into it, most of the disadvantages of SOA are the same as those of microservices, but with more concrete examples behind them. The same can be said for the advantages, because fundamentally what we are doing is the same thing – taking a big problem and breaking it down into smaller problems.

And he goes on to point out that the companies which are often held up as leaders in adopting or pushing microservices are happy to also describe their architectures as service-oriented. However, in order to accomplish what they did they've tended to ignore traditional SOA products, which in Matt's view are focussed on approaches based around the Enterprise Service Bus. However, in his opinion these SOA products get a bad reputation because people on some projects have used them to build an application rather than an enterprise-wide architecture and not because they are inherently poor at delivering on assisting the development of service-oriented architectures.

As such the features are focussed primarily on this enterprise use-case, with ways of tracking business-unit level SLAs. Most SOA products will mandate that services communicate using one, or a small number of protocols and message formats, such as HTTP, FTP, SOAP, JMS etc, and provide a library of connectors that enable this.

In fact Kai Wähner believes that the ESB is not dead and still has a role to play with microservices.

You use an ESB for what it is built for: Integration, orchestration, routing, (some kinds of) event processing / correlation / business activity monitoring. You can also build applications via (micro)services, which implement your requirements and solve your business problems. Deploy these services independently from each other with a standardised interface to a scalable runtime platform – automatically. The services are decoupled and scale linearly across commodity hardware.

It appears that many people, not just Matt, believe that SOA and microservices use the same set of principles but applied at different layers in an organisation. SOA is about orchestrating "large services", but those services could be implemented from a composition of microservices. Although of course as we reported earlier, perhaps size isn't a good way of defining a microservice:

Using only size for defining microservices is a poor measure and useless for determining whether a service has the right responsibilities, Jeppe Cramon states in a series of blog posts clarifying his view on microservices and the coupling problems he finds in synchronous two-way communication.

In fact Matt believes that microservices owe their existence to the success of SOA principles (others have found it easier to understand service-orientation through adopting microservices), concluding with:

If you are developing an application, then a microservice framework is going to be more agile and give you greater control as a developer. If what you are trying to do is orchestrate a number of business processes across your whole enterprise, then a SOA product probably provides a better set of tools.

Now back in 2014 we reported on a discussion between Cap Gemini's Steve Jones and others around how microservices aren't really new at all. As Steve said at the time:

This for me is why Microservices is just a Service Oriented Delivery approach for a well architected SOA solution.  SOA provides the contextual framework, provides most of the rules that Microservices aims to adhere to but more over gives a broader context within which Microservices fit within a complex enterprise.  Calling out WS-* for the one millionth time or 'big' ESB and talking about massively complex projects is simply a shot at a different challenge.

So Matt isn't alone in thinking that SOA and microservices are tied closely together, but these discussions are often driven by people who have a deep SOA background. Perhaps those microservices proponents who haven't been so immersed in SOA over the years, or have found SOA, or maybe specifically the tools aimed at aiding in developing with a SOA methodology, lacking have a different perspective? For instance, earlier this year Bob Rhubart quoted Eberhard Wolff, a freelance consultant and trainer and head of the technology advisory board for adesso AG, when he had this to say about SOA and microservices:

SOA is a strategic initiative to change the IT of the whole enterprise, separating it into different services, thereby allowing the enterprise to be more flexible. [...] Microservices must be independently deployable, whereas SOA services are often implemented in deployment monoliths. So while the technologies are to some extent similar, SOA and microservices are really different beasts.

However, in the same article Oracle ACE Director Torsten Winterberg said that in his view "Microservices are the kind of SOA we have been talking about for the last decade". This debate about any relationship between SOA and microservices is likely to rage for a long time, perhaps similar to how REST versus SOA debates went on. In fact Kevin Pool, CTO for TIBCO in Asia, called it The Great Debate:

What’s different about Microservices? In Microservices, each operation (or method) is developed separately. The single customer SOA service described [earlier in his article] would be implemented separately as dozens of separate Microservices. No formal interface is defined, or perhaps a very flat and simple interface is defined. No central data model is defined with complex schema hierarchies and structures. Well, perhaps a common data dictionary may be defined, but that is not programmatically enforced on each Microservice; each Microservice is free to independently incorporate changes only when needed. Each Microservice can be independently deployed, stopped, or restarted. In many situations there is a common platform that executes the individual Microservices.

Now Kevin took a very implementation specific view when comparing and contrasting SOA with microservices, one which centred on ESBs, SOAP and WSDL. But perhaps Coert van den Thillart summarised it best in his article from earlier this year:

How much the Microservices architectural style differs from SOA depends on who you talk to. If nothing else, MSA offers a clearer and better defined approach on setting up an architecture built around services. The key differentiator being the focus on autonomously adding value.

As well as comparing and contrasting various aspects and approaches to SOA and microservices, George Lawton believes that microservices brings agility to SOA as well as "rectifying the SOA legacy":

Microservice principles align closely with trends in Agile software development and perhaps the evolution of SOA principles, minus the heavy weight of traditional enterprise service busses.

And certainly at least one of the commenters on his article seems to agree:

I agree [with another comment] that the idea of microservices is not necessarily a new idea. I see it more as a refinement of an idea that makes better use of current technologies, such as containers and automation, to better solve a problem.

So what do you think? Are microservices and SOA related? Is this really a discussion about technological (implementation) approaches to support them both rather than architectural differences? Perhaps as Matt suggests, the real difference is with data management and ownership? Is this a debate that needs to be had at all? Or is it possible that, as George Santayana said "Those who cannot remember the past are condemned to repeat it"?

Rate this Article

Adoption Stage

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Tell us what you think

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Matt should clearify on this by Paw Baltzersen

"that data that would be stored in one place in the monolithic application is stored in multiple places for the microservice applications. This presents challenges in maintaining data consistency."
If you are talking about the same data being stored in multiple location, then you've misunderstood a very critical part of what microservices are. This should never happen.
Data in a monolithic architecture could end up being SEPARATED into multiple locations, never copied. I hope this is what you meant.

Re: Matt should clearify on this by Jean-Jacques Dubray

Are you implying that there is never a case where you will need to denormalized the underlying data model across bounded context (e.g. for improving the performance of a join)?

Re: Matt should clearify on this by Paw Baltzersen

I'm saying that a microservice owns it's data. Sure other services can make a copy of it, but I will argue that this is a bad architecture smell. I'd go back and rethink the architecture so this isn't needed. The split between the services might be wrong, which is a common (and understandable) mistake when going from monolithic to micro.
I'd do anything in my power to "denormalized the underlying data model across bounded context", simply to avoid the consistency headache.

Re: Matt should clearify on this by Jean-Jacques Dubray

We all know that relational data models can easily be partitioned in bounded contexts and every business entity can be assigned unambiguously to a single (business) owner. We all know that business capabilities from marketing to operations have completely disjoint data models.

Re: Matt should clearify on this by Gene Hughson

A blanket declaration that redundant data between microservices is an architectural smell is unrealistic. That type of declaration re: a monolith is unrealistic (caching, anyone?). Given the additional latency involved, going over the wire in every case, just to avoid redundancy, will end up either severely harming performance or greatly limiting your design options. What's important is establishing which service is the authoritative source for what data and ensuring that those with copies are eventually consistent with that source (

Another book report by Will Hartung

Hey Mark, do you have an opinion on the subject? This is another of InfoQ infamous book report on another blog post. It's not even a long article, but it's content free full of "Matt says" and a quote. Can we flag these as "Hey just go read this other blog" so we don't waste our time digging through the post to see if there's any actual value in reading it?

Re: Another book report by Mark Little

Hi Will. I wouldn't say it's "content free" but my hope was to summarise some of the more pertinent points that Matt was making. I would always encourage you to go read the full article. In terms of value, I think that comes in bringing this to the attention of a wider audience and also the conversations that hopefully ensue within the comments section.

Re: Another book report by Mark Little

Hi Will. Upon further reflection I should have included more references to other articles that compare/contrast with the topic. I've updated the article slightly and hopefully you (and others) will get more out of it now. Thanks for bringing this to my attention.

Re: Another book report by Will Hartung

Thanks Mark, I think this is much better. I hope you do too.

Re: Another book report by Mark Little

Hi Will. Yes, I do. Once again, thanks for the positive critique.

Microservices are an Agile architecture. by Dan Rosner

This part is the most salient- "Microservice principles align closely with trends in Agile software development..."
Traditional waterfall/monolithic software development practices tend to create large SOA/ESB architectures; now that everyone is 'all agile all the time'- the corollary architecture is microservices. Agile's methodology drives short, iterative dev and delivery cycles of complete but small bits of business functionality. It's a natural fit to deliver these services as microservices.
Not getting into whether this is better or worse, the answer to that is, "it depends" on what you are building and maturity of business, etc.

But just pointing out that architecturally SOA is to waterfall as microservices are to agile. It's not a lot more complicated than that.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Email me replies to any of my messages in this thread

11 Discuss

Login to InfoQ to interact with what matters most to you.

Recover your password...


Follow your favorite topics and editors

Quick overview of most important highlights in the industry and on the site.


More signal, less noise

Build your own feed by choosing topics you want to read about and editors you want to hear from.


Stay up-to-date

Set up your notifications and don't miss out on content that matters to you