The microservice architecture is a collection of small services with each service having a specific function. These service modules can’t perform well in isolation and need some kind of medium so that they interact and share data.
This leads us into one question: How to stitch these service modules together?
There are two ways to do it: Microservice Orchestration and Microservice Choreography. We will talk about both in detail.
Let’s have a quick peep into:
Microservice Orchestration vs Choreography
What is Microservice Orchestration?
In an orchestra, we have a central man called the “orchestrator”. Therefore, he is responsible for invoking all the sounds.
Similarly, in the microservice orchestration, the orchestrator (central controller) handles all the microservice interactions. It transmits the events and responds to it.
The microservice Orchestration is more like a centralized service. It calls one service and waits for the response before calling the next service. This follows a request/response type paradigm.
- Easy to maintain and manage as we unify the business process at the center.
- In synchronous processing, the flow of the application coordinates efficiently.
- Creating dependency due to coupled services. For example, if service A is down, service B will never be called.
- The orchestrator has the sole responsibility. If it goes down, the processing stops and the application fails.
- We lose visibility since we are not tracking business process.
What is Microservice Choreography?
It is the other way to achieve microservice interaction.
We want to avoid dependencies in a microservice architecture. So, that each service can work independently. Choreography solves this issue which was the main challenge in orchestration approach.
You can imagine Microservice Choreography as a belle dance (as shown in the above picture). In it, every individual performs steps independently.
Similarly, in microservice Choreography, every microservice performs their actions independently. It does not require any instructions. It is like the decentralized way of broadcasting data known as events. The services which are interested in those events, will use it and perform actions. This is also known as reactive architecture. The services know what to react to, and how-to, which is more like an asynchronous approach.
- Enables fast processing. As no dependency on the central controller.
- Easy to add and update. The services can be removed or added anytime from the event stream.
- As the control is distributed, there is no single point failure.
- Works well with the agile delivery model, as teams work on certain services rather than on entire application.
- Several patterns can be used. For example, Event sourcing, where events are stored, and it enables event replay. Command-query responsibility segregation (CQRS) can separate read and write activities.
- Complexity is the concerning issue. Each service is independent to identify the logic and react based on the logic provided from the event stream.
- The Business process is spread out, making it difficult to maintain and manage the overall process.
- Mindset change is a must in the asynchronous approach.
Most of the times, these approaches don’t work well in architecture. So, what is the solution in these use cases?
The answer is Hybrid
That is to say, the hybrid approach can solve the problem. For example, if we have a mix of synchronous and asynchronous blocks of activity. So consequently, one or more hybrid pattern can add value to the projects.
Hybrid is the combination of the orchestration approach and choreography. In this approach, we use orchestration within the services whereas we use choreography in between the services.
A Hybrid approach like others is two-edged. Let’s discuss:
- The Overall flow is distributed. Each service contains its flow logic.
- Services are decoupled (but to an extent).
- The coordinator is coupled with the services.
- If the coordinator goes down, it impacts the entire system.
In short, all the approaches have their benefits and trade-offs.
as the saying is “one can’t make eggs without breaking them”.
In a Nutshell
Microservice Orchestration and Choreography are two different modes of interactions. Orchestration uses a centralized approach to execute the decisions and is more crystal clear and has better control. However, Choreography gives more freedom to execute those decisions. On the other hand, we can use both by adopting a hybrid approach to get better results.
So, you can choose from these approaches according to the demands of your architecture.