Die versteckten Kosten zustandsbehafteter Orchestrierung

SchemaBridge Team · 2026-02-02 · Distributed Systems, Immutable Infrastructure, Orchestration, Anti-Patterns, Reliability

Warum Ihre „einfachen“ internen Tools Ihr größtes Zuverlässigkeitsrisiko sein könnten – und wie Immutable-Infrastructure-Muster in der Anwendungslogik Abhilfe schaffen.

In der Welt der Microservices sind wir besessen von Entkopplung. Wir nutzen Queues, setzen auf ereignisgesteuerte Architekturen und zerschlagen Monolithen. Und doch begehen wir innerhalb unserer Orchestrierungs-Engines oft die Kardinalsünde verteilter Systeme: Wir schreiben zustandsbehaftete Schleifen.

Bei SchemaBridge haben wir kürzlich unsere zentralen System-Workflows überarbeitet – diejenigen, die unsere eigenen schrittweisen Rollouts steuern. Dabei sahen wir uns mit denselben Anti-Patterns konfrontiert, die viele Engineering-Organisationen plagen. Das ist nicht nur eine Geschichte über unsere Release Notes; es ist eine Übung darin, Immutable-Infrastructure-Prinzipien auf die Anwendungsschicht anzuwenden.

Das „Schleifen“-Anti-Pattern

Betrachten Sie den klassischen „Poller“:

while not deployment.is_ready():
    sleep(60)
    check_status()

Dieser Code setzt ein stabiles Universum voraus. Er geht davon aus, dass der Polling-Prozess ewig lebt. In Wirklichkeit ist das ein Artefakt eines verteilten Monolithen. Ein Prozess, der seinen Zustand über ein langes synchrones Warten hinweg im Speicher hält, ist fragil: Startet sein Host neu oder hängt ein Aufruf, verliert er diesen Zustand oder bleibt als „Zombie“ zurück, auf den niemand achtet – und seine Fehlermodi werden unvorhersehbar.

Die Lösung: Rekursive Verkettung

Wir sind von einer internen while-Schleife zu einem rekursiven Ausführungsmodell übergegangen, ähnlich dem Continuation Passing Style aus der funktionalen Programmierung.

Muster: Jede Runde startet einen Monitor-Child-Workflow, der mit einem dauerhaften DELAY-Schritt statt mit sleep() wartet; anschließend startet ein SPAWNER-Schritt die nächste Runde als Child-Workflow – der Rollout-Workflow startet einen weiteren Run von sich selbst.
Ergebnis: Der Parent wartet weiterhin darauf, dass sein Child sich zurückmeldet, aber er wartet dauerhaft: Die Wartezeit ist eine Zeile in PostgreSQL (ein WAIT_ALL-Merge, der den Callback des Childs erwartet), kein Thread und keine In-Memory-Schleife. Stirbt ein Worker mitten im Rollout, geht nichts verloren; der Datenbankzustand bleibt die Single Source of Truth.

Unveränderliche Logik: Versionierung mit kanonischem Hashing

Versionierung ist bekanntlich schwierig. Wenn Sie eine Workflow-Definition aktualisieren, was passiert mit den bereits laufenden Ausführungen?

Das Anti-Pattern: „In-place-Updates“. Sie deployen neuen Code, und bestehende Ausführungen verhalten sich plötzlich anders.
Der Industriestandard: Immutable Infrastructure. So wie wir uns nicht per SSH auf Server einloggen, um sie zu patchen (wir ersetzen sie), sollten wir auch laufende Workflow-Definitionen nicht patchen.

Workflow-Versionen sind in SchemaBridge unveränderlich: Ein Deploy erzeugt eine neue Version, und ein Run ist an die Version gebunden, mit der er gestartet wurde. Neu hinzugekommen ist kanonisches DSL-Hashing: Jede importierte Workflow-Definition wird in eine kanonische JSON-Form serialisiert und gehasht, und der Hash wird mit dem Workflow gespeichert (dslHash).

Dieser Hash beantwortet eine Frage, die früher überraschend schwer zu beantworten war – hat sich die Logik tatsächlich geändert? Wenn ein Konfigurationsimport oder unser eigenes System-Workflow-Bootstrapping auf eine Definition trifft, deren Hash mit dem bereits Live-Stand übereinstimmt, plant er ein No-op, statt neu zu deployen; und ein Live-Workflow, der von seiner Quelldefinition abgewichen ist, lässt sich durch einen Hash-Vergleich erkennen.

Den „God Mode“ abriegeln

Schließlich haben wir uns der Sicherheit interner Tools gewidmet. Es ist üblich, internen „Cleanup“-Skripten Root-Zugriff zu geben. Das verstößt gegen das Prinzip der minimalen Rechte (Principle of Least Privilege).

Wir stellten fest, dass unser eigenes internes „Gradual Rollout“-Tool die Workflows, auf denen es operierte, über fest codierte logische IDs fand – was es leicht machte, es auf den falschen Workflow zu richten und diesen zu überschreiben. Wir haben das auf zwei Arten behoben:

Auflösung nach Rolle, nicht nach Name: Der Rollout findet seinen Ziel-Einstiegspunkt jetzt über explizite Tags, die auf Eindeutigkeit geprüft werden, statt über fest codierte Lookups logischer IDs.
Ein Credential mit minimalen Rechten: Die Gateway-Schritte in unseren Rollout-Workflows authentifizieren sich mit einem eigenen benannten API-Key, dem bewusst config:manage fehlt – die Berechtigung, die Konfiguration des System-Tenants umzuschreiben. Die Automatisierung, die vom am wenigsten vertrauenswürdigen Ort aus läuft, kann die Regeln, unter denen sie läuft, nicht mehr ändern.

Fazit

Wenn Ihre Orchestrierung auf sleep() beruht, kämpfen Sie gegen die Cloud.

Indem wir Rekursion, Unveränderlichkeit und minimale Rechte konsequent nutzen, gelangen wir von „hoffnungsbasierter“ Orchestrierung zu einer Orchestrierung, deren Zustand Sie inspizieren und deren Schadensradius Sie begrenzen können.

Weiterführende Literatur: