Orchestration vs choreography - which is better in composable and API-first architecture?

Gregor Hohpe speaks at AWS Summit (@philww)

As enterprises increasingly break up previously monolithic application architectures into more composable patterns, choosing the right framework for co-ordinating all these separate components becomes paramount. Simply adopting an API-first approach — even the right kind of APIs, which is a whole other subject in itself — isn't enough on its own. There needs to be some overarching organizing principle. The word people most often use in this context is 'orchestration' — but is that really the right word to use when talking about an ecosystem of loosely coupled, autonomous resources? Some prefer 'choreography' instead. Danilo Poccia, Chief Evangelist (EMEA) at AWS, is in the latter camp. He explains:

Choreography is like a ballet. Every component knows what they should do, and magically, they can work together without hitting each other.

My motivation for examining this issue comes from a perception that a lot of the conversation about composable architecture reminds me of the early years of cloud computing. Ten or fifteen years ago, many people were claiming to have a cloud architecture when they were really adopting just one or two of its characteristics, while still operating a largely conventional application stack. It took many years to achieve mainstream recognition of what cloud computing truly entails. I can see the same confusion arising around composable architecture.

I went looking for answers at two events in June this year — the first was AWS Summit London, where I had the conversation with Poccia. A week later, I was in Amsterdam for MACH TWO, the second annual conference of the MACH Alliance, which aims to steer early adopters towards a truly composable architecture. Its main proponents are vendors and integrators who focus on composable commerce and digital experience platforms, but the organization has ambitions to expand its reach into other application categories — including ERP, which I'll be looking at in a separate article.

The organization's definition of composable architecture is summed up in the MACH acronym, which stands for Microservices-based, API-first, Cloud-native SaaS and Headless. But in my discussions and research around MACH, I've seen that there's more to it than that simple list of characteristics — how each of them are interpreted and implemented is equally important. The term API-first in particular is carrying a lot of hidden meaning, which is why I'm drilling into two aspects. In this article, I'm looking at how APIs are organized in a truly composable architecture. In a second companion article, I'll dig into the make-up of the APIs themselves. This seems to be the crux of getting composability right — and also helps distinguish true composable architectures from those that claim to be composable simply because they use APIs.

Orchestration vs choreography

So what about orchestration and choreography? These concepts are important because the more composable your architecture becomes, the more your APIs proliferate. Without an organizing or intermediary layer, developers end up having to build and maintain connections to each individual API, which rapidly becomes unsustainable. Poccia explains:

The problem when you have multiple components and you need to integrate with them, is that if you put the logic of integration inside each component, then every time you add something new, you need to change all the other components to let them know that there is something new.

Abstracting the composition logic into a separate layer makes it possible to avoid this complexity, although it's important to keep that layer independent rather than building assumptions into it — for example, tying it to a specific front-end — that could prove difficult to undo in the future if conditions change. In the digital experience space, this has given rise to a new category of vendor that provides real-time orchestration across front-end and back-end APIs, such as Conscia, whose CEO Sana Remekie has been active on LinkedIn in arguing the case for experience orchestration.

At MACH TWO, I asked Casper Rasmussen, President of the MACH Alliance and also Group SVP of Technology at tech consultancy Valtech, for his thoughts. He believes both have a role to play:

I think it's actually more choreography, when you're talking about services organization, about getting the architecture to go in tune or whatever you could say, be in rhythm, or play in harmony. But orchestration is a thing too. There are business processes and workflows that needs to get orchestrated, there are user experiences that need to get orchestrated.

This goes to the heart of the distinction between the two approaches. Orchestration is more command-driven, with the orchestration engine directing the actions of each component and therefore tending towards a more tightly coupled scenario where response times are critical. Choreography is more event-driven and therefore tending towards a more loosely coupled environment where fault tolerance comes to the fore. But orchestration is also a term that's used very widely and therefore can be misleading. He adds:

The orchestration word is also — just like composable — potentially a very over-used or potentially a very blurred word. There are many things that needs to be orchestrated, organized, choreographed.

Control vs autonomy

I also spoke to Chris Bach, a MACH Alliance Executive Board member and Co-founder and Chief Strategy and Creative Officer of Netlify. The company launched a data orchestration layer on the opening day of the MACH TWO conference. He sees the argument in favor of the word choreography, but wonders if that's the right word either:

You could make an argument that it is choreography. I like it, it's actually very beautiful. Orchestration reminds me of a symphony, when you have a conductor conducting a symphony. A choreographer is the same, but just with human bodies.

I think the notion here is — perhaps there's a better word than orchestration — is that idea of workflows, of making it viable. A good orchestration is something that allows you to, relatively frictionless[ly], exchange components.

In the same conversation, his colleague Dorian Kendal, CMO of Netlify, makes the case that orchestration is a better word to describe a service that is ready to step in and issue new instructions if something goes awry:

When I think of choreography, I think of somebody that comes in, they set the stage and they walk away. And it's all up to the people on the stage to actually perform and to do what they've learned. It is a once-and-done — you teach someone, they teach a ballet, your ballet artists, they go on, the dancers go they do their show. That's different than orchestration, where the conductor is always there. The conductor is there saying, 'Hey, let's make sure this actually continues to work.' So if something messes up, like if a dancer falls, the choreographer is not on the stage, helping to make sure it works. So I think, from my perspective, it is more orchestration, because we're there the whole time actually making sure that everything continues to work well together in one symphonic way.

Back at AWS Summit, a presentation on the topic of 'refactoring to serverless' suggests that both approaches have a role to play. Gregor Hohpe, Senior Principal Evangelist at AWS and author of The Software Architect Elevator and other books, talks about moving from one to another. He explains that, whereas orchestration gives more explicit control and insight into what's happening, choreography just leaves the components to get on with the job:

You could change orchestration to choreography, so rather than having [AWS} Step Functions orchestrate all the things in a more synchronous kind of model, you can choreograph that and have a flow of events, that scales very nicely.

Sometimes you want to build the same order of things, in order to know what you have. Then a central orchestrator is actually a really nice thing to have, so you can report on, 'Okay, I have a thousand instances, and 80 of them are in this state and the other 900 are in that state.'

So you can move back and forth, while retaining the same, or very similar, functional behavior.

My take

Like Rasmussen, I'm wary of the word orchestration. For my part, I feel it carries a fair bit of baggage from way back in the days of business process management, when it was used as part of a very command-and-control type of setup which doesn't sit at all well with the notion of loosely coupled autonomous services. Even today, I suspect that an orchestration mindset is one that is all too likely to start making assumptions about how components should behave, and thus will inadvertently build inflexibility into an application or process. I instinctively lean towards choreography because then you have to do the work to ensure your components are able to operate in a loosely-coupled, event-driven environment.

On the other hand, I recognise that Hohpe's advice is sound. There will be some cases where orchestration is what you need, while other cases are better served by choreography. However if that's the case, it leads inexorably to the conclusion that your APIs must be capable of operating autonomously within a choreographed process, otherwise they'll be sitting there waiting to be told what to do because you built them with orchestration in mind.

In short, my next article goes on to look at how you build your APIs, because ultimately that determines the success or otherwise of your composable architecture.