Do you Orchestrate OR Choreograph?

If you have to derive an architecture for a new application in an enterprise, how would you respond to a question if one asks that which one do you choose "Orchestration vs Choreography" w.r.t building & connecting services?

Do you say that Orchestration of Services is Better? You might be scared that people might think that you are not ready to adopt the latest technology benefits?

If you say that the Choreography of the services is much better? Then again you might be scared that people might think that you don't have a proper understanding of traditional software standards to build the required Enterprise Architecture?

What if you say that "We need both of them" then you definitely feel that people will be mad at you if you have to wear the cap of an Enterprise Solution Architect!!

The possible reactions for the same question might change when you need to transform an existing architecture to a modern target architecture right?

Enough, too many questions? I know that this question might confuse you if you are new to the world of micro-services on a cloud!

In this article, we will understand this question and try to answer it with some basic/minimal understanding.

Let's try to understand what is Orchestration and Choreography?

Orchestration of Services

From the web - "The Control or coordination of the elements of a situation to produce the desired effect, especially surreptitiously"

Let's understand from an example if you consider an e-commerce application where you need to buy some product, you need to place an order to get it delivered. So here, if we can identify there are three major processes which are included, Order, Credit Check & Shippment Process.

Service-Oriented Architecture (SOA) & Enterprise Service Bus (ESB)

If we need to build this process to fulfill the service, we can think of Service Oriented Architecture (SOA) to coordinate these services using Enterprise Service Bus (ESB) as shown below

Here service orchestration means that how we build the communication among these services via Integrated Service Bus(ESB) to build the required coordination. Here ESB should know(get control) about the service which it should communicate (kind of tightly coupled) to fulfill the end-to-end service.

Monolithic Pattern (Architecture)

Nowadays it's been called 'Monolithic Architecture' where multiple application services within a single instance using a service bus to build communications using a layered architecture as shown in the below diagram.

As everything in a single instance doesn't mean that it is not scalable (in today's world w.r.t containerization technology) but it is easy to develop, test, scale, and test. As you expect, there are some cons with this architecture depends on the context of a business(particularly given the e-commerce example).

As usual, every architecture does have pros & cons right? Before we compare or get some deep insights about this, let's now understand what is choreography of services?

Choreography of Services

From the web - "The Sequence of Steps or Movements"

It sounds equivalent to orchestration right?

I would say it has a similar meaning but from my point of view, choreography represents the interactions between multiple services whereas orchestration describes the control of one's perspective to establish the communication. To get more understanding, in the above example, the middle man(ESB) controls everything w.r.t where to locate and communicate with each service in its own understandable way.

In simple terms, we can view the choreography of services as per the below diagram for the given example.

This choreographic way of designing the applications for an enterprise derived so-called, Microservice Architecture to adopt the technology benefits w.r.t scalability, operability & flexibility. The major benefit from this architecture is to get faster deployments which are unlikely in the above architecture (SOA) as if you need to do a change in service then you must need to test and deploy the complete application base but whereas is in Microservice architecture, you simply do the change for your service (ex - Order service) and deploy it seamlessly as its isolated service without affecting the other services in the enterprise.

There could be many arguments stating the above and experts do also say the perfect implementation of SOA is so-called Microservice Architecture. Let's not get into that mode of debating here but one can get enough understanding if they do deep-dive analysis!

Microservice Architecture

What is Microservice? Just put it in simple terms it's a single responsibility service with its own boundaries that does only one thing. For example here, order service can only how to handle only order-related services and contain its own database to store the same data which can't be accessible to other microservices running enterprise event buses. Oh, wait, what is Event Bus here? As we understand the basic meaning of Microservice, we need a communication channel to perform choreography right? That's where we have Event Drive Architecture (EDA) evolved.

Event Driven Architecture

It talks about how microservices can communicate with each other by exchanging what they are up to. For example, in our order fulfillment application, the order microservice can raise events like OrderCreated, OrderValidated, OrderCancelled and etc kind of events to this enterprise event bus where other interested microservices can subscribe to it. Here the Account Credit check service can subscribe to the OrderPlaced event to check the requested quantity of product and credit exists to fulfill the request where in turn it can raise an event called CreditCheckPassed.

So Event Drive Architecture states the principles/patterns as per the given enterprise state.

In our example, if you look at the below representation, each microservice has its own database and communicates with others via Events.

As stated, these microservices are scalable and flexible which can run on any platform as they use cloud-native technologies like Docker, Kubernetes &, etc.

Following is an example of our application(Order Delivery) architecture on a cloud. One can access this order service(REST API) via API Gateway to build the portal using some front-end frameworks like Angular/React/etc based on their devices.

Summary

So coming back to our initial question, do you choose Orchestration or Choreography pattern to develope an architecture?

From my insights, there is no right answer for it. One must be careful and do the properly structured way of thinking depends on the type of business, availability of services (On-Premise vs Cloud) and Customer Experience &, etc.

Examples like Amazon, Netflix & major service providers are evolved from monolithic patterns to microservice patterns as they make sense for their business operations but may not be valid for large complex businesses.

P.S - This article is just to share my thoughts, insights & opinion but may not concretely state what one should follow. At last, there is no hard rule that every service should be on the cloud to implement EDA (Microservice Architecture) or to do choreography. There are cloud tools like MS Event Bus, Amazon EventBridge, Solace &, etc which follow EDA principles using widely known native platforms like Apache Kafka, RabbitMQ &, etc.

#StaySafe #StayHome

Kondala Rao Thota