Why microservices orchestration is important to modern tech stacks

Microservices architecture enables developers to break down the functionality of a website or a single application into a framework of smaller, loosely coupled services. Each service performs its own part in that framework, forming a collective ecosystem of services that determines the user experience. 

Since microservices are only loosely coupled, it’s easier to scale up a single service rather than scaling the entire application, with independent teams able to focus on a single business process without necessarily having to understand the big picture. These teams can use different programming languages, and frameworks of their choice, with communication between microservices facilitated via application programming interfaces (APIs).

The effective management, or orchestration, of microservices within a larger ecosystem is critical to the success of the website or app that they are part of. With that in mind, in this post, we’re going to take a closer look at microservice orchestration, and the benefits it can provide for modern tech stacks.  

What is microservices orchestration?

Microservices orchestration refers to the management of the communication and interaction between different microservices, as part of a tech stack. 

When you start to model more complex logic, you need to have a clear understanding of the business scope and business requirements of the larger project. You cannot simply create websites and applications by randomly connecting different microservices — you have to understand how you will manage the necessary business processes, and how your microservices will communicate with each other.

So how do microservices communicate?

Using a microservice ecosystem is a little bit like going to the ballet, the opera, or a concert. In these settings, artistic elements align to create the experience for the audience — venue, musicians, choreography, costumes, direction, and so on — and we often use the terms choreography and orchestration to describe that process. 

What a day full of art!

The terms choreography and orchestration can also be applied in computer science to describe the way that different components in a tech stack communicate. The terms are often used with different meanings, and in different contexts, so to avoid misunderstanding, let's define them in the following way:

• Orchestration: command-driven communication.

• Choreography: event-driven communication.

With choreography, an “event broker” component keeps individual services informed about the status of the overall ecosystem, and lets them work out the details of their own functions. Like dancers, their individual contributions are shaped by the collective choreography of the performance.

With orchestration, a central brain (Service A in the image) guides and drives the collective process directly, like a conductor in an orchestra. Simply put, one component coordinates one or more other components by sending the commands to perform their functionality. 

Key terms and concepts

In this post, we’re going to focus on orchestration, as it pertains to microservice ecosystems. Before getting into that, let’s familiarize ourselves with some terms and concepts:

Bounded context

The Unix philosophy suggests that applications should “Do One Thing and Do it Well.” This begs the important question: How do you decide the boundaries of your application’s service?

In monolithic software, where the presentation of content is tangled up in code, boundaries are difficult to discern because dependencies are bundled together and even small changes can lead to unpredictable side effects in other parts of the system.

In bigger systems, changes become even more risky and expensive to deploy — to the point that you may consider migrating away from a monolithic architecture to a microservices architecture. If you’re thinking about migration, taking a domain-driven design (DDD) can help address boundary complications. 

The DDD approach suggests that a company's business value lies in its domain knowledge (for example finance, ecommerce, healthcare, etc.) and that, by focusing on domain, we can model what really matters. DDD represents a common language shared by stakeholders, in particular domain experts and software developers, to reduce the risk of misunderstanding by reducing unclear requirements and business rules.

That process involves creating areas known as bounded contexts. Bounded contexts can be subdivided until they become granular and actionable subdomains, which can be translated into small and independent services by implementing teams. Bounded contexts form the basis for the creation of microservices.

But what is the benefit of bounded contexts?

When you align your bounded contexts with business requirements, your microservices will be more loosely coupled — which, in turn, offers the autonomy of function that development teams need to design and implement solutions for specific business needs.

As a result of that autonomy, each microservice can have its own meaning in different bounded contexts, and its own domain-focused solution, and can execute its logic without affecting other domains. 

Workflow

A workflow is a particular set of actions that compose a business process.

Workflows commonly involve multiple microservices, each with its own bounded context, and each performing its own tasks and emitting new events to downstream consumers.

The concept of workflow is important for understanding microservices orchestration. One of the principal concerns of orchestration (and choreography) is solving the problem of how multiple microservices can work together to fulfill larger business workflows, such as the product purchase workflow represented below.

Transaction

A transaction is a series of actions that must execute as a single unit. If even one of the transaction operations fails, the entire series of steps must be rolled back to leave the application in its previous stable state. For example, an airline ticket booking app typically builds several steps into the purchase process: checking for availability with the airline, booking the ticket, processing the transaction, and so on. The point is, what appears to be a unified flow on the front end, actually involves multiple connected processes under the hood.  

Event vs. command

An event is something that happened: a fact. Let’s use “Process 1” as an example of an event: in this context, microservice A asserts “Process1IsComplete” in order to let other subscribed microservices know that the Process 1 event has occurred. Here, microservice A has no expectations about what needs to happen based on the Process1IsComplete event, and other microservices may or may not decide to react to it.

However, if microservice A sends Process1IsComplete specifically to microservice B, that means microservice A wants or expects microservice B to do something. In this context, Process1IsComplete is a command, and microservice B cannot simply ignore it. 

Essentially, commands involve an expectation of a reaction, while events simply share information. 

