Orchestrieren oder Choreografieren? Über eine Streitfrage in Microservices-Architekturen
Über die Popularität von Microservices haben wir bereits in Teil 1 dieser Serie gesprochen. Teil 2 hat sich dann speziell dem Thema Migration zu einer solchen Architektur gewidmet. In diesem dritten Teil möchte ich mich nun einer wichtigen Entscheidung zuwenden: Soll die Kommunikation zwischen den verschiedenen Microservices durch Orchestrierung oder Choreographie geregelt werden? Beide Ansätze haben Vor- und Nachteile, die sorgfältig abgewogen werden müssen. Die Entscheidung hat großen Einfluss darauf, welchen Aufwand spätere Änderungen erfordern und kann damit leicht über Erfolg oder Misserfolg der gesamten Microservices-Transformation entscheiden.
Vorteile der Orchestrierung
Orchestrierung bedeutet, Microservices (oder auch menschliche Aufgaben oder andere Endpunkte) zu koordinieren. Das typische Bild ist das eines zentralen Orchestrators, der die Interaktionen zwischen den Microservices steuert und koordiniert. Der Orchestrator legt die Reihenfolge fest, in der die Microservices aufgerufen werden, und kann auch die Fehlerbehandlung und Kompensation koordinieren. Er stellt somit sicher, dass aus dem Zusammenspiel verschiedener Microservices ein sinnvoller End-to-End-Geschäftsprozess entsteht.
Ich möchte hierzu einen wichtigen Punkt betonen, nämlich den, dass die Orchestrierung nicht unbedingt zentral oder übergeordnet erfolgen muss. Auch einzelne Microservices können wiederum andere Microservices, die sie benötigen, orchestrieren. Zum Beispiel benötigt die Abwicklung einer Bestellung andere Services rund um Bezahlung, Lagerhaltung und Logistik. Und der Microservice, der die Bezahlung regelt, benötigt seinerseits Services zur Kreditkartenzahlung, Abbuchung, zu dritten Zahlungsdienstleistern (wie beispielsweise PayPal), eigenen Wallets oder was auch immer. Somit passiert Orchestrierung auch dezentral. Die verwendete Technologie, beispielsweise eine Process Orchestration Platform, wird dann aber oft im Unternehmen zentral betrieben, um Teams von der Bürde zu befreien, eigene Technologie betreiben zu müssen.
Zentrale Plattform ≠ zentralisiertes Prozessmanagement
Sollte dieses Maß an Zentralität Diskussionen hervorrufen, bietet das Buch "Team Topologies" gute Argumente, warum die Autonomie der Teams auf die Fachlichkeit, nicht aber unbedingt auf alle technischen Aspekte gedacht werden sollte [1]. In kurz: Technologische Infrastruktur, wie Datenbanken oder eben auch Process Orchestration Plattformen, sollte als "Capability" den Teams bereitgestellt werden. Die Teams bekommen dann "nur" eine eigene Instanz, ihren eigenen Mandanten oder einen eigenen User, ganz nach den konkreten Anforderungen an Isolationslevel. Die Teams sind inhaltlich verantwortlich, was genau ausgebracht wird, also das Datenbankschema oder das Prozessmodell, nicht aber für den technischen Betrieb.
Ein großer Vorteil der Orchestrierung ist, dass die Kollaboration der Microservices explizit definiert wird. Damit gibt es eine Stelle, an der man beispielsweise die Bestellabwicklung verstehen, analysieren oder auch ändern kann. Werden grafische Notationen wie Business Process Model and Notation (BPMN) verwendet, so können unterschiedliche Stakeholder an Diskussionen beteiligt werden. Das kann auch während der Laufzeit geschehen, wenn zum Beispiel eine Prozessinstanz auf Grund eines Fehlers stecken bleibt.
Die Orchestrierung erleichtert also die initiale Abstimmung, den Betrieb, die Wartung und die kontinuierliche Weiterentwicklung.
Was ist nun der Haken? Eigentlich gibt es keinen. Es bestehen jedoch hartnäckige Missverständnisse, die sich meist darum drehen, dass Orchestrierung ein zentralisiertes Modell ist, ein Bottleneck, das außerdem die Autonomie der Teams verletzt, was wir bei Microservices nicht haben wollen. Oft werden dazu noch gescheiterte BPM- und SOA-(Business-Process-Management- und Service-Oriented-Architecture-)Vorgehen der letzten Dekade aus der Schublade gezogen. Dort wurden allerdings auch Prozesse inhaltlich in einer zentralen Abteilung definiert und die Technologie war meist zu komplex und nicht skalierbar. Die Ausgangssituation damals war also eine ganz andere als heute.
Wann lieber Choreographie?
Es gibt jedoch trotzdem Anforderungen, für die die Orchestrierung nicht unbedingt die beste Lösung ist. Welche Anforderungen können das sein? Nun, bei der Orchestrierung muss der koordinierende Part sein Gegenüber kennen. Betrachtet man etwa den Bestellabwicklungsprozess, so gibt es vielleicht Dienste, die dieser nicht kennen sollte. Beispielsweise könnte man einen Benachrichtigungsservice aufsetzen, der den Kunden über Statusveränderungen informiert. Hier kann es sinnvoller sein, dass der Bestellprozess lediglich bestimmte fachliche Ereignisse publiziert (z. B. Bestellung erhalten, Bestellung bezahlt, Bestellung verschickt), auf die andere reagieren können. In diesem Beispiel könnte dann neben dem Benachrichtigungsservice auch ein Bonuspunkteservice auf diese Ereignisse reagieren, um das Bestellvolumen von Kunden auszuwerten.
Dies wird als Choreographie bezeichnet. Dabei gibt es eine dezentrale Kommunikation zwischen den Microservices, wobei jeder Microservice eigenständig auf Ereignisse reagiert, die er von anderen Services empfängt. Es gibt keine Orchestrierungskomponente, die die Reihenfolge der Aktionen bestimmt.
Den Vorteil dieses Vorgehens kann man im Beispiel oben schon erkennen: Der Bonuspunkteservice könnte jederzeit neu eingeführt oder verändert werden, ohne dass der Service zur Bestellabwicklung angefasst werden müsste. Gleiches gilt für die Benachrichtigungen: Das Team rund um Bestellabwicklung muss lediglich sinnvolle fachliche Ereignisse zum richtigen Zeitpunkt auslösen, sich aber nicht damit beschäftigen, wann welche Benachrichtigung auf welchem Kanal wie genau rausgeht.
Allerdings kann Choreographie die Komplexität erhöhen, da die Abfolge von Aktionen schwer vorhersehbar und nachvollziehbar sein kann (was ja eigentlich auch die Idee ist). Die Fehlererkennung und -behebung ist somit deutlich erschwert.
Mythos lose Kopplung
Choreographien gelten gerne als lose gekoppelt. Wenn Sie genau hinschauen, gilt das aber nur für die zeitliche Kopplung rund um den technischen Transport der Ereignisse, da meist Messaging- oder Event-Bus-Systeme zum Einsatz kommen. Das bedeutet, dass ein Ereignis auch dann abgesetzt werden kann, wenn der Empfänger nicht zur Verfügung steht.
Fachlich sind die zwei Services aber dennoch gekoppelt, denn natürlich will ich nur eine Versandbestätigung schicken, wenn die Bestellung auch versendet wurde. Und diese fachliche Kopplung bleibt bestehen. Daher sind natürlich auch choreographierte Microservices gekoppelt. Allerdings erfolgt die Kopplung quasi anders herum. Während bei der Bezahlung einer Bestellung die Bestellabwicklung weiß, dass sie den Bezahlservice verwendet (und dieser keine Ahnung hat, wer ihn aufruft), weiß der Benachrichtigungsservice, auf welche Events er reagieren muss (die Bestellabwicklung hat aber keine Ahnung, wer alles ihre Ereignisse verwendet). Ein letzter Hinweis an dieser Stelle noch: Auch Orchestrierung kann natürlich über Messaging zeitlich entkoppelt kommunizieren.
Somit sind aus meiner Sicht beide Varianten gleichberechtigt im Maß der Kopplung, nur anders ausgestaltet. Und je nach fachlicher Situation ist eben die eine oder die andere Variante sinnvoller.
Fazit
Gibt es einen logischen Fluss von Ereignissen, also einen fachlich gewollten Prozess, spielt die Orchestrierung ihre Stärken aus. Gibt es stabile fachliche Events und Zusatzoptionen, die für den eigentlichen Geschäftsprozess wenig relevant sind, kann Choreographie die bessere Wahl sein und den eigentlichen Orchestrierungsprozess fokussiert halten.
Somit kommen in größeren Projekten meistens beide Kollaborationsstile zum Einsatz und es gilt, die richtige Balance zu finden. Dies ist leider nicht ganz einfach und erfordert etwas Erfahrung. In "Practical Process Automation" gibt es ein ganzes Kapitel zu dieser Frage mit mehr Beispielen [2].
Eine gute Daumenregel für den Anfang ist auch, mit Orchestrierung zu starten, da dies vor allem für Unternehmen, die neu in der Microservices-Welt sind, viel einfacher zu verstehen und zu beherrschen ist. Und dann wird Choreographie eingemischt, wann immer es sinnvoll ist.
