Orkestratie versus choreografie

Wat is orkestratie versus choreografie?

Orkestratie en choreografie zijn de twee manieren om werk te coördineren dat over meerdere systemen loopt. Bij orkestratie houdt een component het proces vast. Die roept elke deelnemer op zijn beurt aan, noteert waar het dossier staat en beslist wat er nu volgt. Bij choreografie houdt niemand het proces vast. Elke component kondigt aan wat ze net gedaan heeft, en de anderen reageren daar zelf op.

Chris Richardson vat beide kanten in een zin samen in zijn catalogus rond het saga pattern. Bij choreografie publiceert elke lokale transactie domeinevents die lokale transacties in andere services in gang zetten. Bij orkestratie zegt een orkestrator aan de deelnemers welke lokale transactie ze moeten uitvoeren.

Camunda kijkt naar het soort bericht dat onderweg is. Choreografie verstuurt events, en de verzender weet niet wie dat event oppikt of wat er daarna gebeurt. Orkestratie verstuurt commando's, want de verzender wil dat er iets bepaalds gebeurt. Dit is geen technologiekeuze: je bouwt beide stijlen op dezelfde message broker. Het is een beslissing over waar de kennis van het volledige proces zit.

Hetzelfde orderproces, op twee manieren getekend

Neem een webshoporder die langs voorraad, betaling en verzending moet. Drie services, één zakelijk resultaat.

Georkestreerd. Een orderservice start een procesinstantie en stuurt die aan. Ze stuurt een commando naar voorraad om te reserveren en wacht op het antwoord, daarna een commando naar betaling, daarna een commando naar verzending, en zet de order op bevestigd. De route staat op een plaats beschreven, in code of in een BPMN-diagram, en de huidige stap van order 4471 is gewoon een veld in de database van de orkestrator.

Gechoreografeerd. De orderservice publiceert order.placed en is klaar. Voorraad hoort dat, reserveert de stuks en publiceert stock.reserved. Betaling hoort dat, doet de afname en publiceert payment.taken. Verzending hoort dat en boekt de koerier. Vier events, geen enkel commando, en geen component die de route kent. De route bestaat alleen als de optelsom van wie toevallig op wat geabonneerd is.

Nu belt de klant. Waar zit mijn bestelling?

In de georkestreerde versie open je de procesinstantie en lees je het antwoord. Camunda Operate bijvoorbeeld toont het procesdiagram met de voortgang van die instantie erop, de variabelen en het incident dat ze tegenhoudt. Order 4471 hangt sinds 9u12 op de betaalstap met een geweigerde kaart. Een keer opzoeken, een zin naar de klant.

In de gechoreografeerde versie is er geen instantie om te openen. Je filtert de logs van elke service op de correlatiesleutel en leest het spoor: order gepubliceerd om 9u07, voorraad gereserveerd om 9u08, betaling logde een weigering om 9u12, verzending heeft nooit iets gehoord. Zelfde antwoord, vijf systemen en een distributed trace verder. En dat werkt alleen als iemand die correlatiesleutel lang voor dit telefoontje op elk event heeft gezet.

Wie kent de staat van het volledige proces?

Dat telefoontje is de dimensie waar de hele vergelijking om draait.

Orkestratie geeft je één plek die het weet. Eén plek om de status van een dossier te lezen, een plek om de route aan te passen als de zaak verandert, een plek om te kijken als er iets misloopt. Emily Fortuna van Temporal verwoordt de debugkant zonder omweg: omdat orkestratie de control flow centraliseert, wordt debuggen en de flow begrijpen veel eenvoudiger. Retries, timers en compensatie zitten daar ook, en daarom belandt het saga pattern zo vaak in een georkestreerde vorm.

Wat orkestratie kost, is een component waar alles op leunt. Microsoft benoemt de rekening in de beschrijving van het choreografiepatroon: een service toevoegen of weghalen kan bestaande logica breken omdat je een stuk van het communicatiepad moet herbedraden, en onder belasting wordt de orkestrator een flessenhals en een single point of failure waarvan de uitval doorslaat naar alles wat eronder hangt.

Choreografie geeft je losse koppeling. Een nieuwe consumer begint naar order.placed te luisteren zonder dat iemand de orderservice aanraakt. Dat is precies wat je wil wanneer een ander team die consumer bezit en op zijn eigen ritme deployt.

Wat choreografie kost, is het antwoord op dat telefoontje. Microsoft schrijft het zonder slag om de arm: zonder centrale orkestrator die de volledige transactiestaat bijhoudt, heeft geen enkele component een volledig beeld van een lopende zakelijke handeling, en moet je consequent distributed tracing en correlatiesleutels gebruiken om nog iets van observability te hebben. Fortuna maakt hetzelfde punt vanuit de code: de codebase van een enkele service vertelt je niets over de volgorde die het systeem hoort te volgen, want die volgorde ligt over alle services verspreid. Volgorde is trouwens de kost die pas later opduikt. Het patroon past bij onafhankelijke stappen die naast elkaar lopen, en wordt lastig zodra service D pas mag starten als B en C allebei klaar zijn.