Understanding microservices orchestration

Service orchestration implements the business logic of a microservice by invoking and integrating one or more microservices and systems.

The central service sends commands to other microservices, and facilitates coordination and integration between microservices. Following the diagram above, we’ll refer to this central service as an “orchestrator.” The orchestrator contains the entire business workflow logic for a given business process, and sends specific commands to downstream microservices to tell them what to do.

The orchestrator then awaits responses from the instructed microservices, and handles those responses according to workflow logic.

How microservices orchestration works

Imagine you want to build a new business capability: an “order service” that enables your clients to order a dress from your online shopping platform.

That will require the integration of several existing microservices, such as an inventory service, a pricing service, and a shipping service. 

You can build the business logic of the order service so that it invokes the inventory, pricing, and shipping services with the required message, and, finally, sends the response back to the consumer about the status of their order. The entire business workflow logic is self-contained within the scope of the order service.

Ideally, the process involves the following steps:

• The client clicks the “buy” button and Order Service receives the order. 

• Order Service sends a command to Inventory Service to change the dress stock.

• Order Service awaits, and then receives, a response indicating whether the stock has been successfully changed. 

• Order Service sends a command to Pricing Service to charge the customer, and awaits a response.

• Order Service receives a response from Pricing Service indicating that the customer has successfully paid. 

• Order Service sends a “ship order” command to Shipping Service, and awaits a response. 

• Order Service receives a response from Shipping Service indicating that the order has been successfully shipped. As part of this event, the client receives an order update: “Your order has been shipped.”

In this scenario, order service, the orchestrator, is responsible for keeping the other microservices in synchrony, just like a conductor would in a musical orchestra. 

The basic idea here is that loosely coupled microservices get their commands from the orchestrator, which sends a call to each service and awaits a reply before proceeding. This central service acts like a brain, driving the whole execution process. It manages the steps of processes by instructing the other services to start new steps and triggering necessary actions. 

Order service keeps track of which parts of the workflow have been completed, which are mid-process, and which have yet to be started.

In the example above, if any services fail to process, they update the order service, which would then trigger any necessary compensating actions (to undo change).

The orchestrator is responsible only for orchestration and workflow logic — it is not responsible for fulfilling the business logic of any of the microservices themselves. Order service only needs to know if a given process has completely succeeded or if it has completely failed.

Myth: Commands require synchronous communication

Downstream services can use either synchronous or asynchronous communication. When downstream services call other downstream services, that style of communication is known as service chaining. From the perspective of an orchestrator (such as the order service above), the existence of multiple-chained downstream services is irrelevant.

However, it is a myth that commands require you to communicate synchronously, leading to temporal coupling.

The difference between command and event is not contingent on whether communication is asynchronous or synchronous. Temporal coupling results from synchronous communication alone, not from the choice to use commands.

Microservices orchestration can be implemented as event-driven orchestration and direct-call orchestration, depending on synchronous or asynchronous communication between the orchestrator and other services.

In both models, the orchestrator sends commands to microservices, and all downstream microservices communicate with just the orchestrator microservice.

The orchestrator is still responsible for workflow logic in both. The only thing changing is the communication between the orchestrator and downstream microservices.

Let's look closer at both types of communication.

Event-driven orchestration (asynchronous)

In this type of communication, the orchestrator keeps a materialization of the events issued to services A, B, and C, and updates its internal state based on the results returned from the worker microservice.

Depending on the response of downstream microservices, the orchestrator can make decisions, and select the next step, according to the workflow logic.

One of the advantages of this pattern of communication is that when the orchestrator, or other downstream microservices goes down, their messages will be stored in the queue. Therefore, when problems that lead to a down microservice are solved, messages will be ready to be consumed by the consumer.

Direct-call orchestration (synchronous)

Orchestration can also use a request-response pattern in communication with downstream services. Here, the orchestrator synchronously sends a request to microservice and awaits a response. During every request, the orchestrator blocks other communication while awaiting a response. Once it gets the response, the orchestrator updates its internal state, and calls other services.

Depending on the chosen communication type, the orchestrator can keep track of event streams or response-request results in the workflow. 

Orchestrated transactions

You can revert transactions from any point in the workflow by modeling transactions as orchestrated. If one service cannot complete the transaction, you can roll back all transactions by reversing the workflow logic, and ensuring that each microservice successfully reverses its actions.

The centralized nature of orchestration means that you can monitor the progress and state of the transaction closely. If there are error messages from any of the downstream microservices, the transaction can be canceled at any workflow point. 

The orchestrator can use either synchronous or asynchronous calls. The critical point here is that the downstream service will try to perform necessary operations according to its internal logic in the first place. After its own error-handling logic, if an error still exists, it returns a failure response to the orchestrator.

The orchestrator must now maintain its rollback logic based on the current state of that response by issuing rollback commands to all required microservices. This means the orchestrator service sends commands to other required services to make them roll back their last state.

