Interview: Why Microservice Architecture and not SOA
Microservices architecture is an extension of SOA.
Main Differences between SOA and Microservices
- Reusability: One of the goals of SOA is to reuse components without worrying about coupling while in microservices weak coupling is preferred, even if it means having code duplication.
- Communication: In SOA, communication between services is usually done synchronously through an enterprise service bus (ESB), this introduces a critical point of failure and latency. In MS Asynchronous communication is also privileged between services (for example a publish subscribe model can be used to allow a service to stay up to date on changes to another one’s data), enabling high availability.
Advantages —
- Independent Development
- Independent deployment
- Independent scaling
- Data isolation: In a microservices architecture, each service has private access to its database (ideally), we can then perform an update of the database schema without affecting the other services.
Disadvantages
- Data Integrity: Microservices have a distributed database architecture, which is a challenge for data integrity. Some business transactions, which require updating multiple business functions of the application, need to update multiple databases owned by different services. This requires setting up eventual consistency of data
- Network latency: Using many small services can result in increased communications between services.synchronous communications should be favored when usage permits
Orchestration vs Choreography
In a microservices architecture, it is inevitable that some services need to communicate with each other, these communications can be achieved in two ways, orchestration or choreography.
Orchestration :
The first intuitive idea to make the services communicate with each other is quite simply to make REST calls between the services. But it introduces dependencies between services. Use orchestrator service to call other services. There is still drawback which is the latency it introduces due to synchronous calls, and poor fault tolerance.
Choreography
The solution is to use events with a publish-subscribe model. Communication is asynchronous and services are unaware of each other, therefore the system is efficient and easy to maintain on a large scale.
In the event of a service failure, the system continues to operate, but the consistency of the data can be lost( The high availability of the system is favored, in cases where the consistency of the data is critical).
It is completely possible to set up circuit breakers to automatically deactivate certain services.
