Guest post originally published on the Sparkfabrik blog
Orchestration vs Choreography: Many factors need to be evaluated in order to figure out which approach is the most appropriate. Orchestration, Choreography or a Hybrid Approach: Let’s delve into how each of these approaches work as well as their pros and cons.
Microservice architecture stands in contrast to Monolithic architecture, bringing with it new requirements: for example, the need to create a system for running microservices together. Within this framework lies the choice between two different approaches: Orchestration vs Choreography.
In this analysis, we’ll first take a step back to clearly define the context. We’ll then take a detailed look at how the two approaches (Orchestration and Choreography) are structured. Finally, we’ll try to understand to what extent it’s possible to use either, in which situations they can be applied, and what their limitations are.
Orchestration vs Choreography: A revolution in microservice architectures
Cloud Native applications are almost always built as a set of microservices that run in containers (e.g., Docker) and can be managed and deployed with DevOps and CI/CD (Continuous Integration/Continuous Deployment) workflows.
There are several options. One option is the “serverless” model, offered by AWS Lambda, for example, which executes blocks of code in response to certain events, and automatically manages the underlying processing resources.
Returning to microservice architecture, its advantage lies in subdividing the application into a series of module and reusable services. Small, lightweight, and easy-to-implement services result in lower development and modification costs and allow for quick and easy scaling.
To make this system work, a method of coordination is needed to allow microservices to work together. There are basically two approaches: Orchestration and Choreography, English terms that not only correspond perfectly to the Italian equivalents of “orchestrazione” and “coreografia,” but also reflect its meaning from a performing arts perspective.
Of course, like all analogies, this one is not perfect, but it captures the fundamental difference between the two approaches. The orchestra has a conductor who tells the musicians what they need to be doing minute by minute. Choreography, on the other hand, is conceived and laid out by the choreographer beforehand and, during the performance, the dancers move about freely. They’re not controlled, but can improvise on what to do from time to time based on the choreography they’ve learned and the music that’s playing.
What is and how does Orchestration work?
As we have said, and as the name suggests, Orchestration is based on the idea of a central system that controls all the interactions between the various elements of the system (i.e., the microservices).
In this approach, the keyword is “supervision” or the monitoring of compliance with individual instructions. In Orchestration, in fact, there’s a service that acts as a controller and handles communications between individual microservices. Doing so ensures that each service performs its assigned part.
The controller serves as middleware, i.e., software that provides applications with common features and services. Generally speaking, we can think of middleware as the connective tissue between the various layers of the application. In the particular case of Orchestration, the middleware component acts as a supervisor who controls the interactions among the various microservices.
Orchestration can be used for a wide range of tasks. For example, Kubernetes allows orchestrated resources to be managed declaratively by abstracting from the underlying physical layer, so they can be managed as a single pool of computational resources.
Management of the declarative configuration is done via a control loop. Just as a thermostat does in a room, when the desired state is determined, the thermostat checks the current state and brings it as close as possible to the desired state. In the case of Kubernetes, controllers observe the cluster and when necessary, they make or request changes to the current state.
In summary, the “orchestrated” approach is based on the idea of creating a centralized and well-organized business process management (or BPM) system that can provide stability to the application and make its status easily measurable and modifiable.
Orchestration tools
As we’ve mentioned several times, Kubernetes is the best-known example of an orchestrator. Of course, there are other types of middleware which address the same function in similar ways: Docker Swarm and Mesos are two other popular examples.
The Cloud Native Computing Foundation (CNCF) that manages the Kubernetes project actually supports the development of other orchestrator projects as well, but they have varying degrees of maturity. Crossplane is in the advanced incubation phase (preceding the actual release, i.e., the Kubernetes layer), while as many as five orchestrators are still in the early stages of development: Fluid, Karmada, Open Cluster Management, Volcano and wasmCloud.
Leggi anche: Kubernetes Operators: what are they? Some examples
Limitations of Orchestration
Let’s now take a quick look at the disadvantages of the Orchestration approach.
LATENCIES AND SERVICE AVAILABILITY ISSUES
In orchestration, the controller must communicate directly with each service in order to tell it what to do. It must then wait until communication is established and the service responds.
When the architecture consists of hundreds or thousands of microservices, it can create problems with service availability or excessive wait times.
There’s a limit beyond which a central controller can no longer efficiently manage this type of architecture. In this case, it’s as if a monolithic application had been created within a distributed environment.
TOO MUCH DEPENDENCE BETWEEN MICROSERVICES
Orchestration creates a strong dependency between individual services, especially when they act synchronously. One service must respond explicitly to another’s requests.
When relationships involve such tight coupling, any break in any link in the chain can bring the entire process to a halt. In an enterprise environment, with thousands of microservices being used for a single business function, the one-to-one approach isn’t scalable.
RESTFUL API AND DIFFICULTIES IN SCALABILITY
Speaking of scalability, the third issue with the Orchestration approach is the use of RESTful APIs, which are themselves closely related services. RESTful APIs are defined by a set of architectural constraints for distributed systems. They communicate via HTTP in a stateless mode for sharing resources uniformly and using universal syntax and a global identifier.
In our opinion, the use of RESTful APIs results in securing an even stronger coupling of services within the architecture, thus increasing the cost and impact on the API of the feature to be added or removed. Again, ultimately, the problem is scalability.
The Choreography approach: What it is and how it works
Choreography uses a completely different and fundamentally decentralized approach. Returning to the metaphor of the dance troupe, it can be said that the choreography of the services is not performed, but rather staged.
By this we mean that staging occurs when participants perform their roles independently. No one element executes an explicit order; rather, each knows a set of actions it must perform in relation to the other elements with which it interacts.
The choreographic approach is based on the idea that a central control element, the orchestrator (i.e., middleware such as Kubernetes) is redundant. The individual components, i.e., microservices, must be capable of self-managing without external intervention and coupled in a loose manner (loose coupling) and not in a tight manner (tight coupling), in other words, in a general and not too tight manner.
This means that the loosely coupled microservices must be able to provide the greatest possible value to the business on their own, without directly impacting other components. In this way, its complexity is reduced because there is no controller to program and manage. Additionally, as one might guess, there is no single node, i.e., a potentially critical element for the entire infrastructure in the event of problems.
But how are messages exchanged between microservices in the absence of middleware?
In a Choreography approach, a component called an “event broker” (or message broker) is used. Choreography occurs according to a sequence of steps. Each microservice that has performed an action sends a message via certain channels. Other microservices, subscribed to that specific channel, receive the message. At that point, they themselves know what to do because they’re designed to respond automatically to certain events (event driven).
In this sense, communication occurs asynchronously, and, returning to the analogy of the choreographed dance, coordination takes place between dancers (the microservices) who listen to the music (the Event Broker) in order to dance.
Using loose service coupling logic allows microservices to be changed (added or removed as necessary) without rendering the underlying logic unserviceable and in need of being rewritten.
Choreography Tools
As with orchestration, a number of solutions are also available in this area.
At the heart of a choreography-based architecture is the event broker we mentioned earlier. This deals with the actual decoupling between the various microservices. Some examples of event brokers include Kafka, RabbitMQ and Amazon SQS.
Furthermore, service-mesh such as Istio or the relatively new runtime system DAPR can be nicely integrated into an event-driven architecture.
Limitations of the Choreography approach
We’ve seen that Choreography is one way to automate the exchange of asynchronous messages between microservices. It uses distributed, event-based control logic optimized for process automation across various domains. It presents the advantages of eliminating single points of failure and can be scaled without a loss in performance. You can also change processes without causing the app logic defined by microservices to lose effectiveness.
However, a choreography-based approach also results in some critical issues. Let’s take a look at them below.
A MINDSET SHIFT IS A PREREQUISITE
The need to shift one’s mindset and way of thinking about the operation of microservices is a prerequisite. In this sense, we can consider it a limitation. The Choreography approach isn’t an option for everyone.
MANAGING THE ENTIRE PROCESS IS MUCH MORE DIFFICULT
With choreography, the business process is literally scattered across various microservices, each of which has greater autonomy because it’s more loosely coupled to the others. This makes it more difficult to maintain the overall view, i.e., the overall process, and to manage it.
HIGH COMPLEXITY
Finally, the major limitation of the choreographic approach to microservices is its complexity. Each service identifies its own logic and reacts independently based on the messages that are coming from the channels it’s listening to. There’s a high risk of failure in trying to make this architecture work.
The third way: the Hybrid Approach
A third path to microservice management is based on a hybrid approach, one that contains both synchronous and asynchronous components.
The hybrid approach involves a centralized element — based on orchestration — regarding individual services and a choreographed element in terms of how services communicate with each other.
This approach allows the orchestrator to be used for better visibility and control of the microservices, while choreography is used to execute the workflow of individual microservices separately and independently.
LIMITATIONS OF THE HYBRID APPROACH
As with orchestration, the limitations of the hybrid approach stem from the fact that the orchestrator is strongly tied to microservices.
If the coordination system has a problem, it impacts the entire system. Additionally, it’s more work to make changes in logic or to modify, add or delete microservices.
Orchestration vs Choreography: Which is better?
When it comes to systems architecture, the best approach to choose is always “it depends“. Orchestration presents a number of advantages and a few disadvantages, as does Choreography.
So which one should you choose?
In light of the benefits and limitations we have discussed, it’s clear that the decision must be made based on several factors. The type of project to be implemented, the business needs, the goals to be achieved and the team and resources available will all impact the decision.
In principle, if we want to promote the scalability of the project and are prepared to handle a high level of complexity, we might consider the Choreography approach.
Conversely, if our priority is to gain control so the application will be more stable and more easily measurable and modifiable, we should consider the Orchestration or Hybrid Approach.