For collaboration of microservices, there are two basic styles: orchestration and choreography.

In his well-known book “Building Microservices”, Sam Newman wrote:

“As we start to model more and more complex logic, we have to deal with the problem of managing business processes that stretch across the boundary of individual services. […] When it comes to actually implementing this flow, there are two styles of architecture we could follow. With orchestration, we rely on a central brain to guide and drive the process, much like the conductor in an orchestra. With choreography, we inform each part of the system of its job, and let it work out the details, like dancers all finding their way and reacting to others around them in a ballet.”Sam Newman, “Building Microservices”

(1) THE ORCHESTRATION STYLE

With orchestration style, we move the rules governing the interaction among different services into a central, coordinating unit. By invoking commands and coordinating the meaning of the results for further steps, this unit reminds a bit of the way a conductor interacts with an orchestra. 🙂

Orchestration style architectures will therefore rely on some request mechanism to issue commands (and queries). But note that such requests must not necessarily be implemented by means of some synchronous request/reply. It might e.g. be realised via asynchronous command messages routed to other services via some kind of messaging infrastructure. It might also be implemented via an “ask for work” (pull) mechanism, which lets the other services retrieve the commands to be carried out by themselves.

Let’s work out a simple example for orchestration. A customer places an order in a webshop. An order service coordinates the following process to fulfill the order. It communicates with three other services: they are dealing with payment, inventory and shipment:

1. A customer places an order in a webshop. As a consequence, an order service coordinates the order fulfillment…
2. … and asks the payment service to collect money.
3. When the money is collected …
4. … the order service asks the inventory service to fetch the items.
5. When the items are fetched …
6. … the order service asks the shipment service to ship the parcel.
7. And finally, when the parcel is shipped …
8. … the order service informs that the order is delivered.

The whole flow logic for this order fulfillment resides in some central brain acting as the flow “conductor”. In our case this central brain is the order service.

(2) THE CHOREOGRAPHY STYLE

With choreography style, the rules governing the interaction among different services move into the decentral units. The decentral services are interacting to reach the goal of the business process, each part of the system knowing the job it is responsible for, and working out the needed details on its own.

Quite typically, choreography style architectures will work with some event publicationmechanism. By means of events, individual services can inform other services of what happened inside of them without needing to know anything about those other services. Note that such event publication might e.g. be implemented by means of a relatively dumb event bus/pipe based on some kind of messaging infrastructure, but it might also be realised via several event feedspublished by the individual services themselves, e.g. via Atom/REST.

Let’s look how the above example could work without any central conductor issuing commands, but just by means of events.

1. Again, the customer places an order in the webshop, which therefore issues an “Order Created” event. As a consequence…
2. … the payment service listening to that event starts to collect money and issues a “Money Collected” event.
3. The inventory service decides to start to fetch the items as soon as the money is collected…
4. … and finally the shipping service will of course ship the parcel, when the items are fetched.

The flow logic for the order fulfillment resides now inside the individual services. They need to work out on which events they need to react in which way themselves.

PROS, CONS AND A COMMUNITY PREFERENCE

An argument often cited in favor of orchestration is, that a central conductor can easily track the flow state. Sam Newman points that out, too: with choreography you might have to do some extra work just to monitor and track across system boundaries. However, the argument may vanish with better out-of-the-box tooling for choreographied architectures.

Another argument in favor of orchestration may be that we can more easily implement the flow logic. Typical requirements like synchronizing parallel business activities, taking care of deadlines and timeouts or compensating business activities in case we need to “roll back” a flow may turn out to be tackled easier when everything related to the flow is centralised.

This argument must however be weighed against the observation that the central conductor in the orchestration approach can easily become “too much” of a central authority and a central point where most of the logic starts to live. Such tendencies work against an important selling point for doing microservices in the first place: easily adapt to changing business requirements.

In general, I have found that systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change […]. I have found most heavily orchestrated implementations to be extremely brittle, with a higher cost of change.Sam Newman, “Building Microservices”

The Microservices Community tends to agree. I tend to agree, too. But I also think that the details can depend on circumstances. When reading Sam Newman’s statement closely, he also suggests that his preference for choreography is true “in general” and that systems may “tend”more toward one or more toward the other approach. This reminds us, that we have options and that we can mix the two styles in a way to match our own requirements.

