Orchestration
Eine zentrale Steuerung ruft die Beteiligten der Reihe nach auf
Die Idee und ihr Nutzen
Eine Versicherung bearbeitet einen gemeldeten Wasserschaden in mehreren Schritten: Zuerst prüft ein Programm, ob der Vertrag den Schaden abdeckt, dann erstellt ein Gutachter ein Gutachten, danach wird der Betrag ausgezahlt. Für jeden Schritt ist ein eigenes Programm zuständig, ein sogenannter Dienst. Ein zusätzliches Steuerprogramm, der Orchestrator, ruft die Dienste in der festgelegten Reihenfolge auf, speichert für jeden Schadenfall, welcher Schritt gerade läuft, und entscheidet anhand jeder Antwort über den nächsten Schritt. Die Sachbearbeitung der Versicherung sieht dadurch im Orchestrator jederzeit, bei welchem Schritt jeder Schadenfall steht, etwa dass ein Fall auf das Gutachten wartet. Diese Bauweise heißt Orchestration, auf Deutsch Orchestrierung.
Wie funktioniert es?
Für den neuen Wasserschaden 4711 startet der Orchestrator einen Ablauf und fragt zuerst den Prüfdienst, ob der Vertrag den Schaden abdeckt. Der Prüfdienst antwortet „gedeckt“. Daraufhin beauftragt der Orchestrator den Gutachterdienst, der das Gutachten bei einem Gutachter in Auftrag gibt. Der Orchestrator speichert dauerhaft, wie weit der Fall ist und dass für das Gutachten eine Frist von zehn Tagen läuft. Ein Gutachter braucht für einen Wasserschaden meist etwa eine Woche; die Frist lässt ihm diese Zeit und etwas Spielraum, ohne dass der Kunde lange auf sein Geld wartet. Trifft das Gutachten innerhalb der Frist beim Orchestrator ein, gibt die Sachbearbeitung der Versicherung den Betrag frei, und der Orchestrator beauftragt den Zahlungsdienst mit der Auszahlung. Ist nach zehn Tagen kein Gutachten eingetroffen, legt der Orchestrator stattdessen für die Sachbearbeitung die Aufgabe an, beim Gutachter nachzufragen. Weil der Orchestrator den Stand aller Fälle speichert, kann die Teamleitung der Sachbearbeitung diesen Stand jederzeit abfragen. Die Teamleitung sieht zum Beispiel, dass 37 Fälle auf ein Gutachten warten und bei 5 dieser Fälle schon mehr als acht der zehn Tage vergangen sind. Bei diesen Fällen bleiben der Teamleitung noch höchstens zwei Tage, um einzugreifen, bevor die Frist abläuft.
Das Entwicklungsteam schreibt den ganzen Ablauf mit Schritten, Reihenfolge, Verzweigungen und Fristen in eine einzige Ablaufbeschreibung, entweder als Programmcode oder als grafisches Ablaufmodell. Der Orchestrator arbeitet nach dieser Ablaufbeschreibung. Er ruft die Dienste auf oder schickt ihnen einen Auftrag. Ein solcher Auftrag lautet zum Beispiel „Prüfe die Deckung für Fall 4711“. Anhand jeder Antwort wählt der Orchestrator den nächsten Schritt. Liegt der Betrag zum Beispiel über 10.000 Euro, holt der Orchestrator eine zweite Freigabe ein. Die einzelnen Dienste kennen den Gesamtablauf nicht. Jeder Dienst erledigt nur seinen eigenen Schritt und meldet das Ergebnis zurück. Fachliche Berechnungen wie die Höhe des Auszahlungsbetrags bleiben in den Diensten, und der Orchestrator entscheidet nur über die Reihenfolge der Schritte. Lange Schritte halten den Orchestrator nicht auf: Während der Gutachter Tage für das Gutachten braucht, hält der Orchestrator keine Netzverbindung zum Gutachterdienst offen. Er speichert, dass Fall 4711 auf ein Gutachten wartet, und setzt den Ablauf fort, sobald der Gutachterdienst das Ergebnis meldet.
Der Orchestrator speichert den Stand nach jedem Schritt. Startet der Orchestrator nach einer Störung neu, liest er diesen Stand und setzt jeden Fall beim richtigen Schritt fort, ohne dass jemand die Fälle von Hand wieder anstößt. Bleibt eine Antwort aus oder schlägt ein Schritt fehl, kann der Orchestrator den Schritt wiederholen, eine Aufgabe für einen Menschen anlegen oder einen Ausgleichsschritt auslösen, der eine bereits erledigte Änderung rückgängig macht. Der Orchestrator verhindert nicht von selbst, dass ein wiederholter Schritt doppelt wirkt. Für jeden Schritt muss deshalb festgelegt sein, ob eine Wiederholung gefahrlos ist. Eine zweite Deckungsprüfung für Fall 4711 schadet nicht. Eine Auszahlung darf nicht zweimal ausgelöst werden. Deshalb beauftragt der Orchestrator den Zahlungsdienst für Fall 4711 nur einmal.
Orchestrierung: ein Orchestrator führt Wasserschaden 4711 durch alle Schritte
Wann ist es sinnvoll und wann nicht?
Orchestration lohnt sich
- Ein Ablauf ist lang und hat viele Schritte, Verzweigungen, Fristen und mögliche Ausgleichsschritte. Bei einem Wasserschaden folgen aufeinander: Deckung prüfen, Gutachter beauftragen, auf das Gutachten warten, Betrag berechnen und die Zahlung anweisen. Die Bearbeitung kann Tage oder Wochen dauern, und ein Teil der Schritte hängt von Menschen ab. Prüfdienst, Gutachterdienst und Zahlungsdienst speichern ihre Daten in eigenen Datenbanken, und kein gemeinsamer Speichervorgang kann alle Schritte zusammen bestätigen oder zurücknehmen. Ohne Orchestrator müsste jeder Dienst selbst wissen, welcher Dienst nach ihm an der Reihe ist und was bei einem Fehler zurückzunehmen ist. Mit Orchestrator steht der ganze Ablauf in der Ablaufbeschreibung, und der Orchestrator löst bei einem Fehler die Ausgleichsschritte aus.
- Sachbearbeitung, Teamleitung, Kunden und Prüfer wollen jederzeit wissen, wo ein Fall steht. Ohne zentrale Steuerung reagiert jeder Dienst nur auf Nachrichten der anderen Dienste: Der Prüfdienst meldet „gedeckt“, der Gutachterdienst reagiert darauf, und so weiter. Der Gesamtablauf ist dann nirgends vollständig beschrieben. Ruft ein Kunde an, weil sein Schaden seit drei Tagen nicht vorankommt, muss die Sachbearbeitung in mehreren Programmen nachsehen. Im Orchestrator sieht die Sachbearbeitung auf einen Blick, dass Fall 4711 auf ein Gutachten wartet.
- Fristen müssen überwacht werden. Ohne Orchestrator merkt kein Dienst, dass für Fall 4711 nach zehn Tagen noch kein Gutachten eingetroffen ist, weil jeder Dienst nur auf eingehende Nachrichten reagiert. Der Orchestrator speichert die Frist und legt nach zehn Tagen die Aufgabe für die Sachbearbeitung an, beim Gutachter nachzufragen.
- Der Ablauf ändert sich häufig. Eine neue Regel wie die zweite Freigabe über 10.000 Euro trägt das Entwicklungsteam nur in der Ablaufbeschreibung ein und nicht in vielen Diensten.
Orchestration ist nicht das Richtige
- Ein Dienst soll auf eine Nachricht hin etwas Eigenständiges erledigen. Ein Beispiel ist ein E-Mail-Dienst, der nach jeder Auszahlung dem Kunden eine Bestätigung schickt. Vom Versand der Bestätigung hängt kein weiterer Schritt des Falls ab, und niemand muss im Orchestrator nachsehen, ob die Bestätigung verschickt wurde. Dann reagiert der E-Mail-Dienst ohne zentrale Steuerung selbst auf die Nachricht des Zahlungsdienstes „Fall 4711 ausgezahlt“. Diese Bauweise heißt Choreography. Das Entwicklungsteam muss den Versand der Bestätigung nicht in die Ablaufbeschreibung eintragen, und die Bestätigung geht auch hinaus, wenn der Orchestrator gerade ausgefallen ist.
- Der Ablauf besteht aus zwei Schritten ohne Verzweigung und Frist. Der Orchestrator hätte dann nichts zu entscheiden und keine Frist zu überwachen, sondern würde nur den zweiten Dienst aufrufen, sobald der erste fertig ist. Stattdessen ruft der erste Dienst den zweiten direkt auf. Ein Steuerprogramm, das betrieben, überwacht und bei jeder Änderung am Ablauf angepasst werden muss, entfällt.
- Die beteiligten Dienste gehören verschiedenen Unternehmen. Ein gemeinsamer Orchestrator müsste die Dienste aller Unternehmen aufrufen, und keines der Unternehmen will einem fremden Steuerprogramm die Kontrolle über seine Schritte geben. Dann steuert jedes Unternehmen seine eigenen Schritte selbst, und die Unternehmen schicken einander nur Nachrichten über erledigte Schritte, wie bei der Choreography. Kein Unternehmen muss einem fremden Steuerprogramm erlauben, seine Dienste aufzurufen.
Nachteile und typische Fehler
Alle Abläufe hängen vom Orchestrator ab. Das Betriebsteam lässt den Orchestrator deshalb auf mehreren Servern gleichzeitig laufen, damit ein ausgefallener Server keinen Fall anhält, und speichert den Stand in einer Datenbank, die ihre Daten laufend auf einen zweiten Server kopiert. Der Orchestrator ist ein zusätzliches Programm oder eine zusätzliche Plattform, die das Entwicklungsteam betreiben, überwachen, aktualisieren und bei jeder Änderung am Ablauf anpassen muss. Ändert das Entwicklungsteam den Ablauf, während noch Tausende Fälle nach dem alten Ablauf laufen, muss es festlegen, welche Fälle nach welcher Fassung weiterlaufen. Dafür bekommt jede Fassung der Ablaufbeschreibung eine Versionsnummer, und jeder Fall läuft nach der Fassung weiter, mit der er begonnen hat. Ändert das Entwicklungsteam die Form eines Auftrags wie „Prüfe die Deckung für Fall 4711“, muss es auch den Prüfdienst anpassen.
Typische Fehler und woran man sie erkennt:
- Ausgefallener Orchestrator: Der Orchestrator fällt aus. Prüfdienst, Gutachterdienst und Zahlungsdienst laufen weiter, bekommen aber keine Aufträge mehr, und kein Fall kommt voran. Erkennbar ist das an Fällen, die alle zur selben Zeit stehen bleiben.
- Doppelte Auszahlung: Der Orchestrator beauftragt den Zahlungsdienst mit der Auszahlung für Fall 4711. Der Zahlungsdienst zahlt aus, aber seine Antwort geht unterwegs verloren. Weil für diesen Schritt Wiederholen eingestellt ist, schickt der Orchestrator den Auftrag noch einmal, und der Zahlungsdienst zahlt ein zweites Mal aus. Eine fehlende Antwort heißt nicht, dass der Auftrag nicht ausgeführt wurde. Erkennbar ist das an zwei Zahlungen zum selben Fall.
- Fehlender gespeicherter Stand: Der Orchestrator hält den Stand nur im Arbeitsspeicher. Nach einem Neustart weiß der Orchestrator nicht mehr, dass Fall 4711 auf ein Gutachten wartet. Meldet der Gutachterdienst danach das Gutachten, setzt der Orchestrator den Ablauf nicht fort, und nach zehn Tagen legt er auch keine Aufgabe für die Sachbearbeitung an. Erkennbar ist das an Fällen, die nach einer Störung nirgends mehr als laufend auftauchen.
- Fachliche Regeln im Orchestrator: Das Entwicklungsteam schreibt Regeln wie die Berechnung des Auszahlungsbetrags in die Ablaufbeschreibung statt in den zuständigen Dienst. Jede Änderung an einer solchen Regel ist dann eine Änderung am Orchestrator, von dem alle Abläufe abhängen. Erkennbar ist das an einer Ablaufbeschreibung, die Beträge berechnet, statt nur die Reihenfolge der Schritte festzulegen.
- Ablauf ohne Versionsnummer: Das Entwicklungsteam ändert den Ablauf ohne Versionsnummer, und laufende Fälle werden nach der neuen Fassung fortgesetzt, obwohl sie nach der alten begonnen haben. Erkennbar ist das an Fällen, die Schritte überspringen oder an einem Schritt hängen bleiben, den es in der neuen Fassung nicht mehr gibt.
Weiterführend
Verwandte Ansätze
- Saga: ein langer Ablauf über mehrere Dienste, bei dem Fehler durch Ausgleichsschritte behoben werden. Ein Orchestrator steuert Sagas häufig.
- Compensating Transaction: beschreibt die Ausgleichsschritte, die der Orchestrator bei Fehlern auslöst.
- Enterprise Service Bus: eine zentrale Verbindungssoftware zwischen Anwendungen, die oft auch eine Ablaufsteuerung enthält.
Werkzeuge und Umsetzungen
- Temporal: Plattform, in der Abläufe als gewöhnlicher Programmcode geschrieben werden. Temporal speichert den Stand jedes Ablaufs und setzt ihn nach Störungen fort.
- Conductor: Ablaufsteuerung für Dienste, ursprünglich bei Netflix entwickelt.
- Flowable: Ablaufsteuerung nach dem Standard BPMN, einer grafischen Darstellungsform für Geschäftsprozesse.
- Operaton: von einer Gemeinschaft weitergeführte Fassung der Ablaufsteuerung Camunda 7, ebenfalls nach BPMN.
- Apache Airflow: steuert Abläufe der Datenverarbeitung. Ein Beispiel ist das nächtliche Laden von Daten.
Quellen
- Microsoft: Saga distributed transactions pattern: beschreibt im Azure Architecture Center den Unterschied zwischen Orchestration und Choreography, einen Orchestrator, der den Stand jedes Schritts speichert und Ausgleichsschritte auslöst, sowie den Hinweis, dass der Orchestrator zur Fehlerquelle für den ganzen Ablauf werden kann.
- Chris Richardson: Implementing an orchestration-based saga: zeigt auf microservices.io, wie ein Orchestrator den beteiligten Diensten Aufträge schickt, seinen Stand in der Datenbank speichert und bei einem Fehler Ausgleichsschritte in umgekehrter Reihenfolge ausführt.