Infrastructure as Workflow: Mehr als statisches Terraform

SchemaBridge Team · 2026-01-18 · IaC, DevOps, Cloud Automation

Day-2-Cloud-Betrieb beherrschen: Infrastruktur als zustandsbehafteten, lang laufenden Geschäftsprozess behandeln.

Die Grenze von „Infrastructure as Code“: Day 1 vs. Day 2

Wir lieben Terraform (IaC). Es hat das Problem der Bereitstellung an „Day 1“ gelöst. Sie beschreiben Ihren Sollzustand (10 EC2-Instanzen, 1 RDS, 1 VPC), führen terraform apply aus, und der Cloud-Anbieter setzt ihn um. Für statische Ressourcen ist das perfekt. Es ist deklarativ, idempotent und versionskontrolliert. Es ist das Fundament modernen DevOps.

Doch die Realität des Cloud-Betriebs ist: An Day 2 steckt die Komplexität. Day 1 ist die Hochzeit; Day 2 ist die Ehe. Bei Day 2 geht es um Prozesse, nicht nur um Ressourcen. Es geht um den lebendigen Lebenszyklus des Systems, während es sich im Laufe der Zeit verändert.

Betrachten Sie den Lebenszyklus eines kritischen Datenbank-Upgrades. Das ist kein statisches Ereignis, sondern ein Workflow:

1. Vorbereitung: Zur Sicherheit einen Snapshot der primären DB nach S3 erstellen.

2. Warten: Sie müssen warten, bis der Snapshot fertig ist. Bei einer großen Datenbank mit mehreren TB kann das 30 bis 45 Minuten dauern.

3. Bereitstellung: Aus dem Snapshot eine neue DB-Instanz mit der neuen Engine-Version hochfahren.

4. Warten: Warten, bis die neue Instanz „Available“ und „Healthy“ ist.

5. Migration: Mit der neuen Instanz verbinden und ein Schema-Migrationsskript (Flyway oder Liquibase) ausführen. Das kann 1 Stunde dauern.

6. Verifikation: Eine Reihe von Smoke-Tests gegen die neue DB ausführen, um die Datenintegrität sicherzustellen.

7. Umschaltung: Bei Erfolg den DNS-CNAME auf die neue DB umstellen.

8. Rollback: Schlägt ein Schritt fehl, müssen Sie den DNS-Eintrag zurücksetzen und die defekte Instanz zerstören.

Terraform passt dafür schlecht. Es ist deklarativ, nicht imperativ. Für „30 Minuten warten“ oder „ein SQL-Skript ausführen und den Exit-Code prüfen“ gibt es zwar time_sleep und local-exec-Provisioner als Notausgänge, aber Terraform hat kein dauerhaftes, fortsetzbares, durch Freigaben gesteuertes Prozessmodell. Um das abzudecken, verpacken Teams Terraform meist in Jenkins-Pipelines, CircleCI-Jobs oder Python-Skripte. Damit sind wir wieder bei der „Glue Code Crisis“, die wir früher in dieser Serie besprochen haben — nur diesmal für Infrastruktur. Diese Skripte sind fragil, zustandslos und praktisch nicht zu debuggen, wenn sie mitten in einer vierstündigen Operation scheitern.

Betriebsabläufe als dauerhafte Workflows behandeln

Bei SchemaBridge sind wir überzeugt: Infrastrukturbetrieb ist ein Geschäftsworkflow. Er hat dieselben Anforderungen wie ein Zahlungsverarbeitungs-Flow: Zuverlässigkeit, Auditierbarkeit, Zustandsverwaltung und Fehlerbehebung.

Wenn Sie Ihren Day-2-Betrieb in SchemaBridge verlagern, erhalten Sie die Leistungsfähigkeit eines dauerhaften Orchestrators für Ihre Cloud:

Das „Control Plane“-Muster: Integration mit AWS, K8s und Terraform

SchemaBridge ersetzt Terraform nicht; es orchestriert es. Wir nutzen das Control-Plane-Muster, um die statische und die dynamische Welt zu vereinen.

1. Der Auslöser: Ein Entwickler committet Code oder startet aus Ihrem Developer-Portal einen „Provision Dev Env“-Workflow, indem er die Webhook-URL des Workflows aufruft.

2. Die Bereitstellung: SchemaBridge ruft die Terraform-Cloud-API (oder den HTTP-Endpunkt Ihres eigenen Runners) auf, um den Run zu starten, der die physischen Ressourcen erzeugt. SchemaBridge ruft terraform nicht selbst über eine Shell auf: Workflow-Skripte laufen bewusst in einer GraalVM-Sandbox ohne Prozess- oder Dateisystemzugriff.

