I hope I am not stepping on anyone's toes or offending either concepts' enthusiasts


I have been looking for real differences between Service Oriented Architecture and Microservices, without finding any clear answer.

I read things like:

  • the side effects of SOA
  • SOA being anti-pattern
  • Microservices came to fix SOA's failures
  • ESBs are not really ESBs instead they are EAIs
  • Over-reliance on Message Brokers
  • Vendors are abusing the notion of SOA and trying to sell their products
  • SOA grows uncontrollably

But still, nothing clearly defines architectural differences between Service Oriented Architecture (as a concept) and Microservices (as a concept)

According to what I understood, they both have:

  • Service Providers, doing only one thing
  • Service Gateway/ESB exposing those services to consumers
  • Service Consumers, accessing services via ESB/Service Gateway


So, is there anything different other than relabeling SOA into Microservices? is it a technology constraint placed to limit Microservices from becoming macro?

Note: I am not looking for opinions, only hard facts, hopefully in bullet points



It seems that a similar debate happened in a Stack overflow question, with opinions divided wether or not Microservices are Service Oriented Architecture in disguise.

Conclusion from the SO question:

  • MS is a special case of SOA
  • MS endorse smaller size of applications hosting services
  • MS is technology dependent (the use of HTTP rather than open protocol options)
  • MS relies on technology to enforce discipline (automatic deployment of services)
  • MS Considers ESBs (evil), but uses API Gateways which IMHO is a type of ESB

That concludes that MS is SOA, if the following is true:

  • Do MS support the notion of Orchestration? One or more master process(es) manage workflows
  • Is there a message broker layer in MS? A set of adapters translating message formats from the message space of the service producers to the service consumers
  • Can microservices read data from monolithic enterprise applications? Can it be APIs of a monolithic application? or it has to be standalone self contained applications, capable of operating independently?

If the answer to last question turned out to be no, then Microservices would not be capable of handling complex workflow systems, e.g. Credit Card Management Systems, or reconciliation systems

  • The fashion for distributed computing nowadays is small, loosely coupled, decentralized, fault-tolerant "agents" or "modules" that have clear, specific responsibilities and are connected together by a simple, straightforward communications protocol. SOA is pretty much the opposite of all that. Your observing the molehill of superficial similarities and overlooking the mountain of differences. Commented Aug 30, 2017 at 17:07
  • 1
    Shouldn't SOA also implement small loosely coupled components? I know at the back end of SOA, are multi-functional applications, mostly described as a "Best of Breed" providing services to other applications and consuming services from other applications, using whatever message format, protocol and medium access suitable for it
    – A.Rashad
    Commented Aug 30, 2017 at 17:14
  • It should, but as you just pointed out, it usually doesn't. Commented Aug 30, 2017 at 17:44
  • Martin Fowler's Site (I think he hates it big time) That was not my feelings when I went to his talk in Barcelona. He's aware of the trade-offs and how people have shifted to this architecture blindly without considering that MS is not suitable for everyone.
    – Laiv
    Commented Sep 1, 2017 at 7:08
  • 1
    Microservices is a bunch of marketing. There is no difference. People were doing this years ago and now someone put a name to it and now it something new. You are correct MS is a (NOT SPECIAL) case of SOA. Please stop with trying to make something out of it. Commented Sep 14, 2017 at 23:08

2 Answers 2


Service Providers, doing only one thing

The core difference, which has widespread consequences of the project, is that with Microservices these Service Providers are independently deployable and scalable.

This is great, because you can be more agile. If a service needs changed, you just change that one, none of its kin. If you want to try a new framework or language, just make a drop-in replacement for that one service. If you suddenly need 100x capacity, spin up some new machines with that service to handle that influx. If you want to version something, just version it without touching the whole app. And it makes things easier to monitor, instrument, divvy amongst teams, obsolete...

But it comes with some heafty implications:

  • Your release process needs to change, because deploying a few services is way different from deploying a few dozen services.
  • Your release process needs to change, because deploying a service to one machine is way different from deploying to a few dozen machines.
  • Your database design, usage, and deployment needs to change because it's kinda meaningless to deploy a service if it needs to deploy this big shared DB to work (breaking all of your other services).
  • Your design and usage of libraries needs to change because it's kinda meaningless to deploy a service if it needs to update this shared library (breaking all of your other services).
  • Your logging/authorization/session management/etc needs to change because it's pretty easy to share stuff when you're just one service, but different when you have a bunch of independent little services that make up the product - and they're going to want to share stuff. Oh, and all of that shared stuff needs to deal with potentially being on different versions.
  • Your communication needs to change. With few services, you can break things along lines where communication doesn't happen often and/or could happen slowly. With microservices, they're going to talk to each other a lot, and high latency isn't going to cut it.
  • 2
    It's for all of these reasons that I view microservices as a specific solution to a specific problem (scaling via distributed computing), and not as an overall application architecture. Commented Aug 30, 2017 at 17:47
  • 1
    Enh, they've got a widespread enough impact that I think that they should be viewed as an application architecture with scalability/distributed computing as an upside (with complexity and other downsides as the trade off).
    – Telastyn
    Commented Aug 30, 2017 at 17:52
  • 2
    So from an architectural point of view, microservices are standalone micro systems doing one thing, while SOA are monolithic applications with multiple services exposed to consumers?
    – A.Rashad
    Commented Aug 30, 2017 at 17:57
  • 1
    I am more confused now! Is it possible for a monolithic application to expose microservices? or does it have to be standalone micro applications?
    – A.Rashad
    Commented Aug 31, 2017 at 14:26
  • 1
    Take a look at this article in DZone Microservices vs SOA.
    – Laiv
    Commented Sep 1, 2017 at 7:17

Here is the bottom-line The one obvious difference between SOA and Microservices is the notion of

Smart Endpoints Dumb Pipes

Unlike SOA, that would rely on oblivious service consumers and producers, delegating traffic management, message format translation and service orchestratoration to external systems, e.g. ESB, service Orchestrator, Message broker.

Not the answer you're looking for? Browse other questions tagged or ask your own question.