However, if there was a failure to roll back, the orchestrator service would decide what to do next. As previously mentioned, while each downstream microservice is responsible for its own retry policy, error handling, and failure management, the orchestrator is only responsible for workflow management. This is why the orchestrator should manage any failure situation by deciding on the next step in the workflow.

Ordinarily, if the transaction has been rolled back, it is also the responsibility of the orchestrator to decide what to do next to finalize the processing of that event. There are several options: retry the event a number of times, discard it, terminate the application, or output a failure event. Therefore, the orchestrator is responsible for issuing rollback commands and awaiting the microservices' confirmation. How the orchestrator finalizes the process is up to you by choosing what kind of stream you design in your application.

The orchestrated approach gives you better visibility into workflow dependencies, more flexibility for changes, and clearer monitoring options compared to choreography design. Thanks to its centralization, orchestration can also handle more complicated distributed transactions. With that in mind, if your workflow changes, and your application includes many independent microservices, it may be beneficial for you to consider orchestration design.

The benefits of microservice orchestration

Simpler dependencies

The orchestrator invokes the downstream microservices, but these microservices don't invoke, and so are not dependent on, the orchestrator. Therefore, in an orchestration model, there are no cyclic dependencies.

Less coupling

Individual microservices are connected via application programming interfaces (APIs) which are invoked by the orchestrator. This means that they can operate independently of each other, offering a greater degree of developmental flexibility. 

Reliability

Orchestration enables you to better coordinate and perform the fulfillment process. That reliability is based on the orchestrator knowing exactly which services are needed to carry out an operation, and enabling you to decide when to send commands to those services. If there is a failure at any point in the process, the orchestrator decides what to do. In this context, fault tolerance scenarios are much simpler than choreography, which uses point-to-point communication.

Scalability

When adding a new service into orchestrated microservices architecture, only the orchestrator needs to modify the interaction rules. By contrast, in choreography, all the interacting services would need to be modified.

Easy to understand

Orchestration makes it easier to understand how the tech stack, and content experiences, are supposed to work. This can make onboarding new people easier because they will typically be able to learn how to use the core system more quickly, while content managers will have less work to monitor overall. 

The drawbacks of microservice orchestration

Creating a god

The relationship between the orchestrator and downstream services must be explicitly defined because orchestration can end up creating a tight coupling between microservices. You must be sure that orchestration is only responsible only for managing business workflow, and avoid creating a “god” service that gives commands to other services because that carries a high risk of causing poor encapsulation and ill-defined bounded contexts. 

Tight coupling prevents you from scaling microservices through your diversified teams. WIth that in mind, an orchestrator should not contain business logic (as far as that is possible), but delegate business logic responsibility to downstream microservices. 

In a tightly coupled orchestration environment, downstream services may not have the flexibility they need to operate autonomously, and so just take orders from the orchestrator. It is important to understand that microservices cluster orchestrated workflows together, have their own local state, and must be strong enough to process their own business logic.

Performance inefficiencies

In an orchestrated environment, there is no direct communication between downstream microservices since communication takes place via a centralized orchestrator. This increases system latency (when compared to choreography) because the orchestrator has to manage the steps of processes by giving instructions and awaiting a response. Furthermore, system throughput is bound to the capacity of the orchestrator.

Single point of failure

If an orchestrator goes down, microservices will no longer be able to communicate with each other. To avoid this problem, orchestrators must be highly available.

Microservices orchestration vs. microservices choreography 

In choreographed communication, microservices interact directly with each other. Each service in the system understands its job and the jobs of the other services — like dancers reacting to other dancers around them in a ballet. The function of a given microservice is contingent on certain events or on receiving certain responses from other services — the microservice is not interested in events or responses that fall outside its specific focus. 

On the other hand, in an orchestrated environment, the orchestrator sends a command message to a downstream microservice, telling it what operation to perform. After this microservice has performed the operation, it sends a reply message to the orchestrator, which processes the message and determines which next step to perform.

Microservice orchestration can provide better workflow visibility because of its centralist approach. However, even if orchestration provides better visibility into workflow dependencies, more flexibility for changes, and more precise monitoring options, there is a risk to the entire system if the orchestrator is its single point of failure. 

With that in mind, developers can mitigate that risk of failure by building a monitoring system into their tech stack to track what each service does as an independent entity. Or alternatively, build out the website using both orchestrated and choreographed communication styles.

The bottom line: The importance of microservices orchestration

We have lots of microservices in our architecture. They have their own business, domain, and logic. They look good when they are alone. However, they need to serve a more important purpose. To do that, they must communicate through the network with the specific design.

Orchestration can be beneficial when the business use case requires one service to handle all interactions with other services and systems. It is usually suitable for interactive services.

In this way, orchestration enables you to put one service in charge of the other services, with the orchestrator aware of the entire workflow. If there is any problem in the overall process, the orchestrator will become aware and take actions as a result. While the orchestrator manages the process execution, it will be easier for support to fix problems and manage the entire system's development.

Take a tour

Chat with our team

We'll show you how our composable content platform can enhance 1:1 customer connections and drive growth for your business.

Subscribe for updates

Build better digital experiences with Contentful updates direct to your inbox.