It is NOT all. There is more to it. Understand the differences and know when to choose what
What is Orchestration?
In a general sense of computing, Orchestration is often discussed in the context of service-oriented architecture, virtualization, provisioning, converged infrastructure and dynamic data center topics. Orchestration in this sense is about aligning the business request with the applications, data, and infrastructure.
Orchestration includes a workflow and provides a directed action towards larger goals and objectives
SOA, or Service Oriented Architecture, is an approach to developing enterprise systems by loosely coupling interoperable services – small units of software that perform discrete tasks when called upon – from separate systems across different business domains. Similarly, Microservice Architecture (MSA) – a variant of the service-oriented architecture structural style – arranges an application as a collection of loosely coupled services. In a microservices architecture, services are fine-grained and the protocols are lightweight.
An important aspect of these architecture patterns is service orchestration. In this article, we will discuss how the enterprise systems and integration projects designed according to proven architectural principles depend on successful service orchestration. We will also show the importance of first finding the right platform with enhanced service orchestration capabilities is a high priority for enterprises looking to build their systems according to industrial architectural practices.
How does Service Orchestration work?
In the Service Orchestration, composite services exchange messages in the domain layer of enterprise applications. Microservices in the application are not programmed to communicate with other services, messages must be exchanged according to a predetermined business logic and execution order so that the composite service or application can run as it is demanded by the end-user. This is usually accomplished through enterprise application integration or EAI, which enables data integration, and the use of a central messaging engine such as an enterprise service bus or ESB, which routes, transforms, enriches messages and maintains the quality of service.
Key benefits of the Service Orchestration
Provides a good way of controlling the flow of the application when there is synchronous processing. For example, if Service A needs to complete successfully before Service B is invoked.
A predefined and finite set of workflow possibilities.
Easier maintenance of the system flow as a central component defines and runs the transaction flow.
Common arguments against Service Orchestration
Single Point of Failure
Central Instance is a single point of failure. If there is a central shared instance of the orchestrator for all requests, then the orchestrator is a single point of failure.
Synchronous processing
Orchestration Leverages synchronous processing that blocks requests.
What is Service Choreography?
In the Service Choreography, each component of the system participates in the decision-making process about the workflow of a business transaction, instead of relying on a central point of control. Applying a choreography pattern means that one service doesn’t talk to another service in order to instruct an action. Instead, each service is observing its environment and acts on events autonomous.
The use of the choreography pattern makes sense if you expect to update, remove, or add new services frequently. The entire app can be modified with lesser effort and minimal disruption to existing services. In terms of the non-functional aspect of the application, consider using Service Choreography pattern if you experience performance bottlenecks in the central orchestrator. This pattern is a natural model for the serverless architecture where all services can be short-lived, or event-driven. Services can spin up because of an event that may occur at any point of time and stage of the transaction. As a result of that happening (event), services should do their task.
How does Service Choreography work?
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. In the diagrams, services are shown interacting with one more many services without a central controller or orchestrator.
Key benefits of Choreography
- It provides low coupling of services in which you can add/remove services into your solution without impacting other services in your overall solution.
- Moves away from a Monolithic approach, working better with the Agile delivery team.
Common arguments against Service Choreography
Fragmented Workflow: Workflow logic resides in fragments. Decentralizing the orchestrator can cause issues while managing the workflow.
If a service fails to complete a business operation, it can be difficult to recover from that failure.
One way is to have the service indicate failure by firing an event. Another service subscribes to those failed events takes necessary actions such as applying compensating transactions to undo successful operations in a request. The failed service might also fail to fire an event for the failure. In that case, consider using a retry and, or time out mechanism to recognize that operation as a failure. For example, see the Example section.
It’s simple to implement a workflow when you want to process independent business operations in parallel. You can use a single message bus. However, the workflow can become complicated when choreography needs to occur in a sequence. For instance, Service C can start its operation only after Service A and Service B have completed their operations with success. One approach is to have multiple message buses that get messages in the required order. For more information, see the Example section.
Growing services difficult to manage:
The choreography pattern becomes a challenge if the number of services grows rapidly. Given the high number of independent moving parts, the workflow between services tends to get complex. Also, distributed tracing becomes difficult.
The orchestrator centrally manages the resiliency of the workflow and it can become a single point of failure. On the other hand, for choreography, the role is distributed between all services and resiliency becomes less robust.
Each service isn’t only responsible for the resiliency of its operation but also the workflow. This responsibility can be burdensome for the service and hard to implement. Each service must retry transient, non-transient, and time-out failures so that the request gets terminated gracefully if needed. Also, the service must be diligent about communicating the success or failure of the operation so that other services can act accordingly.
Hybrid Reactive Design
The Hybrid Reactive Design brings together best of both the worlds of Orchestration and Choreography. This design mitigates the tradeoffs from the two models. This approach described in this section is Reactive Between and Orchestration Within.
This Hybrid Reactive Design pattern uses reactive between services and orchestration within a Business Service i.e. Composite Service. In the given diagram, Business Services are reactive to one another. A Business Service consumes an event that triggers it to orchestrate calls to Microservices. Those additional service calls could be asynchronous or synchronous. The Business Service then produces an event with the result from those Microservice calls.
Solving common arguments against Service Orchestration by introducing reactive architecture pattern
Orchestration tradeoff 1: Single Point of Failure
Problem: Central Instance is a single point of failure.
Solution: If there is a central shared instance of the orchestrator for all requests, then the orchestrator is a single point of failure. If it goes down, all processing stops. This can be overcome by adding resilience to the central component by introducing high availability and fault tolerance.
Orchestration tradeoff 2: Synchronous processing
Problem: Orchestration Leverages synchronous processing that blocks requests.
Solution: This can be overcome by adding asynchronous exchange of messages between composite services and moving away from traditional synchronous request-reply based orchestration controllers.
Choreography tradeoff 1: Fragmented workflow
Problem: Workflow logic resides in fragments. Decentralizing the orchestrator can cause issues while managing the workflow.
Solution: One way is to have the service indicate failure by firing an event. Another service subscribes to those failed events takes necessary actions such as applying compensating transactions to undo successful operations in a request. The failed service might also fail to fire an event for the failure. In that case, consider using a retry and, or time out mechanism to recognize that operation as a failure. For example, see the Example section.
It’s simple to implement a workflow when you want to process independent business operations in parallel. You can use a single message bus. However, the workflow can become complicated when choreography needs to occur in a sequence. For instance, Service C can start its operation only after Service A and Service B have completed their operations with success. One approach is to have multiple message buses that get messages in the required order. For more information, see the Example section.
Choreography tradeoff 1: :Growing services difficult to manage
Problem: As the number of services grows in choreographed application, workflow between services tends to get complex. Also, distributed tracing becomes difficult
Solution: By introducing smart reactive rules, the choreographed application can be well documented and the workflow can be visualised and managed easily. This introduces a big improvement in the choreographed application manageability.
Additional Benefits
- The services are decoupled (but not the services within Business Services).
- Asynchronous processing is enabled by leveraging events between Business services.
- The overall flow is distributed. Each service contains its own flow logic.
Trade Offs
- Within Business Service there is coupling with Microservices, although this will bring more well defined microservice responsibility and application will be more manageable.
- Depending on the design, within Service A there could be synchronous processing that blocks requests. Although, this may be necessary depending on the business scenario the service is trying to solve.
