Orchestration vs Choreography

 Microservices architecture — a software design paradigm in which an application and business use case is broken up into a set of composable services — promise many technical benefits to enterprise organizations. First, they’re small, lightweight, and easy to implement. Second, they enable reusability that reduces the cost of developing or changing applications, ensures the efficient use of resources, and makes it easy to scale applications on demand. At a high level, there are two approaches to getting microservices to work together toward a common goal: orchestration and choreography.

Orchestration entails actively controlling all elements and interactions like a conductor directs the musicians of an orchestra, while choreography entails establishing a pattern or routine that microservices follow as the music plays, without requiring supervision and instructions.

How Orchestration Can Kill Microservices and Create a Distributed Monolith

In an orchestra, each musician is awaiting command from the conductor. They are each an expert at playing their instrument, whether it be a violin, bass drum or clarinet, have practiced ad nauseum, and have the sheet music for their part – and yet they’d be collectively lost without the conductor.

In orchestration, one service controller handles all communications between microservices, and directs each service to perform the intended function. In our symphony example, the function would be “play the music.”

Disadvantages of Microservices Orchestration

One disadvantage of orchestration is that the controller needs to directly communicate with each service and wait for each service’s response. Now that these interactions are occurring across the network, invocations take longer and can be impacted by downstream network and service availability.

In smaller environments this may work fine, but things fall apart when you’re talking about hundreds or even thousands of microservices. You’ve basically created a distributed monolithic application that’s slower and more brittle than those of the past! Just like a conductor would lose their ability to effectively manage a massive orchestra, because each musician is awaiting individual attention, its not viable to ask a service control to manage that many microservices.

Tight coupling

When orchestrating microservices, you’ll find that they’re highly dependent upon each other — when they’re synchronous, and each service must explicitly receive and respond to requests to make the whole service work, failure at any point could stop the process in its tracks.

When we’re talking about microservices in an enterprise environment, sometimes thousands of microservices are applied to a single business function. At this scale, one-to-one interactions simply can’t keep up with business demand.

The Benefits of Choreographing Services with Event Streams

If conducting a symphony is a good metaphor for service orchestration, then a dance team works well for choreography. In a dance team, everyone knows what they’re supposed to be doing, and is able and required to take the right step as each beat hits.

To choreograph microservices, you need a way of exchanging messages between microservices whenever something happens – you need an event broker. The moment a given microservice sends a message, they’re done. Everything else happens in an asynchronous manner, without waiting for a response or worrying about what happens next. Each service is observing its environment, and any other service that subscribes to that channel of messages will know what to do from there.

In our analogy, the dancers (microservices) listen to the music (the event broker) and make the necessary moves because they’re all following the same choreography.

Loose service coupling for agility and fault tolerance

Adding and removing services is much simpler in a choreographed microservices architecture. All you need to do is connect the microservice to (or disconnect it from) the appropriate channel in the event broker. With loose service coupling, the addition and removal of microservices doesn’t break existing logic, resulting in less development churn and flux.

The fact that choreography isolates microservices means if one application fails, business services not dependent on it can carry on while the issue is rectified. It is also not required for each service to have complex, built-in error handling in the case of network failures since it’s the event broker’s responsibility.

With a RESTful API, errors can cause cascading problems. This can result in tasks that could have been executed being blocked by a single communication problem, resulting in idle workers. In addition, any outages result in disappointed customers and potentially, the loss of business.

Faster, more agile development

In this fast-paced landscape where time to market is critical, the speed at which you are able to develop and modify applications can have a serious impact on business. Development teams being impacted by changes to other services is a common barrier to agility. Choreographed, event-driven microservices allows for development teams to operate more independently and focus on their key services. Once these services have been created, they are now easily able to be shared between teams. This reuse of developed components is a huge savings in both labour and time.

More consistent, efficient applications

When creating a microservice that has one specific function, you’re able to create a more modular codebase. Each microservice handles a specific business function and together, as a unit, they perform the business process.

The ability to reuse these microservices as part of many business processes keeps your system consistent and makes it easier to create or modify services because you can tap into code that’s already been proven to perform a given function.