For many years, the question “Choreography or Orchestration” divided the software integration world and is still not decided today.
The choreography is an integration pattern that relies on the rule “Smart Endpoints and Dumb Pipes”. It suggests that the endpoints (service, micro-services) are smart enough to fully implement our processes without any smart intermediate but just dumb pipes. At the Development level, connections between endpoints must be dumb. Our processes intelligence is only implemented at the endpoint level.
The choreography looks like a project that would hire clever people and let them work independently and concurrently, using emails (the dumb pipe) to exchange information.
The orchestration is an integration pattern based on a different rule, “Smart Endpoints and Smart Pipes”. The “Smart Pipes” are orchestrators that manage process contexts and communication between endpoints. So, processes are not limited to the endpoints but are also implemented in the orchestrators. This organisation creates dependencies between orchestrators and services but reduces dependency between services dramatically[i].
Orchestration is commonly used in projects where clever people are hired in an organisation with management and hierarchy that optimises and synchronises exchanges between the project’s partners.
Choreography vs Orchestration
The table below summarises the main characteristics of each integration pattern.
Choreography
Orchestration
Easy to set up, no need for additional partners or elements to implement processes other than endpoints.
One or more orchestrators are required to implement processes. The orchestrator can be a simple bespoke development or a more sophisticated system such as a BPEL (present in OpenESB) or a BPMN engine.
Direct or semi-direct (ex: DNS routing) connection between endpoints (services). Consequently, there is no central point in the architecture. This lack creates dependencies between services.
There is no direct connection between services but between services and orchestrators. This integration pattern creates dependencies between the orchestrators and the services. Also, a single point of failure appears when the low-level infrastructure is flawed and does not provide redundancy and high availability features. (OpenESB has mechanisms to solve this issue)[ii].
Simple processes are easy to implement with choreography.
Simple processes must be implemented at the orchestrator level. This represents extra work if the process is straightforward.
The choreography pattern does not dedicate an entity to manage the process context. Consequently, it does not supports natively multi-step conversations, process context management, compensation required by complex processes. Process management feature requires a considerable effort to be developed and tested with the choreography pattern.
One of the main orchestrator features is the management of the process context.
Orchestrators (ex: OpenESB BPEL, Oracle BPEL ) support natively multi-step conversations, process context management, compensation required by complex processes.
Choreography does not dedicate an entity to manage the business process context; consequently, the process’s context is shared by the elements implementing the process. So, when the process becomes complex and requires context management, the endpoints (service, micro-services) become stateful components. Reusing and evolution of stateful services are tricky and costly.
One of the main orchestrator features is the management of the process context. It relieves the services from the burden of context management.
The endpoints (services, microservices) remain stateless. Maintenance and evolution costs are lowered, and stateless services can be reused easily in other applications.
Stateful services generate affinity between service consumers and service providers.
Service providers and service consumers are linked by the process context. This dependency prevents your platform from scaling. Managing scalability with stateful components requires robust infrastructures, excellent monitoring, and consequently extensive resources and budget.
The context process is managed at the orchestrator level, and the endpoints remain stateless. So, it is easier to implement a good level of scalability with stateless components in your integration platform.
How do the orchestrators, which are stateful components, scale?
Recent orchestrators (ex: OpenESB) implement sophisticated scalability and high availability features and do not reduce global process capabilities.
Conclusion
Choreography relies on simple (dump) connections between services, and process implementations rely on the endpoints’ smartness. Since this pattern cannot manage process context easily, we recommend it for prototypes, POCs and simple processes.
On the other hand, even if its learning curve is sharper, the orchestration has been designed to implement complex projects and maintain stateless processes.
No offence to Lewis and Fowler[iii], “smart endpoint and dumb pipe” is a teenager illusion when implementing complex processes with reasonable budgets.
Before finishing, let’s raise the apparent objection that the choreography is very much used by the GAFA. The answer is simple: Using GAFA to validate the Choreography pattern (or any other technology) is inaccurate for us. Indeed, these companies have almost unlimited staff, infrastructure and budget and play in a different division. Their constraints, teams, and budgets are so far from all other companies that taking them as an example becomes a fallacious comparison.
[i] Fortunately, orchestrators such as the BPEL engine is designed to work with contracts of service and not directly with the endpoint. To communicate with the orchestrator, the endpoint implements the contract of service. So, the dependency between is limited to the contract (the interface) and not to the implementation (the endpoint). If many endpoints implement the contract, using it as an intermediate provides great flexibility, evolution, availability and scalability.
[ii] The OpenESB infrastructure support service redundancy, request redirection to reduce the single point of failure
Enterprise Architect at a tech services company with 201-500 employees
Real User
Aug 12, 2021
Conceptually the difference is that choreography involves two or more microservices working together( in a choreographed fashion) to achieve a result.
There are two high-level forms of choreography.
The first is Direct Choreography in which operations in one microservices direct invoke operations in a second microservice by means of a direct call.
This means, one microservice needs to know about the other (i.e. they are tightly coupled) making maintenance more complicated. This is because there is no top-level boss - they all cooperate and so inter microservice communication is part of the microservice behaviour.
The second is an indirect approach in which each microservice minds its own business but when it does something it makes it known that it did something( e.g. publish an event). It doesn't know if anyone cares, it just publishes it.
If a second microservice cares about that event it will do what it has to do.
In this way, microservices still don't need to know about each other. Each microservice knows which events it cares about but not where they came from.
On the other hand, Orchestration involves a "conductor" microservice that runs the show and invokes various operations of various other microservices. If MS O invokes MS A and then MS B then it needs to know about MS A and B but A and B do not need to know about each other.
Orchestration is a way of limiting tight coupling as well as centralizing the related behaviour logic.
The choreography describes the interactions between multiple services, whereas orchestration represents control from one party's perspective.
This means that a choreographydiffers from an orchestration with respect to where the logic that controls the interactions between the services involved should reside.
Hi! Microservices orchestration and choreography are two different approaches to managing interactions between microservices in a system. Orchestration involves a central controller that coordinates and directs the communication between services, while choreography relies on decentralized communication where each service knows how to interact with others. To understand the relative benefits of each approach in a microservices architecture, you can check out this detailed article: https://www.cleveroad.com/blog.... It provides insights into the advantages of using microservices, including scalability, flexibility, and ease of maintenance, which can help you make informed decisions when choosing between orchestration and choreography in your microservices implementation.
Business Process Design optimizes organizational operations by mapping and refining processes, enhancing efficiency and ensuring streamlined workflows. This approach leads to reduced costs and increased productivity. Focusing on Business Process Design enables companies to gain clarity in their operations and achieve improved outcomes through systematic process optimization. Leveraging stakeholder feedback, these designs help in identifying inefficiencies and creating value-driven...
For many years, the question “Choreography or Orchestration” divided the software integration world and is still not decided today.
The choreography is an integration pattern that relies on the rule “Smart Endpoints and Dumb Pipes”. It suggests that the endpoints (service, micro-services) are smart enough to fully implement our processes without any smart intermediate but just dumb pipes. At the Development level, connections between endpoints must be dumb. Our processes intelligence is only implemented at the endpoint level.
The choreography looks like a project that would hire clever people and let them work independently and concurrently, using emails (the dumb pipe) to exchange information.
The orchestration is an integration pattern based on a different rule, “Smart Endpoints and Smart Pipes”. The “Smart Pipes” are orchestrators that manage process contexts and communication between endpoints. So, processes are not limited to the endpoints but are also implemented in the orchestrators. This organisation creates dependencies between orchestrators and services but reduces dependency between services dramatically[i].
Orchestration is commonly used in projects where clever people are hired in an organisation with management and hierarchy that optimises and synchronises exchanges between the project’s partners.
Choreography vs Orchestration
The table below summarises the main characteristics of each integration pattern.
Choreography
Orchestration
Easy to set up, no need for additional partners or elements to implement processes other than endpoints.
One or more orchestrators are required to implement processes. The orchestrator can be a simple bespoke development or a more sophisticated system such as a BPEL (present in OpenESB) or a BPMN engine.
Direct or semi-direct (ex: DNS routing) connection between endpoints (services). Consequently, there is no central point in the architecture. This lack creates dependencies between services.
There is no direct connection between services but between services and orchestrators. This integration pattern creates dependencies between the orchestrators and the services. Also, a single point of failure appears when the low-level infrastructure is flawed and does not provide redundancy and high availability features. (OpenESB has mechanisms to solve this issue)[ii].
Simple processes are easy to implement with choreography.
Simple processes must be implemented at the orchestrator level. This represents extra work if the process is straightforward.
The choreography pattern does not dedicate an entity to manage the process context. Consequently, it does not supports natively multi-step conversations, process context management, compensation required by complex processes. Process management feature requires a considerable effort to be developed and tested with the choreography pattern.
One of the main orchestrator features is the management of the process context.
Orchestrators (ex: OpenESB BPEL, Oracle BPEL ) support natively multi-step conversations, process context management, compensation required by complex processes.
Choreography does not dedicate an entity to manage the business process context; consequently, the process’s context is shared by the elements implementing the process. So, when the process becomes complex and requires context management, the endpoints (service, micro-services) become stateful components. Reusing and evolution of stateful services are tricky and costly.
One of the main orchestrator features is the management of the process context. It relieves the services from the burden of context management.
The endpoints (services, microservices) remain stateless. Maintenance and evolution costs are lowered, and stateless services can be reused easily in other applications.
Stateful services generate affinity between service consumers and service providers.
Service providers and service consumers are linked by the process context. This dependency prevents your platform from scaling. Managing scalability with stateful components requires robust infrastructures, excellent monitoring, and consequently extensive resources and budget.
The context process is managed at the orchestrator level, and the endpoints remain stateless. So, it is easier to implement a good level of scalability with stateless components in your integration platform.
How do the orchestrators, which are stateful components, scale?
Recent orchestrators (ex: OpenESB) implement sophisticated scalability and high availability features and do not reduce global process capabilities.
Conclusion
Choreography relies on simple (dump) connections between services, and process implementations rely on the endpoints’ smartness. Since this pattern cannot manage process context easily, we recommend it for prototypes, POCs and simple processes.
On the other hand, even if its learning curve is sharper, the orchestration has been designed to implement complex projects and maintain stateless processes.
No offence to Lewis and Fowler[iii], “smart endpoint and dumb pipe” is a teenager illusion when implementing complex processes with reasonable budgets.
Before finishing, let’s raise the apparent objection that the choreography is very much used by the GAFA. The answer is simple: Using GAFA to validate the Choreography pattern (or any other technology) is inaccurate for us. Indeed, these companies have almost unlimited staff, infrastructure and budget and play in a different division. Their constraints, teams, and budgets are so far from all other companies that taking them as an example becomes a fallacious comparison.
[i] Fortunately, orchestrators such as the BPEL engine is designed to work with contracts of service and not directly with the endpoint. To communicate with the orchestrator, the endpoint implements the contract of service. So, the dependency between is limited to the contract (the interface) and not to the implementation (the endpoint). If many endpoints implement the contract, using it as an intermediate provides great flexibility, evolution, availability and scalability.
[ii] The OpenESB infrastructure support service redundancy, request redirection to reduce the single point of failure
[iii] https://martinfowler.com/artic...
Conceptually the difference is that choreography involves two or more microservices working together( in a choreographed fashion) to achieve a result.
There are two high-level forms of choreography.
The first is Direct Choreography in which operations in one microservices direct invoke operations in a second microservice by means of a direct call.
This means, one microservice needs to know about the other (i.e. they are tightly coupled) making maintenance more complicated. This is because there is no top-level boss - they all cooperate and so inter microservice communication is part of the microservice behaviour.
The second is an indirect approach in which each microservice minds its own business but when it does something it makes it known that it did something( e.g. publish an event). It doesn't know if anyone cares, it just publishes it.
If a second microservice cares about that event it will do what it has to do.
In this way, microservices still don't need to know about each other. Each microservice knows which events it cares about but not where they came from.
On the other hand, Orchestration involves a "conductor" microservice that runs the show and invokes various operations of various other microservices. If MS O invokes MS A and then MS B then it needs to know about MS A and B but A and B do not need to know about each other.
Orchestration is a way of limiting tight coupling as well as centralizing the related behaviour logic.
The choreography describes the interactions between multiple services, whereas orchestration represents control from one party's perspective.
This means that a choreography differs from an orchestration with respect to where the logic that controls the interactions between the services involved should reside.
https://stackoverflow.com/ques...
Hi! Microservices orchestration and choreography are two different approaches to managing interactions between microservices in a system. Orchestration involves a central controller that coordinates and directs the communication between services, while choreography relies on decentralized communication where each service knows how to interact with others. To understand the relative benefits of each approach in a microservices architecture, you can check out this detailed article: https://www.cleveroad.com/blog.... It provides insights into the advantages of using microservices, including scalability, flexibility, and ease of maintenance, which can help you make informed decisions when choosing between orchestration and choreography in your microservices implementation.