What is really different between SOA and Microservices

Question

Disclaimer

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

Background

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

Question

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

References

• Software Engineering Questions
• Martin Fowler's Site (I think he hates it big time)
• Info world
• Michael Fethers' Website
• Stack Overflow Questions

Update

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

Answer 1

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.

Answer 2

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.