3. Das Warten: Ein dauerhafter Delay-Schritt wartet, danach prüft ein Gateway-Schritt den Status des Terraform-Runs. Workflows sind azyklische Graphen; statt einer endlosen Polling-Schleife verketten Sie daher eine begrenzte Anzahl von Warte-und-Prüf-Schritten oder lassen den Workflow sich nach einem Delay selbst neu spawnen — dieselbe Rekursion, die auch unser eigener System-Workflow für schrittweise Rollouts verwendet.

4. Die Nachbereitung (die „Logikschicht“): Sobald die Infrastruktur existiert, ruft SchemaBridge die Endpunkte auf, die die DB-Migrationen ausführen, die Testdaten einspielen und die Abnahmetests anstoßen — die API Ihres CI-Systems oder einen kleinen Ops-Service unter Ihrer Kontrolle innerhalb des neuen Clusters.

Mit diesem Muster bleiben Ihre Ressourcen in HCL (HashiCorp Configuration Language) definiert, während Ihre Betriebslogik in einem visuellen Graphen definiert ist.

Ephemere Umgebungen: Der Heilige Gral der Entwicklergeschwindigkeit

Jedes moderne Engineering-Team wünscht sich ephemere Umgebungen — eine vollständige Kopie der Produktion für jeden Pull Request (PR). Das ermöglicht echte Isolation und verhindert Bugs, bevor sie nach main gemergt werden.

Herkömmliche Ansätze scheitern, weil das Aufräumen schwierig ist. Sie fahren Ressourcen für PR-123 hoch, aber der Entwickler vergisst, den PR zu schließen, oder das Cleanup-Skript schlägt fehl. Ihre Cloud-Rechnung explodiert durch „Zombie-RDS-Instanzen“ und „verwaiste Load Balancer“.

Mit SchemaBridge ist eine Umgebung ein Workflow mit definiertem Lebenszyklus.

1. Start: Ressourcen (RDS, einen Cache, ECS-Services) über Ihre Provisioning-API hochfahren.

2. Warten: Ein dauerhafter Delay-Schritt schärft den Abbau bereits bei der Erstellung — zum Beispiel mit einer TTL von 24 Stunden. Das Warten belegt weder Worker noch Container; der Weckzeitpunkt wird persistiert.

3. Aufräumen: Wenn der Timer abläuft, wacht der Workflow auf und ruft Ihre Provisioning-API auf, um die Umgebung zu zerstören. Für „abbauen, sobald der PR gemergt ist“ richten Sie den Merge-Webhook Ihres Git-Anbieters auf einen separaten Teardown-Workflow und gestalten den Abbau idempotent, damit es nicht schadet, wenn beide auslösen.

Da der Teardown-Timer im selben Run geschärft wird, der die Umgebung erstellt hat, ist er schwer zu vergessen. Selbst wenn der gesamte SchemaBridge-Cluster neu startet, feuert der persistierte Timer trotzdem, und die Umgebung von PR-123 wird planmäßig zerstört. Das ist „Garbage Collection für die Cloud“.

Illustratives Szenario: Blue/Green-Deployment ohne manuelle Eingriffe für einen latenzkritischen Service

Stellen Sie sich ein Team vor, das eine latenzkritische Matching-Engine betreibt und seinen Kernservice ohne eine Mikrosekunde Ausfallzeit aktualisieren muss.

Die Herausforderung

Ein standardmäßiges Kubernetes-Rolling-Update wäre nicht sicher genug, wenn das Team die Korrektheit der neuen Version 10 Minuten lang auf Live-Daten verifizieren müsste, bevor der Traffic umgeschaltet wird. Es bräuchte ein komplexes „Shadow Mode“-Deployment.

Der SchemaBridge-Ansatz

Das Team könnte in SchemaBridge einen „Blue/Green Deployment Workflow“ bauen:

1. Green deployen: Die neue Version der Engine neben der alten hochfahren (Green).

2. Shadow-Traffic: Das API-Gateway so konfigurieren, dass es eine generische Kopie des Live-Traffics an Green sendet (Fire-and-Forget). Die Antworten von Green gehen nicht an Nutzer, sondern werden aufgezeichnet.

3. Verifizieren: Nach einem 10-minütigen Delay holt der Workflow per HTTP eine Stichprobe der aufgezeichneten Antworten von Green und der zugehörigen Antworten von Blue (live) und vergleicht sie mit JSONata.

4. Entscheidungspunkt: Bedingte Kanten routen anhand des Vergleichsergebnisses:

5. Umschalten: Der Workflow aktualisiert den Load Balancer, um den echten Nutzer-Traffic auf Green umzuschalten.

6. Aufräumen: Er wartet eine weitere Stunde (für ein einfaches Rollback) und zerstört dann Blue.

Das Ergebnis

Ein solcher Workflow könnte das Deployment-Risiko erheblich senken. Ein SRE-Team könnte ein Deployment auslösen und sich anderen Dingen zuwenden, im Wissen, dass der Workflow die Verifikation und den expliziten Cleanup-Pfad ausführt, den es entworfen hat — und so riskante, seltene Releases in sicherere Routine verwandeln.

