Serverless Integration Patterns: Orchestration and Choreography

This article describes serverless integration patterns based on choreography and orchestration, pro-cons, and when to use them

In a monolith, in-process communication between components happens either via method invocation of function calls.

When you are building a cloud solution, communication between components is a lot harder. By component, I am referring generically to any type of serverless function; DB services (with implicit behavior such as get, put, update); apps running in K8s clusters as a service, etc.

There are usually 3 ways to approach this:

1. have a direct invocation between components
2. having components to work independently but coordinate them using commands or events
3. having an external entity that centrally controls and organizes work between components.

Let’s review these 3 options and then dive into the patterns:

• Direct invocation: all components calling each other. The fact that each component knows others usually makes it harder to change, test and debug the whole behavior of the system. A good one to quickly kickoff, hard to maintain.
• Choreography: components work independently and they don’t know each other. We need a component that can choreograph implementing an asynchronous message pattern, usually, an event bus like AWS EventBridge or Azure Event Grid to enable participants to publish and receive messages and events. In practical terms, it could also be a simple queue or topic.
• Orchestration: A centralized orchestration component to take care of all coordination logic, usually a workflow like AWS Step Functions or Azure Logic Apps. You also have other options based on open source projects such as Camunda Cloud.

These patterns are not determined by technologies or whether it is synchronous or asynchronous. They are defined by responsibilities, what each component is meant to do.

Direct invocation

We can say that this is the default pattern. You just do, and you get it. I won’t dive into this one…