Letting Microservices dance to the tune of…
An enterprise-class application often has multiple disparate systems which work toward a common goal of giving an unmatched experience to its end users. The components working together can be part of the same umbrella or maybe some are controlled by third parties. And if we have to relate this with today’s approach of building such systems, one thing that pops out would be, is to have such an application with multiple microservices with each having its own purpose, its own reason of existence.
Architects and Designers spend a considerable amount of time deliberating the right approach of splitting the services and wiring them up in such a way that the integration and the data flow between them become smooth. As said before this is an intense step in determining the right combination for the task at hand and has to be bang-on or else the repercussions could be huge and therefore it is advisable to have a team of experts especially with some prior experience who can ask the right set of questions, can set right set of expectations, can take the right set of assumptions when talking to business owners, users, and various other stakeholders.
Calling the shots
When talking about an enterprise-class application with multiple microservices within its scope, it is imperative that all these services must work together as a unified system and for that to happen they need to stay and work with each other in harmony! Getting to the ultimate state where the services becomes autonomous, they are proactively instrumented, they generate alarms, they auto-heal themselves are some of the goals that we should aspire to and inorder to achieve them we need start well and splitting the services properly and coordination between them plays a vital role.
Let’s try to spend some time in this article to understand how the coordination between services is planned, executed and what each such approach brings to the table and the things we should be wary of!
Orchestration
It is a technique in which the microservices talk to each other with one central controller in between. This controller is responsible for calling the shots and decides what all microservices should be involved in any given workflow. This is a mode that works much like a Conductor giving instructions to musicians who are well versed in playing their instruments. The Conductor in an orchestra controls the overall performance of the band, similarly, in the Orchestration mode, there is a microservice that dons the hat of being a Conductor and runs the show.
As visible in the diagram below, Microservice A and Microservice B are the controllers here and acts as an orchestrator
Why Orchestration?
- Centralized control that leads to simplified management of the workflow
- Logging and Monitoring the workflow becomes easier
- Synchronous nature of Orchestration makes the coordination of flow more efficient
and Why not?
- Tight coupling between the services leads to an overly interdependent system, and any failure in any of the services can lead to drastic implications and can even bring the entire system to a halt
- With Orchestrator controlling the show, it acts as a single point of failure, in the events of it going down, the entire system could be at risk
- Over dependent on one mode of communication can at times makes the implementation overly in favor of REST
- With large number of microservices in the system, and with multiple flows converging to single microservice can lead to scaling and performance issues
Choreography
This technique on the other side doesn’t prefer a single controller to lead the show, in fact all the services in the enterprise application act as autonomous and can work independently of each other. However, each service knows how to handle the messages coming from other services, they are aware of the syntax and semantics of processing them. It is like a group performance where each performer knows about the steps that he/she has to take to make the entire performance, a hit! As and when each microservice receives a message and knows that the message is valid, it triggers the appropriate workflow and would then emit an event via message broker and that’s it. The job of the microservice is, by and large done, post this.
Why Choreography?
- Reduces coupling between services and thereby dependency
- More flexible and agile development
- Not anymore single point of failure
- Easy to plugin new microservices into the overall ecosystem
and Why not?
- Scale and complexity of the overall application grows especially when there are a significant number of operating services
- This also leads to decentralization of the business logic as there would co-exist mini-functional owners in form of different microservices
- There is a paradigm shift from conventional synchronous style to the asynchronous style of design and development
Middle Ground
As we can see, there are pros and cons of both Orchestration and Choreography and hence we should be pragmatic in our selection for architecting any system. A common ground could be to mix the best of these two approaches and build systems on top of that! This approach wouldn’t only suite in cases where we are building a fresh system from scratch but in case where we are re-architecting or doing adjustments in the existing application.
