DEV Community

Cover image for Microservices Patterns: Orchestration and Choreography
Allan B/H
Allan B/H

Posted on

Microservices Patterns: Orchestration and Choreography

Hi everyone! This is my first post and I'd like to share some thoughts about the differences between Orchestration and Choreography as architecture approaches in a solution based on microservices.

There are many ways to define the interaction between software components, in a microservices architecture, to have a robust result, is crucial to follow some principles of design.

That is why could be a very important tool to know about Orchestration and Choreography terms.

Orchestration

This pattern behaves like a real orchestra, where there is a central guider that coordinates all of rest of musicians in order to play a symphony. In Orchestration, a piece of software does that work and by certain number of calls, it makes possible the entire process.

Alt Orchestration

According to the last image, service 1 is responsible for making the requests to other components. Those calls could be either synchronous or asynchronous. So, service 1 manages the interactions between service 2 and service 3.

In that sense, an orchestrator becomes an easy way to manage complex processes by a centralized control between each steps. So, it has all required functionalities to make a response to the client.

Most likely, Orchestration can increase the dependencies between services. Due to the existence of a single coordinator of a entire process. Usually it is delegated to this component more responsibility than others and sometimes it results in a lack of purpose and anemic model .

Summary

  • A single component conducts all the process (orchestrator).
  • Commonly, orchestrator has more responsibility that other components.
  • Easy way to coordinate a complex process with several steps.
  • If orchestrator gets so much responsibility, tends to anemic models.

Choreography

On another side, Choreography is a pattern which components communicate by themselves to complete a request. So, there is no a single conductor but each service is responsible for doing its part of the job.

The governance of services under this model could be more complex, since there are several points of failure. And evidently, it is necessary to complement the solution with a good tracing pattern.

However, Choreography provides low coupling when is implemented under a event-driven architecture (although this approach is not exclusive of that pattern). Because of this, the components designed come to be more autonomous and it allows a better reusability thus the reduce of dependencies.

Alt Choreography

Therefore, in a choreography service 1 doesn't know about the calls of service 2 and service 3.

Summary

  • Each service acts together to get a result with the same level of responsibility.
  • The interactions flow uses to be more complex.
  • Components are more autonomous.

tl;dr

Orchestration Choreography
A single component conducts
all the process.
Components have to act together in a coordinated way.

Orchestrator has more responsibility
than other components.
Use to be a harder way to coordinate a
complex process with several steps.
Orchestrator with so much responsibility
tends to anemic models.
Services show a tendency to be more
autonomous.

Conclusion

Orchestration and Choreography models have certain advantages and disadvantages and they are not good or bad by themselves. All depends on the requirements and technical capabilities. For that reason, it would be helpful to evaluate the pros and cons of both patterns to implement a solution that fits properly.
Finally, it is necessary to emphasize that is not kind of dichotomy between Orchestration and Choreography and they could be used in a sort of combination inside an software architecture.

References

Bruce, M., & Pereira, P. A. (2019). Microservices in action. Shelter Island, NY: Manning Publications Co.

Top comments (0)