Although both SOA and microservices are architecture styles (an architecture style is a formal notation to explain how a software application is assembled and its implications),these two variations have a lot of differences:
- Its approach is to connect existing applications via a single instance, the ESB, via disparate protocols.
- The connection and message delivery between the endpoints must be orchestratedwithin the ESB.
- The service that is exposed in the ESB should be written in a specific language and follow mostly SOAP protocol (with or without WS* stack) or REST, via HTTP protocol.
- Costly when you have a huge payload to exchange between the parties, due to the phases of marshaling and unmarshaling.
- Vertically scalable.
- ESB as a single point of failure.
- Harder to deploy in comparison to MSA (microservices style architecture) due to dependencies of the application endpoint and ESB mediation itself.
- Services are registered in advance of the execution and consumption of their contract by other services.
- Its approach is to create a single, self-sufficient application that can run in an isolated environment with its own database.
- The connections between the services are choreographed – this way the microservice can respond to a specific event received.
- Follows only REST conventions. Can use binary protocols such as Google Protobuf and Twitter Finagle.
- Corresponds to a functional feature of our current monolith system.
- Horizontally scalable.
- Easy to deploy with CD/CI in place.
- Microservices register themselves in an entity called an API Gateway and are automatically discovered by other microservices.