Microservices Orchestration vs Choreography | (Technology)
Understand the art of designing the architecture for your next project
Let me start by saying that most of the technology industry has already been following microservice-based architecture, as compared to Monolithic architecture. Actually, there were many challenges while adopting the monolithic architecture which gave rise to microservices. In monolithic, the entire application was very tightly coupled. Tight coupling is like a boon for any software project unless the project is built just to say “Hello world”.
The technical goal while building any successful project is to make it scalable and secure. The microservices give us the freedom to make the product scalable, fault-tolerant.
Surely, we will try to understand the microservices orchestration vs microservices choreography before jumping directly to the difference between them both. We will discuss a bit about the microservices and their use.
The article will have a lot of useful content, so pay close attention.
Microservices can be easily defined as a collection of services that can run as a standalone application. There are a plethora of benefits that a microservice can provide. For any first time reader, consider it as a football match, each player is given an individual responsibility, they all work together in harmony but are capable enough to play alone just like a microservice.
We can increase the capacity of any player by making him practise more, individual players getting injured won't impact the entire game. The player can be replaced with another player. Similarly, in the case of microservice, we have the freedom to pay attention to the service that is behaving absurdly, instead of checking the entire application.
While following microservice-based architecture each service can be scaled optimally based upon the load. We don’t have to upscale the entire application like frontend, middleware, backend etc. This saves a huge amount of infrastructure cost.
Microservice are fault-tolerant if implemented properly. Each service can be managed by a separate team based on the complexity of the project. Scalability isn’t a concern with microservices. Deployment is totally separate from the application which makes it a better choice. In the worst case, only that particular application can go wrong instead of the entire application.
I hope that I feel this is a fair enough understanding about microservice, as this article is more about cicroservice orchestration and choreography than just microservices. Let’s not divert much with the agenda.
Microservices orchestration is a logical entity, which helps in managing the micro-services.
As we already know about micro-services, and their pros and cons. It is time to understand the ways in which we can communicate amongst the microservices. Once we have a couple of micro-services running for our project, it is of course required for them to share data and build business logic.
Orchestration is one of the ways to do it. Orchestration runs off the concept of the orchestra, where there are multiple musicians who are masters in playing their instrument, which is a service in our microservices architecture. The conductor of an orchestrator gives direction to everyone, about the nodes.
The players(Services) are capable enough in themselves to play the entire song as they have the notes(Business logic) of the songs to be handy with them. But to play the music (Project) together, in a symphony they need a conductor to manage everything.
Likewise, the microservice orchestration work in a similar fashion, when a parent service manages the request. It redirects the request to the respective service and collects the data. The final response is generated in the main service called orchestrator which is then given to the client application.
The role of the orchestrator is to communicate with each service that is required to fulfil any API request.
Microservices choreography on the other hand is altogether a different approach to communication amongst the microservices. Choreography as the name suggests each individual actor has their own responsibility and also knows the drill.
There are multiple patterns for designing microservice architecture, one such pattern is the Saga pattern which can be used to design microservice architecture, either following choreography or orchestration.
In choreography, microservices works in parallel, unlike orchestration. The entire system work on event-based architecture, where a service collects data from a message bus and perform the business logic and in return submit data to another message bus.
This approach fails tolerance if implemented correctly, as each service work on its own. If in case any one of them goes down we are aware of
which service is causing an issue, and can directly work upon that.
In microservice choreography, there are multiple topics to which a service subscribe, and update another topic. The task of the microservice is defined, and it just checks if the topic is empty or not. Unless the topic is empty, it keeps performing the task it is supposed to do.
Microservice Choreography Vs Orchestration
The main difference, between microservice choreography and orchestration, is that there is nothing central in the case of choreography. The adoption of any one of them depends upon your use case. If you want very frequent communication amongst the service then you must opt for orchestration otherwise choreography is a better option.
In the case of orchestration, we need to have proper logging, otherwise, it will become very difficult to find which service failed in returning the correct data. Logging the error is always the saviour.
Mostly architect uses the amalgamation of both approaches to create the final architecture design, which makes the entire system resilient. Various operations are synchronous in nature, while others are asynchronous, so both of these approaches are required to make your product fill proof.
Before understanding microservices choreography versus orchestration any software developer should understand what is microservice architecture.
Once you are well through by creating a couple of microservices now is the time to follow either one of the approaches. This article was intended to explain the difference between both of them. A lot can be researched about microservices and designing their architecture.
Parallelly I am also constantly researching various other options like Netflix Conductor, Saga pattern etc., for which I will definitely share my learning with you.
Meanwhile to keep yourself updated about future articles consider following me, you won't get disappointed. We will grow together.
About The Author
Apoorv Tomar is a Software developer and part of Mindroast. You can connect with him on Twitter, Linkedin, Telegram and Instagram. Subscribe to the newsletter for the latest curated content. Don’t hesitate to say ‘Hi’ on any platform, just stating a reference of where did you find my profile