Waar de grens meestal ligt

Voor een bedrijf met één ontwikkelteam en een helpdesk die klanten moet antwoorden, is orkestratie bijna altijd de juiste standaardkeuze. Niet omdat ze architecturaal beter zou zijn, maar omdat de vraag die twintig keer per dag binnenkomt gaat over waar een dossier zit. De losse koppeling die choreografie oplevert, betaalt zich terug wanneer aparte teams moeten deployen zonder met elkaar te overleggen. Met één team betaal je voor een voordeel dat je niet kan uitgeven.

De meeste systemen die een paar jaar draaien, komen bij hetzelfde compromis uit, en Camunda en Microsoft omschrijven het gelijkaardig: orkestreer binnen een domein, choreografeer tussen domeinen. Bij Microsoft klinkt dat als choreografie gebruiken waar communicatie over domeingrenzen losse koppeling nodig heeft, en binnen een enkele bounded context eerder een orkestrator overwegen. Bij Camunda als events gebruiken zodra het bericht de context van het huidige domein verlaat, en orkestratie zodra je met domeinkoppeling tussen je services zit.

Het orderproces hierboven blijft dus end-to-end georkestreerd, en publiceert bij afloop een order.completed event dat rapportering, marketing en het loyaltyprogramma elk oppikken zonder ooit in de orderflow te verschijnen. Fortuna waarschuwt nog voor de timing van die keuze: choreografie lijkt in het begin lichter, maar orkestratie is makkelijker te bouwen wanneer je er meteen mee start. Achteraf een centrale flow bouwen bovenop services die er al van uitgaan dat niemand de leiding heeft, is de dure versie.

Dezelfde discussie, nu met AI-agents

Multi-agentsystemen hebben deze discussie opnieuw uitgevonden met nieuwe woorden. Een orkestrator-agent die het werk plant en subagents aanroept, is orkestratie. Een reeks agents die het werk aan elkaar doorgeven, elk beslissend wanneer ze doorschuiven, is choreografie met een naambadge waar handoff op staat.

De catalogus van Microsoft rond agent-orkestratiepatronen loopt punt voor punt gelijk met de klassieke versie. De patronen met een manager-agent geven je een plan en een audit trail daarvan. Het handoff-patroon geeft je agents die onderling beslissen wanneer ze de controle doorgeven, en waar je daar op moet letten zijn eindeloze handoff-lussen en onvoorspelbare routes. Dat is de agentversie van een eventcyclus. Hun advies over waar je begint is kort: een enkele agent met tools is vaak de juiste standaardkeuze voor bedrijfstoepassingen, en die is eenvoudiger te debuggen en te testen dan een opstelling met meerdere agents.

Een ding verandert wel, en het verandert in het voordeel van orkestratie. Agents zijn niet-deterministisch, dus dezelfde input kan morgen een andere route nemen. Microsoft raadt daarom aan om agentflows te testen met scorerubrieken of een model als jury in plaats van met exacte vergelijkingen, en om elke agentactie en elke handoff te instrumenteren. Als het pad zelf niet reproduceerbaar is, dan is een component die noteerde welke agent welke opdracht kreeg en wat er terugkwam de enige reden dat je achteraf nog kan reconstrueren wat er gebeurd is. Het argument van auditeerbaarheid, dat bij gewone services vooral handig is, wordt bij agents dragend.

Waar moet je op letten bij beide stijlen?

De orkestrator die alle bedrijfslogica naar zich toetrekt. Orkestratie loopt mis als een centraal proces stilaan elke regel, elke uitzondering en elk speciaal geval voor een klant absorbeert, tot niemand er nog aan durft raken en elk team erachter staat aan te schuiven. De orkestrator hoort de route, de staat en de foutafhandeling te bewaken. Zodra ze ook prijsregels en btw-logica begint te bewaken, splits je ze.

De orkestrator als single point of failure. Ligt ze plat, dan beweegt er niets. Bewaar de staat van elke instantie, maak deelnemers idempotent zodat een retry na een crash niet twee keer van dezelfde kaart afhaalt, en draai de engine zo dat ze het verlies van een node overleeft.

Eventstormen en cycli. Microsoft beschrijft hoe gedecentraliseerde eventtopologieën op schaal emergent gedrag opleveren, waarbij een klein event een cascade uitlokt en services die op elkaar reageren een feedbacklus vormen. De vangrails die ze noemen zijn eventfiltering, limieten op gelijktijdige verwerking, throttling en expliciete regels over wat op wat mag reageren. Camunda benoemt de mildere dagelijkse variant: eventketens die niemand getekend heeft, die nergens zichtbaar zijn en die het zoeken naar een fout moeilijker maken dan nodig.

Niemand heeft het getekend, dus niemand kan het veranderen. De stille kost van choreografie is dat het proces enkel in de hoofden van mensen bestaat. Voor je dat aanvaardt, vraag je best wie in het bedrijf de orderflow vandaag op een whiteboard kan tekenen, en wat er gebeurt in de week dat die persoon vertrekt.