Choreographers: The key to avoiding Vendor Lock-in

In a vendor lock-in situation, where a company is significantly dependent on one technology vendor and has no ability to migrate to another, a choreography-based approach may be the solution. This alternative is a step up from service orchestration, so it is important to understand the key differences between the two.

M

aximizing flexibility through a microservice architecture 

As more companies adopt microservice architectures, developers are increasingly exposed to the concepts of orchestration and choreography, since they need to understand and choose the correct strategy for coordinating the interaction between the microservices in their applications. Each microservice focuses on a specific function and communicates with other services through well-defined signals. Any platform or application is likely to take advantage of this vision in which each microservice addresses a specific function: from employee access to notifications, billing or profile management. 

The idea behind microservices is to break down an application into smaller, autonomous parts, allowing them to be deployed independently, providing flexibility, agility and scalability. The way in which this architecture is organized will depend not only on the evolution of the system, but also on the company’s strength when faced with vendor lock-in.  

The increasingly more popular choice by technology companies to host services in the cloud benefits from the microservices architecture in many ways, although it is essential to choose wisely how to coordinate the interactions between them: through orchestration or choreography. 

Orchestration: centralized management 

Orchestration involves having one centralized component, known as an orchestrator or orchestra conductor, which coordinates and controls the execution of the different microservices. The orchestrator is basically in charge of managing the signals between the services, deciding when and how they should interact. It is in charge of ensuring the synchronization and correct sequence of operations, thus guaranteeing the smooth and coherent operation of the system. The orchestrator is responsible for detecting a need and invoking a service. From there it will receive a response, which will determine what the next step is. Based on the result obtained, the orchestrator will trigger a new service, if necessary. All phases of the process are managed with calls to the different microservices that go through the director. 

The most noteworthy advantage of this approach to technology services architecture is that it simplifies process monitoring and control. By having a centralized point of coordination, it is easier to monitor and manage interactions, as well as to obtain a global view and extract real-time information on status and performance. 

In addition, by having an orchestrator controlling the execution flow, the overall complexity of the system is reduced. Instead of having to coordinate and synchronize each of the individual services directly, the orchestrator handles these tasks. This simplifies both commissioning and maintenance, allowing developers to concentrate on the functionality of each service without having to worry so much about the coordination between them. 

If the model of interaction between services is transactional, i.e., if operations are performed that must be consistent and reversible in response to errors, the orchestrator will be able to handle exceptions or process breakpoints. This means that, if a failure or interruption occurs at any point, the orchestrator can establish recovery and transaction restart mechanisms to ensure data integrity and maintain system consistency. 

The orchestrator controls the interactions, as he is the one who “knows” the specifics of each task required to solve the various processes. For example, in a workflow involving video identification, signature of documentation and generation of digital assets, or in the case of a purchase process where payment and delivery belong to different actors, the orchestrator ensures that each step is performed in the correct order and that the customer is notified at each stage. Between steps, events are triggered and approved by the orchestrator, leading to the next step. 

It is important to note, however, that this reliance on the orchestrator can lead to vulnerabilities if breakpoints are not handled correctly. There may also be ensemble impairments if the orchestrator fails or experiences problems. 

Choreography: collaboration and independence  

On the other hand, choreography is a different approach that defines how different microservices interact and coordinate their actions. Instead of relying on a centralized controller, coordination is achieved through a set of predefined signals or events. 

These signals or events act as messages that microservices use to communicate with each other. Each of them can send or receive these signals, allowing them to make decisions and perform actions based on the information they receive from the others. The elements either communicate with each other or deposit the messages in a public area from which the rest of the services can “pick them up”. 

The key feature of the choreography is that it relies on decentralization. Each microservice works independently and autonomously, making its own decisions based on the signals it receives. There is no centralized component that directly coordinates actions, allowing for greater flexibility and agility in the system. 

This planning based on collaboration and interaction between the microservices themselves can result in a more distributed and resilient system, as there is no bottleneck to encourage errors. In addition, if a microservice is receiving a high workload, it can be scaled horizontally by adding more instances or requests of that specific microservice without affecting the overall system performance. Also, if the company decides to add, modify or replace microservices, it does not affect the system as a whole. 

Another of the most important particularities of choreography is asynchronicity. That is, when one microservice sends a message or event to another, the sender can continue working without waiting for a response. In a synchronous communication model, the sender could be blocked if the receiving microservice takes a long time to reply.  

Patricia Bazán, professor at the National University of La Plata and expert in computer science and software development, summarizes the main differences between orchestrator and choreographer in 4 blocks¹: 

• Objective: 

– Orchestrator: Compose services within the same organization to meet a specific business process.  

– Choreographer: Compose services for collaboration between different organizations. 

• Model:

– Orchestrator: Hierarchical (question – answer).  

– Choreographer: Peer to peer. 

• Focus:

– Orchestrator: Put together services and the order in which they are executed to achieve the goal of a business process.  

– Choreographer: Define the way in which multiple parties collaborate to create a business transaction. 

• Basis:

– Orchestrator: Constitutes a service in itself.  

– Choreographer: Defines the interaction between services. 

Clearly, companies relying on cloud computing can opt for a hybrid approach, combining both the use of an orchestrator and choreography. The orchestrator could coordinate and control certain aspects of the workflow, while the choreography would be used to enable collaboration and communication between microservices in a distributed manner. The orchestrator can be especially useful when there are dependencies or strict rules to be followed in the process and the choreographer in those phases that require quick and direct actions. 

Avoid dependencies and lock-ins 

When looking for a solution that alleviates or avoids vendor lock-in or vendor dependency, certain aspects should be considered, such as which of the approaches studied is based on this solution and which is the most appropriate. 

With a choreography solution, each microservice can be replaced or upgraded independently, without affecting the entire system. This means that if changes or replacements are needed, they can be made without affecting the overall functionality of the system. In an orchestration solution, microservices are tightly coupled to the orchestrator, making it difficult to replace or update individual components without affecting the overall system. 

It is likely that orchestration will cause the concerned organization to go back to square one, tying it to the specific vendor that provides the orchestrator. However, choreography, orchestrator of orchestrators, by allowing each microservice to operate independently, without relying on a particular vendor, will prevent hijacking and provide more freedom for the company to choose and change individual service providers as needed. 

¹ La orquestación de servicios y las aplicaciones actuales (Service orchestration and current applications) | Patricia Bazán. Published by Universidad Nacional de La Plata, EDULP. 2021