Why service collaboration needs choreography AND orchestration

Let’s assume you want to build a simple order system covering the whole order fulfillment process with the following three microservices involved (you might name it services, components or aggregates if you prefer):

• Payment
• Inventory
• Shipping

The overall order fulfillment definitely requires these three services to collaborate. Currently there is a big fight going on as to which collaboration style to use — orchestration or choreography (for an introduction on the basic styles see Orchestration or Choreography). But is this an either or decision?

I strongly believe that in most real-life scenarios you need a clever mix of both collaboration styles so let’s go over that.

Choreography

Assume that we want to use event-based choreography as much as possible. This is in sync with the typical recommendation among microservice publications, e.g. “Building Microservices” from Sam Newman:

In general, I have found that systems that tend more toward the choreographed approach are more loosely coupled, and are more flexible and amenable to change […].

[…], asynchronous event collaboration helps us adopt a choreographed approach which can yield significantly more decoupled services — something we want to strive for to ensure our services are independently releasable.

And I agree that this make sense on a large scale. Doing so results in the following event flow for our order application:

So far so good, no component is talking directly to each other and only events are used to communicate. Very de-coupled — isn’t it?

No.

Event command transformation

The problem is that the payment service has to react to the order placed event. It has to know its consumer! As soon as other services need payment, it has to be adjusted. This is exactly what we don’t want, at least in the case of the payment.

Another example: You want to implement the new business requirement that VIP customers can pay later by invoice. Now you have to change multiple components: The payment needs to know only to execute payments for non VIP customers. The inventory has to know that it reacts also on order placed but only for VIP customers. So you already had to tell two services about your VIP customer even though they should never know about it.

That’s why an additional component that decides that you have to do paymentwhenever an order was created improves de-coupling of the payment service from its concrete consumer. My friend Martin Schimak an I call that event command transformation:

In our example this might be done by an order service.

Orchestration

As soon as you issue commands, you’ve taken the first step towards orchestration as the transformer automatically is some kind of conductor commanding another component. However, the command is still a message and can be sent over the normal bus. So I see good reasons to still summarize that as choreography without remorse. As wording is very important in the current discussions I think this helps to remove misconceptions that orchestration has to be avoided at any price; as you can see that the event command transformation is actually essential to build a nicely de-coupled event-based system!

State Handling

We have a second challenge. The payment might take quite long to complete. Assume we want a call center to call the customer to clear problems during payment. That might take days to weeks. So now you get a long running flowin your order service and you have to track the state. And you might face timing requirements, for example the pricing in the order might only be fixed for 7 days so you want to take action if the order is delayed too long.

I have described basic implementation approaches in How to implement long running flows, sagas, business processes or similar. A typical approach is to use a state machine to do this. This finally means you are using an orchestrated style of collaboration within your order service. It is important to notice the small word within here.

“Overall choregraphy and local orchestration”

This yields the following approach:

• Orchestration takes place locally in the order service. It is an implementation decision of that service to use a (local) brain to coordinate the flow it has to implement. There is no central conductor steering different services, no central spider in a giant spiderweb. That’s the typical misconception with orchestration engines. But there is a proper event command transformation so that the order service can command the payment service in order to improve de-coupling.
• The end-to-end business process of ordering goods can be implemented as overall choreography. Only messages (events and commands) are sent over the wire, there is no central conductor controlling everything.

This brings the best of both worlds: Handling state and mastering control over the flow happens in a context you can easily control — one service. Choreography is used on the larger scale of collaboration of various services to improve flexibility.

Conclusion

For real-life use cases services need to collaborate. You need both: A choreographed event-based style as well as an orchestrated command-based styledepending on the situation at hand. With a clever mix you reach the level of de-coupling you aim for especially when using microservices.

If you are interested in concrete code examples for the concepts discussed, there is the flowing retail sample application showing all these aspects in action.

Source:

https://plexiti.com/en/blog/2017/03/microservices-orchestration-or-choreography/

https://blog.bernd-ruecker.com/why-service-collaboration-needs-choreography-and-orchestration-239c4f9700fa