Service oriented architecture vs Microservices

I guess that SOA means different things to different people, so it can be hard to state all the differences between Microservices and Service Oriented Architecture that will be right for all of us, so I'll say what I understand from both approaches.

SOA

First and foremost: in my understanding, SOA is an software architecture style (Service-oriented Architecture).

SOA is suited for an enterprise environment, where you need to integrate different applications (e.g.: human resources, billing, logistics...). This integration must occur by using service interfaces - that's why it is Service-oriented.

Since these service interfaces utilize common communication standards, SOA can promote the decoupling of applications from each other and make the development easier and faster. SOA does not define which protocol to use when integrating systems, but the most commons out there are probably via HTTP requests and messaging. Also, it doesn't define if it has to be synchronous or asynchronous service interfaces, you can use sync, async or even both.

There are some architectural patterns that help corporations implement SOA ecosystem, but the most common is the ESB - Enterprise Service Bus. There are some big players in the market that has products that implement this pattern, as an example: Oracle's Oracle Service Bus, IBM's IBM Integration Bus (Oracle has a family of products focused on service-oriented architecture that is called Oracle SOA Suite).

In summary: SOA is an enterprise-scoped concept that enables existing applications to communicate with each other via a loosely coupled interface that can use multiple protocols, messaging, sync and async interfaces, so that one application can expose it's functionality to be reused in other applications.

Microservices

Microservices is an architectural style that aims on developing an application as a suite of small, independent services.

See that? It says that ONE application MUST be developed as a SUITE of small SERVICES.

What are the benefits of this approach? Well:

1. Since they're small, they are more maintainable
2. They are loosely coupled (of course, it depends on how you designed your ecosystem)
3. They are independently deployable, which means that you can scale one part of your application without scaling the other.

Of course, there are some drawbacks, so don't trust when someone say that every application should be developed in this architectural style: distributed systems add complexity (!!!)

Microservices Architectural Style doesn't define how microservices interact with each other. It can, like SOA, be through HTTP requests, messaging, file, etc. Also, it doesn't define how one application (no to be confused with microservice) interact with another - for that, we can look into the enterprise-scope of SOA.

To clarify what these statements mean in a Microservices architecture:

• application - a suite of small, independent, loosely coupled services
• microservice - a service of the suite

The differences

While SOA is an enterprise-scoped concept that aims to integrate applications with each other via loosely coupled service interfaces, Microservices is an application-scoped concept that aims to develop ONE application as a suite of small services.

That's my point of view on both concepts and, of course, there can be disagreements

Microservices is what SOA was meant to be before Microsoft and IBM got involved and bloated it all beyond any recognition with SOAP (which is terrible) and XML (which is terrible) and UDDI (which is worse) and UML (which is unnecessary). The real difference is in the implementation, not the concepts.

"plus ça change plus c'est la même chose"

One big difference is the 'ESB', the 'Enterprise Service Bus' which is basically a messaging system that spans the entire organisation. We still use the concept, but now we call it Kafka and it works properly*.

These days Microservices largely serve REST-based APIs, because event-driven architecture has morphed into DDD, which is way too hard for most PHP and Python programmers to grok, despite being needed in all non-trivial apps**

Another major difference between SOA and Microservices is that SOA was standards-driven, whereas Microservices are rather poorly defined. This isn't a criticism, it's a feature. Because of this, it is possible for PHP programmers to still appear relevant despite having no useful skills.

The final difference is the focus. SOA focused on the interfaces, whereas microservices focus on the 'micro' bit -- the decomposition of monolithic megastructures into smaller more manageable components. In a lot of ways, microservices are closer to pure OO than most OO languages - especially if you have a non-trivial app (i.e., one that uses event-sourcing rather than REST APIs***).

• * Other messaging systems still exist, just about, but mostly it's just Kafka
• ** if you're not using this, it's because your app is trivial, not because you have a non-trivial app that doesn't need it.
• *** Event-sourcing doesn't preclude the use of REST, you can always adapt your services to the event bus using an event handler that invokes your services through a queue. But then you're getting closer to the old SOA models.