Microservices Orchestration vs Choreography: What should you prefer?

As per Dzone, a survey done with 345 enterprises, 63% of companies say they used Microservices architecture with improved employee efficiency and customer experience. In the same survey enterprises also agreed that they saw higher benefits in using an orchestration engine in their Microservices architecture. On the other hand StackOverflow data says companies usually take Choreography approach for their Microservices without really knowing it.

In last year’s Accion Global Innovation Summit, Hemesh Thakkar our design and architecture lead presented a session on “Orchestration vs Choreography”.

Hemesh discussed the differences between implementing Choreography of Microservices and Orchestrating them. He also stated various challenges with Choreography and Orchestration approaches and how Accion Labs’ Breeze blueprint uses platforms like Camunda and Zeebe to overcome these challenges.

Listen to Podcast: Orchestration vs Choreography of Microservices

Managing Independence and Control

To illustrate the challenges that need to be addressed in a microservices architecture, let us consider a hypothetical application. We have several capabilities in the application that need to work with each other in order to perform certain business goals. For example, if we are building an e-commerce application, this could consist of several microservices such as:

• A Product microservice that would show you a list of products.
• A Cart service that allows a selection of products along with parameters such as quantity, colors, flavors etc. to be specified
• An Inventory microservice that checks which products are in stock in various locations
• A Shipping microservice that provides information about shipping any product to a given location

All these microservices would work independently, and can be customized, scaled and deployed independently. However, a customer’s purchase journey encounters all these independent microservices. Hence the overall business transaction that spans the scope of multiple microservices needs to be controlled. The transaction needs to be seamless, and should not be broken. All the microservices need to work together to be able to fulfill an order and that will be the real value for the business.

The pattern of requirements where business transactions require cross boundary coordination between multiple microservices is called a saga or workflow pattern. There are several models for implementing such workflows or sagas in a microservices environment. These models differ in the level of independence provided to each microservice and the method of control for them to work with each other seamlessly.

The three models that distinctly differ in the two aspects of independence and control are:

1. Tight Coupling - where all microservices are tightly coupled with each other providing the least independence to each microservice. The method of control of the saga or workflow is spread across all the microservices, and is hence highly brittle and difficult to change.
2. Choreography - where microservices work independently but coordinate with each other using cues or events. The method of control of the saga or workflow is determined by a predefined set of cues or events.
3. Orchestration - where microservices are controlled by an orchestrator or conductor. This allows centralized control of the saga or workflow. The orchestrator or conductor could be centralized for all the sagas or workflows, or could be distributed as individual services for each saga or workflow. This provides varying levels of independence to each microservice.

Tight Coupling, Choreography and Orchestration

To understand how these models work, consider an example of a group of dancers dancing on a stage. The dance looks appealing when all the dancers coordinate with each other well. Each dancer could be doing their own moves, but they coordinate with each other to make the overall dance look appealing.There are several ways in which these dancers could coordinate.

One way for the dancers to coordinate with each other is for all the moves of each dancer being rehearsed and predetermined. Each dancer closely watches other dancers and knows each move made by them. If one dancer makes a wrong move, all dancers will get affected and the entire performance may suffer. This is an example of Tight Coupling.

Another model is to allow each dancer to move independently, but have a predefined set of cues for the dancers to coordinate with each other. These cues are like signals that the dancers watch for, and coordinate their moves based on the cues.The cues are defined and agreed upon before the actual performance. Each dancer is free to perform their own moves during the actual performance and only provides cues to other dancers. This allows the dancers to be independent but still makes the entire performance properly coordinated. Even if one dancer makes a move that other dancers do not know, the overall dance still works well as long as the cues are provided properly. This is an example of Choreography. This model works well when the predetermined set of cues can be well defined.

The third option is to appoint one dancer as a conductor or orchestrator. The conductor or orchestrator communicates to all other dancers to coordinate the dance. All other dancers depend upon the conductor for their performance. This is an example of Orchestration. This model provides the maximum level of control to the conductor, but also makes the conductor a single point of failure.

Finding the Right Balance: In the Orchestration model, the conductor can provide different levels of independence to each individual performer. Sometimes, all moves can be controlled in tightly controlled sequences, while there could be sequences where individual dancers are provided more freedom to improvise. It is this factor that can be leveraged to provide a meaningful balance between Choreography and Orchestration. Thus, Orchestration provides flexibility to an architect that can determine the levels of control and independence based on business use cases.

