Skip to main content

Choreography over Orchestration

Context​

Microservices are used or are being adopted. There are (plans for) central components that manage the workflows between lower-level microservices.

Problem​

  • These central components are coupled tightly to the managed microservices, indicated by being frequently changed together.
  • New functionality frequently requires coordination between the teams of the functionality owner and the central component managing the workflows.

Solution​

Use workflow choreography instead of orchestration.

Even though having more central service managing the workflows (orchestrators) might be more simple and an easier way to manage complexity, it is recommended to use a choreographic collaboration style instead. This implies the shift to an event-driven architecture, meaning domain events play the leading role of interfacing between microservices. Domain events describe that specific things regarding the domain happened in the system, for example an order was dispatched, a bill was payed, ecetera. These events are made available to all other microservices, so they can react on those events. The overarching behavior is added up by each microservice playing its role in the overall picture (choreography).

Orchestration

Choreography

Choreography leads to a lower coupling between microservices since not all communication partners need to be known but only the messaging mechanism that distributes the events to other microservices. However, the events become the contract that needs to be evolved. Without the central components, it will be easier to adjust existing functionality, but also to extend the system with new functionalities and microservices. The technique goes well with the goal to decentralize the responsibility and to reduce coordination overhead as far as possible.

Choosing choreography over orchestration also comes with its drawbacks. Error handling is not as easy since the logic does not exist in a central place, thus we need compensation mechanisms and monitoring, tracking if all required actions were taken in the end to recognize errors in the first place. Developers might not be familiar with this programming paradigm, so there might be the need to build up this knowledge first, e.g., by using education programs or doing experiments.

Please note that the workflow coordination type (orchestration vs. choreography) is generally independent from

However, choreography naturally aligns well with asynchronous workflows, and orchestration aligns well with synchronous workflows but can also be implemented as asynchronous workflow.

We found a conflicting meaning for the word orchestration in the microservice domain. Next to workflow orchestration it is used in the context of container orchestration of cluster managers. Thus, we suggest to speak of workflow orchestration and container orchestration instead of leaving room for ambiguities.

Example​

The following example shows two systems. Both are different architectural takes on how a healthcare professional can create a patient in a healthcare software system, e.g. for sharing files with them and managing medical devices. Other services need to know that this patient exists in order to offer their services to the patient.

The first system uses an orchestration-based approach where the Patient Service takes directly takes the place of the central brain. It needs to know all dependent services to trigger their behavior. Changing one dependent service is likely to require changes on the Patient Service as well.

The second system uses a choreography-based approach where a Broker decouples the services from each other. The Patient Service is only responsible for letting other services know via a publish-subscribe mechanism that a new patient was created. They act upon event receival accordingly. The logic is now more cohesive in one service instead of distributed through the system.

Maturity​

Proposed, requires evaluation.

Sources of Evidence​

L7:

  • Microservices use "Service orchestration via plain old programming"
    • !!! Seems to contradict other material => maybe changed over time?

L16:

  • both approaches possible, but prefer choreography (except there are good reasons to do otherwise)
  • Choreography
    • (+) high degree of freedom of how things can be handled
      • Scenario: add new service => orchestrator also has to be changed
      • What if the "conductor" is from another vendor in an IoT scenario? => not possible
    • (-) Additional effort (e.g. service) for monitoring if all required actions are done successfully

L22:

  • Context: usual standards in microservice projects for implementing interfaces
  • message-oriented, stateless, hypermedia-driven

L34:

  • Orchestration predominant in SOA, choreography predominant in microservices
  • Orchestration
    • (-) often means introducing canonical data model => hard to change later on, limits evolution
    • => Make sure to use bounded contexts to compensate for that
  • Choreography
    • Leads to "no logic in integration"
    • Flexibility to design & adjust business processes
    • Good alternative to distributed transactions (which we try to avoid)

L41:

  • RabbitMQ as technology in example for message-passing choreography
  • Choreography
    • (+) low coupling
    • (+) no interfaces to violate

L47:

  • Experiences with orchestration (coming from SOA)
    • First ESB, overkill for anything but large organizations, connectors cost a lot
    • Second BPMN engines, automating orchestration routes too complex for mid-sizied applications, risk to introduce coupling
    • Last lightweight webhooks, => "passive choreography"

L52:

  • Microservices prefer choreography

L55:

  • Microservice example using orchestration

LM48:

  • Context: microservice migration describes an examples project (FX Core) and compares back to monolith
  • use message-based choreography
    • asynchronous and decouples services entirely
    • use RabbitMQ for pub-sub
    • consumers pull from queue
    • => no need to call each other directly => low coupling, no interface violation

Interview B:

  • Always try to use events (=> choreography)
    • (-) more complex to wrap your head around (devs not used to asynchronous programming)
    • (-) more complex to monitor
    • (-) alternative paths have to be thought our from beginning

Interview D:

  • REST vs events (=> somewhat resembles orchestration vs choreography in the context)
  • event-flow often more natural to mimic real-world processes

Interview E:

  • No orchestration but a choreography
    • no big single point of failure who manages other systems
    • but every subsystem contributes to the whole