The Difference between SOA and Microservices?

| by Mark Little Follow 13 Followers on Jul 23, 2017. Estimated reading time: 2 minutes |

We've had a few articles over the years on the differences and similarities between SOA and microservices. Some suggest there is much to be learned from SOA whereas others believe that distancing microservices from SOA is more beneficial. Furthermore, Neal Ford, amongst others, has suggested that moving from monolithic architectures to a services-based approach may be easier than going to microservices. There has not been much activity recently around the overall "SOA or microservices" debate until RedMonk's Stephen O'Grady published an article on the subject. In it O'Grady suggests that the size of the service is not the deciding factor, similar to what others have argued over the years, such as Dan North, and separately Jeppe Cramon stated:

Using only size for defining microservices is a poor measure and useless for determining whether a service has the right responsibilities [...]

In fact O'Grady believes these are a lot of facts behind the association between SOA and microservices:

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.

Within his article O'Grady has produced a couple of nice diagrams using Google Trends, and the first shows that despite its popularity, SOA peaked and was popular for a relatively short period of time in the industry.

Stephen believes that the argument about size as a differentiator ignores or obscures the real reason why SOA dropped in popularity and microservices came on the scene; in his view, SOA was a vendor driven effort whereas microservices is driven far more by developers.

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.

O'Grady mentions that microservices do benefit from SOA, both on what worked and what did not work.

Microservices are easier for them to develop than monolithic alternatives, and come without the vendor standards baggage of SOA [...]

Others have made the same argument over the last few years, including Asanka who said:

Today, enterprises are moving toward a clean SOA and embracing the concept of an MSA within a SOA. Possibly the biggest draws are the componentization and single function offered by these microservices that make it possible to deploy the component rapidly as well as scale it as needed. It isn't a novel concept though.

And the second Google Trends graph Stephen shows is also interesting.

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

"SOA is dead; long live services" by Gene Hughson

I think it's a matter of scope, rather than size.

Microservice architecture, unlike SOA, is an application-level pattern. Microservices are typically oriented toward a use, with the ability to independently scale whereas SOA was oriented toward reuse and sharing (more detail here).

SOA's inter-application nature, when combined with the "build it and they will come" philosophy (and yes, the vendor hype didn't help either) led to a lot of unfulfilled hopes. The techniques were useful, the reality just didn't live up to the expectations. That being said, I suspect there's a fair amount of SOA still going on, just under an assumed name.

I am surprised why people think microservices are not part of SOA by Siva Prasanna Kumar

First thing to understand is SOA is no tool, no pattern, it's a concept. It just says how characteristic features of service should be and with certain granularity.

Atleast as far as I understand microservices services granularity is smaller but still end of the day they all are services which will adhere to basic principles of SOA.

MSA is SOA optimised for the particular purpose, namely, deliver a complete application as a set of services. by Alexander SAMARIN

MSA is SOA optimised for the particular purpose, namely, deliver a complete application as a set of services. The main MSA rules is one unit-of-functionality in one unit-of-deployment as one unit-of-execution - some kind of BizDevOps model.

SOA and Microservices by JOel MAmedov

ERP applications are so called "monolithic" type applications and there are many reasons for that (transaction, integration, complex business rules, workflows, complex databases and so on) Now, try to build ERP application with SOA or Microservices. As name implies the service is just that a service that being provided/exposed by "application". But, application has to be build first before any its services can be made available (selectively) to external consumers. The idea that application can be assembled by individual services is not a serious proposition.

This article doesn't define its terms by Matt Friedman

An article entitled: "The Difference between SOA and Microservices?" should first and foremost start with definitions of SOA and Microservices. Without such definitions I find the article of little use.

The truth is both SOA and Microservices are vague terms meant to express a general concept which may sometimes mean exactly the same thing and/or have the same result.

Re: This article doesn't define its terms by Mark Little

Matt, we try not to duplicate information which is captured in other articles on the site but instead link to them. Hopefully if you follow the links at the start of the article you'll find the data.

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

6 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