Microservices - Choreography vs Orchestration

Mich erreichte folgende Fragestellung während eines Projektes: Was denkst du über Choreography und Orchestrierung im Kontext von Microservices?

Um diese Frage zu beantworten, werde ich zunächst die beiden Ansätze erklären und daraufhin die Gegensätze herausarbeiten. Wir starten mit den Gemeinsamkeiten. Beide Ansätze stehen vor der Herausforderung, verteilte Transaktionen (Saga Pattern) zu managen.

Die Digitale Transformation ist Ihr Top-1-Projekt?
Nutzen Sie Ihre Chancen – wir kümmern uns als Full Service Partner um die Herausforderungen.

Zentralisierung oder Dezentralisierung?

Aber die Art und Weise, wie sie dem Problem begegnen, ist gegensätzlich. Orchestrierung delegiert die Ausführung von Transaktionen an einen dedizierten Service. Eine zentralisierte Workflow Engine organisiert dabei die Transaktionsschritte. Was sind die Vor und Nachteile? Der zentralisierte Style erlaubt die zentrale Verwaltung des Zustands und Fortschritts des Workflows. Dies führt konsequenterweise dazu, dass der Workflow auch einfach überwacht werden kann und Fehler, Retries und Timeouts zentral gemanaged werden können. Der teilnehmende Service muss darüber hinaus nicht den gesamten Workflow zu kennen. Jedoch muss der Service seinen Anteil an der Kompensation selbst bewerkstelligen, weil diese Funktionen auch vom Orchestrierungsservice verwaltet werden. Die zentralisierten Services formen einen Single Point of Failure, welcher in Betracht gezogen werden muss, wenn es darum geht, Fehlerszenarien für das Gesamtsystem zu betrachten. Denn zur Laufzeit formt der Orchestrierungsservice ein monolythisches System. Die Fähigkeit, unabhängig deploybar zu sein, wird leiden, wenn dieser Ansatz auf die teilnehmenden Services angewendet wird.

Der Gegensatz ist der dezentralisierte Ansatz, genannt Choreography. Hierbei wird mittels Domain-Events und dem Event-carried-State-Transfer Pattern (Alle Infos für den Kontext eines Events befinden sich ebenfalls im Event) die Verantwortung der Transaktionsverwaltung und ihrer Kompensation von einem Service zu allen teilnehmenden Services transferiert. Hier muss jeder Service der Transaktion die komplette Kompensation des gesamten Workflows unterstützen. Die Vorteile liegen dabei auf der Hand. Die Services bleiben lose gekoppelt, auch zur Laufzeit, und können damit ohne jegliche Probleme skaliert und verändert werden. Es gibt keinen Single Point of Failure. Auf der anderen Seite bleibt der Workflow-Zustand und -Fortschritt implizit versteckt. Somit wird das Monitoring ziemlich schwierig und benötigt wie jede andere Funktion ein zusätzliches zentrales System, um diese Dienste anzubieten.

Wann Orchestrierung, wann Choreography?

Die Frage kann auf die Fragestellung "zentral vs. dezentral" reduziert werden. Hierfür sollte man sich immer fragen, in welchem Fall Microservices verwendet werden sollen. Die Antwort ist dabei einfach: der Einsatz ist nur dann sinnvoll, wenn Microservices dein Problem lösen. Hast du überhaupt ein Problem? Wieso in der Praxis nicht klein und zentralisiert starten? Und wenn diese Lösung Probleme verursacht, erst dann darauf reagieren.

Die dezentralisierte Lösung hört sich spannender an. Aber behalte im Gedächtnis! Bevor man Raketen-Wissenschaft betreibt, starte mit der Domäne, modelliere die Transaktion, implementiere die Kompensation und nutze die Funktionen, welche das Tooling von sich aus anbietet.

Und wo sind die Grenzfälle? Ja, es gibt sie. Denke einmal über Transaktionen nach, welche über mehrere Bounded Kontexte und damit oft auch über mehrere Teams aufgespannt sind. Hier könnte die dezentrale Lösung gewisse Vorteile bieten. Aber am Ende ist dies wieder die individuelle Fragestellung, wieviel Abhängigkeiten zwischen Teams im Projekt gemanaged werden können.

Als Standardtool sehe ich im Kontext von Orchestrierung häufig Camunda BPM. Was nutzt Ihr? Als Lektüre zum Thema empfehle ich das Buch von Sam Newman, Monolith to Microservices.

Die Digitale Transformation ist Ihr Top-1-Projekt?
Nutzen Sie Ihre Chancen – wir kümmern uns als Full Service Partner um die Herausforderungen.