In recent years, microservices have gained significant relevance in application development. They have spread so widely that they are now applied by default to any project, whether necessary or not.
The reality is that microservices are not easy to manage; they introduce a lot of complexity, and it’s important to know when to use them and, above all, how to do so.
Why do I say this? Because I was very surprised that, when talking to a couple of developers from an important European technology company (they have more microservices than developers), they didn’t know what orchestrating or choreographing meant.
Why is it important to know these terms? Because choreography and orchestration are the two (not mutually exclusive) ways of interacting between microservices.
By definition, microservices should contain only a part of the business logic. A use case for a microservice (usually) is a part of another more global use case that involves several microservices. Thus, microservices need each other and, therefore, must be able to communicate. This communication can be done in many ways: API, events (Event-Driven Architecture), sockets, SOAP, and any other form of communication we can think of.
Right at this point, when we have a use case that involves several microservices, we have to make a decision: do we use orchestration, choreography, or both?
Orchestration and Choreography analogy
As a fan of analogies, let’s go with one to explain the difference between orchestration and choreography in a more dynamic way. In the following sections I’ll provide a more technical view.
Let’s visualize a full orchestra with its conductor and a variety of musicians: violinists, cellists, etc. This orchestra faces the challenge of performing a symphony where each musician plays a critical role although their contribution is a small part of the whole. Here, the goal is to play the symphony without errors, similar to the operation of microservices, where each “musician” (microservice) contributes functionality.
As rehearsals progress, coordination challenges emerge; the violin must precede the cello but they fail to synchronize. Here comes the conductor, who takes on the task of orchestrating, ensuring that each one performs their part at the right time.
Orchestration, then, involves a central entity that directs the operation. The conductor acts as such, similar to a service that manages the sequential calls to various microservices ensuring that everything is executed in the correct order and time.
However, suppose the conductor leaves their position. In the absence of this central figure, the musicians decide to operate more autonomously, adapting to the flow of the ensemble. If the violin starts its solo, it signals the cello its time to enter. This exemplifies choreography, where there is no central command, but each service (musician) responds and adjusts based on the activity of the others.
There are, of course, mixed approaches. The conductor could set the general guidelines —key points where they take control—, but allow, at other times, for the musicians themselves to coordinate their interaction.
Orchestration
Orchestration refers to the method by which the interaction between different services is controlled and managed in a centralized manner. There is a service, known as the orchestrator, that takes responsibility for directing the flow and coordinating calls to the services. It determines what requests, when, and how they should be made, allowing for the definition of complex flows.
Advantages of Orchestration
- Centralized control.
Orchestration provides a single point of control, facilitating implementation and changes. Additionally, it relieves each service from the responsibility of knowing how to act in response to the actions of other services, easing the development and maintenance of code.
- Ease of monitoring and error management.
Having a single point of orchestration allows us to identify and resolve errors more quickly. A centralized point also allows us to visually understand the logic of the use case and manage compensatory actions to maintain the application’s state consistent if an error occurs.
Disadvantages of Orchestration
- Single point of failure.
Concentrating coordination logic in a single service introduces a risk, as any failure in this service will affect the entire process.
- Can generate bottlenecks.
When working in systems with high loads, having a centralized point can produce a bottleneck. Ultimately, we are creating a funnel through which all requests to microservices will pass.
- Risk of creating a “monolithic microservice”.
This is, in my opinion, the biggest risk we can face when adopting this method of coordination. Having a centralized point can lead to an overly complex orchestrator with too many responsibilities and business logic.
Choreography
In contrast to orchestration, choreography describes a decentralized approach to the interaction between services. In this model, there is no centralized place to coordinate the different calls to the services; instead, each service knows and manages its own rules of interaction and communication with other services. This coordination is based on an Event-Driven Architecture, where each service publishes events and others consume them. The services that consume the events can decide whether or not to execute a use case.
Advantages of Choreography
- Scalability and resilience.
Choreography facilitates the construction of systems that can scale more easily and be more resilient to failures, as the failure of one service does not necessarily affect the other services.
- Greater flexibility and decoupling.
This approach promotes the independence of the services, allowing development teams to work in parallel and make changes to specific services without the need to closely coordinate with the maintenance of a central orchestrator.
Disadvantages of Choreography
- Complexity in tracking and monitoring processes.
Without a centralized point defining the flow of business logic, it can be more complex to monitor the complete state of the distributed process.
- Difficulty in managing complex dependencies between services.
Complexity increases as more services and events are added, as it is necessary to have a global view of what happens after each change.
- Risk of inconsistency and difficult-to-trace errors.
Without maintaining a central point, an unexpected modification of the flow in some service can occur, causing inconsistencies and errors in the sequence of operations.
Comparison between Orchestration and Choreography
| Orchestration | Choreography | |
|---|---|---|
| Control | Centralized: An orchestrator directs the flow of operations between services. | Decentralized: Services autonomously decide when and how to interact based on events. |
| Complexity | The integration logic is centralized, which can simplify the design. | Event management and subscriptions can increase complexity and development effort. |
| Flexibility | Changes in the process flow require updates from the orchestrator, which can be slow. | High, since services can adapt and evolve independently. |
| Scalability | May be limited by the orchestrator, especially under high loads. | Favored by the decentralized model, allowing independent scaling of services. |
| Monitoring | Facilitated by a central point of control, allowing detailed tracking. | Can be challenging due to the distributed nature of interactions. |
| Resilience | A failure in the orchestrator can impact the entire system. | Higher, as the failure of one service affects the system less as a whole. |
Personal conclusion
In my opinion, orchestration is more maintainable and simpler than choreography. It allows defining, even with external tools, how the flow between services will be. Moreover, it offers advantages in monitoring, debugging, and visualizing the flow.
On the other hand, I find a consistency issue with choreography. In theory, it is more scalable; however, as scalability needs grow (more services, more events, and more use cases), complexity increases exponentially as we are more exposed to interruptions in the flow by other services. Nonetheless, I like to apply it on a small scale, when execution flows are not complex and we can do without a centralized unit.
In conclusion, the use or non-use of each method depends on the context, the project’s needs, and, of course, the team’s experience.