Kostenmanagement: Der „Workflow“ von FinOps

Cloud-Kostenoptimierung (FinOps) ist oft ein manueller Prozess, bei dem Entwickler ständig ermahnt werden, Dinge abzuschalten. Mit SchemaBridge können Sie diese Governance automatisieren.

Das Night-Watchman-Muster

Sie können einen „Night Watchman“-Workflow deployen, der jeden Abend um 20:00 Uhr läuft.

1. Scannen: Fragen Sie Ihre Ops-API (zum Beispiel eine kleine Lambda-Funktion oder einen internen Service, der Ihr Cloud-SDK kapselt) nach allen als Nicht-Produktion getaggten Ressourcen. SchemaBridge kommuniziert per HTTP mit ihr; es hat keinen nativen AWS-Connector.

2. Aktivität prüfen: Lassen Sie denselben Endpunkt die CPU-Auslastung der letzten Stunde melden und behalten Sie nur die Ressourcen unter 5 %.

3. Herunterfahren: Bei Leerlauf den Endpunkt aufrufen, um die Instanz zu stoppen (nicht zu terminieren).

4. Benachrichtigen: Eine Slack-Nachricht an den Besitzer senden: „Wir haben Ihre Dev-Box pausiert, um Geld zu sparen.“

5. Fortsetzen: Ein separater „Start my box“-Workflow, der aus Ihren Ops-Werkzeugen über seine Webhook-URL ausgelöst wird, startet die Instanz am Morgen wieder.

Ein solch einfacher Workflow kann die Ausgaben für ungenutzte Dev-Umgebungen spürbar senken und die laufenden Kosten vergessener, dauerhaft laufender Nicht-Produktionsressourcen reduzieren.

Vergleich: Jenkins/GitLab CI vs. SchemaBridge-Betrieb

| Merkmal | CI/CD-Pipelines (Jenkins) | SchemaBridge-Betrieb |

| :--- | :--- | :--- |

| Zustand | An einen Executor gebunden; lange Wartezeiten belegen Ressourcen | Dauerhaft (in PostgreSQL persistiert; übersteht Neustarts) |

| Dauer | Minuten/Stunden | Stunden/Tage (dauerhafte Timer) |

| Logik | Skriptbasiert (Bash/Groovy) | Visuell (Graph) |

| Freigabe | Input-Schritt in der Pipeline | Approval-Schritt (UI oder API) mit Timeout |

| Wiederherstellung | Neustart ab einer Stage | Erneute Ausführung ab dem fehlgeschlagenen Schritt |

| Parallelität | Durch Executors begrenzt | Fan-out (Spawner) mit automatisch skalierten Workern |

Experten-Checkliste für Ops-Automatisierung

Um Ihren Betriebs-Stack zu modernisieren, befolgen Sie diese Heuristiken:

1. Warten nicht skripten: Wenn Sie in Bash sleep 60 schreiben, um auf einen ALB zu warten, machen Sie es falsch. Verwenden Sie einen dauerhaften Delay-Schritt, gefolgt von einer Statusprüfung.

2. Zuerst das Löschen automatisieren: Schreiben Sie die Cleanup-Logik vor der Erstellungslogik. Stellen Sie sicher, dass jedes Erstellungsereignis einen passenden Zerstörungspfad hat.

3. Freigabe-Gates nutzen: Scheuen Sie sich nicht, bei risikoreichen Aktionen einen Menschen einzubinden. Ein „Pause for Approval“ ist ein Feature, kein Bug.

4. Den Operator auditieren: Protokollieren Sie, wer die Umgebung ausgelöst hat und warum. Lassen Sie den Auslöser die ID des Anfragenden im Payload mitgeben und versehen Sie jede erstellte Ressource damit.

5. Ops als Code behandeln: Versionieren Sie Ihre Betriebs-Workflows genau wie Ihren Anwendungscode. Exportieren Sie sie als Bundles, legen Sie sie zur Review in Ihrem Repository ab und deployen Sie sie über die Deployments-Seite (planen, prüfen, anwenden) oder einen Konfigurationsimport.

Fazit: Die Cloud ist ein Zustandsautomat

Ihre Infrastruktur ist kein statischer Haufen Server; sie ist ein lebendiger Bestandteil Ihres Geschäfts. Wenn Sie sie als Zustandsautomaten behandeln, können Sie die komplexen, mehrstufigen Betriebsabläufe automatisieren, die heute das Leben Ihres SRE-Teams auffressen. Sie können von „ticketbasiertem Betrieb“ zu „Self-Service-Betrieb“ wechseln — mit eingebauter Sicherheit und Dauerhaftigkeit.

Siehe auch: Der Cold-Start-Mythos: Die JVM für Events optimieren — warum lang laufende Worker Kaltstarts pro Event schlagen.

Ansehen