Orchestrating microservices

Question

What is the standard pattern of orchestrating microservices?

If a microservice only knows about its own domain, but there is a flow of data that requires that multiple services interact in some manner, what's the way to go about it?

Let's say we have something like this:

• Invoicing
• Shipment

And for the sake of the argument, let's say that once an an order has been shipped, the invoice should be created.

Somewhere, someone presses a button in a GUI, "I'm done, let's do this!" In a classic monolith service architecture, I'd say that there is either an ESB handling this, or the Shipment service has knowledge of the invoice service and just calls that.

But what is the way people deal with this in this brave new world of microservices?

I do get that this could be considered highly opinion-based. but there is a concrete side to it, as microservices are not supposed to do the above. So there has to be a "what should it by definition do instead", which is not opinion-based.

Shoot.

Answer 1

So you're having two services:

1. Invoice micro service
2. Shipment micro service

In real life, you would have something where you hold the order state. Let's call it order service. Next you have order processing use cases, which know what to do when the order transitions from one state to another. All these services contain a certain set of data, and now you need something else, that does all the coordination. This might be:

• A simple GUI knowing all your services and implementing the use cases ("I'm done" calls the shipment service)
• A business process engine, which waits for an "I'm done" event. This engine implements the use cases and the flow.
• An orchestration micro service, let's say the order processing service itself that knows the flow/use cases of your domain
• Anything else I did not think about yet

The main point with this is that the control is external. This is because all your application components are individual building blocks, loosely coupled. If your use cases change, you have to alter one component in one place, which is the orchestration component. If you add a different order flow, you can easily add another orchestrator that does not interfere with the first one. The micro service thinking is not only about scalability and doing fancy REST API's but also about a clear structure, reduced dependencies between components and reuse of common data and functionality that are shared throughout your business.

HTH, Mark

Answer 2

So, how is orchestration of microservices different from orchestration of old SOA services that are not “micro”? Not much at all.

Microservices usually communicate using http (REST) or messaging/events. Orchestration is often associated with orchestration platforms that allow you to create a scripted interaction among services to automate workflows. In the old SOA days, these platforms used WS-BPEL. Today's tools don't use BPEL. Examples of modern orchestration products: Netflix Conductor, Camunda, Zeebe, Azure Logic Apps, Baker.

Keep in mind that orchestration is a compound pattern that offers several capabilities to create complex compositions of services. Microservices are more often seen as services that should not participate in complex compositions and rather be more autonomous.

I can see a microservice being invoked in an orchestrated workflow to do some simple processing, but I don’t see a microservice being the orchestrator service, which often uses mechanisms such as compensating transactions and state repository (dehydration).

Answer 3

If the State needs to be managed then the Event Sourcing with CQRS is the ideal way of communication. Else, an Asynchronous messaging system (AMQP) can be used for inter microservice communication.

From your question, it is clear that the ES with CQRS should be the right mix. If using java, take a look at Axon framework. Or build a custom solution using Kafka or RabbitMQ.

Answer 4

i have written few posts on this topic:

Maybe these posts can also help:

API Gateway pattern - Course-grained api vs fine-grained apis

https://www.linkedin.com/pulse/api-gateway-pattern-ronen-hamias/ https://www.linkedin.com/pulse/successfulapi-ronen-hamias/

Coarse-grained vs Fine-grained service API

By definition a coarse-grained service operation has broader scope than a fine-grained service, although the terms are relative. coarse-grained increased design complexity but can reduce the number of calls required to complete a task. at micro-services architecture coarse-grained may reside at the API Gateway layer and orchestrate several micro-services to complete specific business operation. coarse-grained APIs needs to be carefully designed as involving several micro-services that managing different domain of expertise has a risk to mix-concerns in single API and breaking the rules described above. coarse-grained APIs may suggest new level of granularity for business functions that where not exist otherwise. for example hire employee may involve two microservices calls to HR system to create employee ID and another call to LDAP system to create a user account. alternatively client may have performed two fine-grained API calls to achieve the same task. while coarse-grained represents business use-case create user account, fine-grained API represent the capabilities involved in such task. further more fine-grained API may involve different technologies and communication protocols while coarse-grained abstract them into unified flow. when designing a system consider both as again there is no golden approach that solve everything and there is trad-off for each. Coarse-grained are particularly suited as services to be consumed in other Business contexts, such as other applications, line of business or even by other organizations across the own Enterprise boundaries (typical B2B scenarios).

Answer 5

the answer to the original question is SAGA pattern.

Answer 6

Trying to aggregate the different approaches here.

Domain Events

The dominant approach for this seems to be using domain events, where each service publish events regarding what have happened and other services can subscribe to those events. This seems to go hand in hand with the concept of smart endpoints, dumb pipes that is described by Martin Fowler here: http://martinfowler.com/articles/microservices.html#SmartEndpointsAndDumbPipes

Proxy

Another apporach that seems common is to wrap the business flow in its own service. Where the proxy orchestrates the interaction between the microservices like shown in the below picture:

.