The Benefits of Microservices Choreography vs Orchestration

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; in orchestration, one service controller handles all communications in a tightly coupled, synchronous manner, while in choreography, an event broker handles messaging in an asynchronous, loosely coupled manner.

A good analogy for looking at microservices orchestration vs choreography is music and dance; 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.

The adoption of microservices is growing rapidly, as evidenced by a study from Dimensional Research on behalf of LightStep which found that almost all the surveyed senior development stakeholders who have deployed microservices expect it to become their default application architecture.

That said, there are many challenges associated with the implementation of microservices – many related to how microservices interact with one another to achieve a business outcome. Choosing between microservices choreography vs orchestration will make a difference in how seamlessly the services function behind the scenes and whether you succeeded in building a microservices architecture or distributed monolith.

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.

Reliance on RESTful APIs

An orchestration approach also relies on RESTful APIs — which are typically created as tightly coupled services — so using them can actually increase the tight coupling in your architecture. Plus, building new functionality comes at a high cost and has a high impact on the API.

So if RESTful APIs and orchestration can’t scale, what does a solution look like for deploying and managing microservices? The answer will take us out of the orchestra pit and onto the stage…

Why RESTful APIs Can’t Compete with the Event-Driven Approach to MicroservicesA look at the benefits of an event-driven approach for microservices and the limits of tight coupling and orchestration with RESTful APIs.Read Now

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 labor 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.

Teach Your Microservices to Dance

The time has passed for a RESTful API-only approach – for architecture that delivers business services faster and more reliably, and that scales with ease, a better approach is to choreograph the microservices interactions. As event-driven architecture and microservices sweep across your software development landscape, a choreographed approach to communication between services will save your company time and money while improving the experience you offer your customers.

Want to learn more about enabling event-driven microservices? Find more blogs and videos (some even featuring yours truly) in the microservices section of our Resources Hub. You can also download the The Architect’s Guide to Event-Driven Microservices for more information.

The Architect's Guide to Building a Responsive, Elastic and Resilient EnvironmentSr. Architect Jonathan Schabowsky addresses the challenges of microservices architecture and shares his perspective on the modern messaging integration patterns architects can leverage.Download Now