Similar to the dancers coordinating on stage, multiple microservices can also be coordinated using tight coupling, choreography or orchestration.

1. Tightly Coupled: All microservices directly call other microservices for coordination of their activities. This makes the application brittle and difficult to change or scale. Any change in one microservice requires all upstream and downstream microservices to change.
2. Orchestration: A centralized orchestration layer is created where all coordination logic is centralized. This orchestrator could be centralized for all sagas or workflows, or there could be separate orchestrators for each saga or workflow. The orchestrator coordinates between all other microservices that participate in the saga or workflow.
3. Choreography: Allow each microservice to perform independently, but provide a mechanism for them to cue each other based on events. This model provides the best balance between independence of individual microservices while providing seamless interaction between them.

One important factor that differentiates the above options is the nature of control between individual microservices. The first option does not provide any such control. The second option is referred to as Orchestration, while the third is Choreography. The following section describes these patterns in further detail.

Tight Coupling, Choreography and Orchestration in a Microservices architecture

When we implement Choreography under Microservices architecture, we will have one service calling another and another service would call the third one, so on and so forth.

But there are several disadvantages in performing this:

1. You have multiple point-to-point communication
2. Each one will be 100% dependent on the other one
3. There may be complex failure implementation to handle
4. For example, service “D” fails and as a result of that service “B” fails, then ultimately the end result will not really work
5. It is incredibly difficult to debug the entire process. If any one service fails you will not know where to look for the failure
6. Testing will be a challenge because you will need all of the services running at the same time to be able to test. Due to all the dependencies you will have a heavy dependency structure.

Now we talk about implementing Orchestration under Microservices architecture. In that scenario you have an event stream where the upstream microservices will publish events and then downstream microservices will listen to them. But this particular implementation is on the grey side and certain solution architects consider it as more of choreography vs orchestration. Since there is a central authority involved which is the event queue, we can consider it as orchestration.

Another approach is where you develop a composite microservice, which coordinates all the service calls by itself so the frontend will call the composite service and it would take care of all the other services.

But again with the Orchestration approach you may encounter certain advantages and disadvantages:

1. The boundaries of each microservices are very well confined; each one of them has to only deal with what it does. There is, of course, a loose coupling involved.
2. No service is really dependent on another one, all it does is, creates events or calls and then forgets whether it responds or not.
3. When you scale up these services you scale with errors in mind.
4. So if anything fails you know for what reason it has failed and testing, that is the most important aspect with which you can test all of these independently because, You don't have to really worry whether the other service really took care of it or not.

Hence you implement orchestration or choreography in your microservice architecture, you will solve a problem but create two new.

Challenges with current Microservices architecture

New architecture that involves microservices has its own challenges. Camunda, the company behind the orchestration framework, did a survey with their customers and asked them the pain points in implementing microservices architecture especially related to workflows.

The two biggest problems that emerged were:

1. Lack of visibility across workflows so the company needs to know the instances of their workflows, how many of them run per hour, or if it's on a high scale, how many will run per min. Additionally how many workflows have failed and what was the reason behind failure. If there are any exception scenarios that are being missed. So, whether you implement orchestration or choreography this problem is prevalent.
2. Another aspect is the ambiguous error handling so if say one server has raised the event and the other couldn't process it, the message will be lost in the no man's land. And we run into a situation where, one party will assume the other would take care of this exception and the other assumes the first one will take care of it but then no one really takes care of it. So these are the two most prevalent problem areas.
3. Third major challenge is scaling, the typical workflow engine the way they are implemented they use databases behind them. Scaling up is a problem when you have a lot of disguise. So that was another problem. For example Amazon has to implement microservices and if they have to implement workflows’ there are thousands and thousands of orders that get placed and they have to be processed really fast. Hence, scaling up is a major challenge with traditional services.

Whether you choose Orchestration or Choreography these challenges will remain prevalent while implementing Microservices. Few comments on the StackOverflow discussion page say that companies need to focus on the business logic. Where a single point of logic does the job, you perform Orchestration. Where a problem cannot be covered by a centralized logic, you perform Choreography.

Talk to our expert today to know more about Microservices Orchestration and Choreography and how you can implement Microservices architecture with Orchestration or Choreography for your business.