Infrastruktur als Workflow: Jenseits von statischem Terraform

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

Day-2-Cloud-Betrieb managen. 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 des „Day 1"-Provisionierens gelöst. Sie beschreiben den gewünschten Zustand (10 EC2-Instanzen, 1 RDS, 1 VPC), führen terraform apply aus, und der Cloud-Anbieter setzt ihn um. Das ist perfekt für statische Ressourcen. Es ist deklarativ, idempotent und versionskontrolliert. Es ist das Fundament von modernem DevOps.

Aber die Realität des Cloud-Betriebs ist: Die Komplexität steckt in Day 2. Day 1 ist die Hochzeit; Day 2 ist die Ehe. Day 2 dreht sich um Prozesse, nicht nur um Ressourcen. Es geht um den lebendigen, atmenden Lebenszyklus des Systems, während es sich über die Zeit verändert.

Betrachten wir den Lebenszyklus eines kritischen Datenbank-Upgrades. Das ist kein statisches Ereignis; es ist ein Workflow:

1. Vorbereitung: Snapshot der primären DB nach S3 zur Absicherung.

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

3. Provisionierung: Eine neue DB-Instanz aus dem Snapshot 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 laufen lassen, um die Datenintegrität sicherzustellen.

7. Umschaltung: Bei Erfolg den DNS-CNAME aktualisieren, sodass er auf die neue DB zeigt.

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

Terraform kann das nicht ausdrücken. Es ist deklarativ, nicht imperativ. Es weiß nicht, wie man „30 Minuten wartet" oder „ein SQL-Skript ausführt und den Exit-Code prüft". Um das zu bewältigen, greifen Teams meist darauf zurück, Terraform in Jenkins-Pipelines, CircleCI-Jobs oder Python-Skripte einzupacken. Wir sind wieder bei der „Glue-Code-Krise" (Teil 1) angelangt, nur diesmal für Infrastruktur. Diese Skripte sind brüchig, zustandslos und unmöglich zu debuggen, wenn sie mitten in einer 4-stündigen Operation fehlschlagen.

Operationen als durable Workflows behandeln

Bei SchemaBridge glauben wir, dass Infrastruktur-Operationen Geschäfts-Workflows sind. Sie haben dieselben Anforderungen wie ein Zahlungsabwicklungsprozess: Zuverlässigkeit, Auditierbarkeit, Zustandsmanagement und Fehlerbehebung.

Indem Sie Ihre Day-2-Operationen zu SchemaBridge verlagern, gewinnen Sie die Kraft eines durablen 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 Trigger: Ein Entwickler committet Code oder löst manuell einen „Dev-Umgebung bereitstellen"-Workflow über das interne Developer-Portal (Backstage) aus.

2. Die Provisionierung: SchemaBridge ruft die Terraform-Cloud-API auf (oder führt ein terraform apply in einem sicheren Worker aus), um die physischen Ressourcen zu erzeugen.

3. Das Warten: Der Workflow pollt die Terraform-API, bis der Run sicher „Applied" ist. Er handhabt die asynchrone Natur der Cloud.

4. Die Nachbereitung (die „Logikschicht"): Sobald die Infrastruktur existiert, verbindet sich SchemaBridge mit dem neuen Kubernetes-Cluster, führt die DB-Migrationen aus, befüllt die Testdaten und führt die Abnahmetests durch.

Dieses Muster erlaubt es Ihnen, Ihre Ressourcen weiterhin in HCL (HashiCorp Configuration Language) zu definieren, während Ihre operative Logik in einem visuellen Graphen definiert bleibt.

Ephemere Umgebungen: Der heilige Gral der Entwickler-Velocity

Jedes moderne Engineering-Team möchte ephemere Umgebungen – ein vollständiges Abbild der Produktion für jeden Pull Request (PR). Das ermöglicht echte Isolation und verhindert Bugs, bevor sie in den Main-Branch gemergt werden.

Traditionelle Ansätze scheitern, weil sie schwer zu bereinigen sind. Sie starten Ressourcen für PR-123, 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 einem klar definierten Lebenszyklus.

1. Start: Ressourcen hochfahren (RDS, Redis, ECS-Services).

2. Warten: Der Workflow tritt in einen Wartezustand ein. Er wartet darauf, dass der PR gemergt wird, ODER dass eine vordefinierte TTL (z. B. 24 Stunden) verstreicht.

3. Bereinigung: Trifft das Signal ein oder läuft der Timer ab, wacht der Workflow automatisch auf und führt terraform destroy aus.

Weil die Bereinigungslogik Teil derselben durablen Workflow-Instanz ist wie die Erstellungslogik, ist es unmöglich, sie zu vergessen. Selbst wenn der gesamte SchemaBridge-Cluster neu startet, erinnert er sich daran, dass er die Umgebung von PR-123 um 17:00 Uhr zerstören muss. Das ist „Garbage Collection für die Cloud".

Fallstudie: Berührungslose Blue/Green-Deployments für Hochfrequenzhandel

Wir haben mit einer Hochfrequenzhandelsfirma zusammengearbeitet, die ihre zentrale Matching-Engine ohne eine Mikrosekunde Ausfallzeit aktualisieren musste.

Die Herausforderung

Ein Standard-Kubernetes-Rolling-Update war nicht sicher genug, weil sie die finanzielle Genauigkeit der neuen Version 10 Minuten lang an Live-Daten verifizieren mussten, bevor der Traffic umgeschaltet wurde. Sie brauchten ein komplexes „Shadow-Mode"-Deployment.

Die SchemaBridge-Lösung

Sie bauten einen „Blue/Green-Deployment-Workflow" in SchemaBridge:

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

2. Shadow-Traffic: Das API-Gateway (Teil 9) so konfigurieren, dass eine generische Kopie des Live-Traffics an Green gesendet wird (Fire-and-Forget). Die Antworten von Green werden nicht an Nutzer gesendet, aber erfasst.

3. Verifizieren: Der Workflow beobachtete die Logs von Green 10 Minuten lang. Er nutzte JSONata, um die finanziellen Outputs von Green mit Blue (der Live-Version) zu vergleichen.

4. Entscheidungspunkt:

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

6. Aufräumen: Er wartete eine weitere Stunde (für einen einfachen Rollback) und zerstörte dann Blue.

Das Ergebnis

Sie reduzierten ihr Deployment-Risiko auf nahezu null. Das SRE-Team konnte ein Deployment auslösen und zum Mittagessen gehen, im Wissen, dass der Workflow die komplexe Verifikation, Überwachung und Rollback-Logik automatisch übernehmen würde. Sie kamen von 1 Deployment pro Woche auf 10 Deployments pro Tag.

Kostenmanagement: Der „Workflow" von FinOps

Cloud-Kostenoptimierung (FinOps) ist oft ein manueller Prozess, bei dem Entwickler ständig ermahnt werden, Dinge abzuschalten. SchemaBridge erlaubt es Ihnen, diese Governance zu automatisieren.

Das „Nachtwächter"-Muster

Sie können einen „Nachtwächter"-Workflow deployen, der jeden Abend um 20:00 Uhr läuft.

1. Scan: Alle mit „Non-Production" getaggten Ressourcen isolieren.

2. Aktivität prüfen: CloudWatch-Metriken auf CPU-Auslastung < 5 % in der letzten Stunde prüfen.

3. Herunterfahren: Bei Inaktivität die Instanz stoppen (nicht terminieren).

4. Benachrichtigen: Eine Slack-Nachricht an den Owner senden: „Wir haben deine Dev-Box pausiert, um Kosten zu sparen. Hier klicken zum Fortsetzen."

5. Fortsetzen: Klickt der Entwickler morgens auf die Schaltfläche, weckt ein Signal (Teil 7) den Workflow, um die Instanz wieder zu starten.

Dieser einfache Workflow sparte einem unserer Enterprise-Kunden 40.000 $ pro Monat an AWS-EC2-Kosten.

Vergleich: Jenkins/GitLab CI vs. SchemaBridge-Operationen

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

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

| Zustand | Ephemer (geht bei Neustart verloren) | Durabel (überdauert Jahre) |

| Dauer | Minuten/Stunden | Tage/Wochen/Monate |

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

| Freigabe | Basic (UI-Button) | Umfangreich (Slack/E-Mail/Webhooks/Mobil) |

| Wiederherstellung | Neustart von vorn | Fortsetzung ab dem Fehlerpunkt |

| Parallelität | Begrenzt durch Executor-Anzahl | Serverloses Scaling (Teil 3) |

Experten-Checkliste für Ops-Automatisierung

Um Ihren operativen Stack zu modernisieren, folgen Sie diesen Heuristiken:

1. Warten Sie nicht skriptbasiert: Wenn Sie sleep 60 in Bash schreiben, um auf einen ALB zu warten, machen Sie es falsch. Nutzen Sie eine Polling-Schleife in einem durablen Workflow.

2. Automatisieren Sie zuerst das Löschen: Schreiben Sie die Bereinigungslogik vor der Erstellungslogik. Stellen Sie sicher, dass jedes Erstellungsereignis einen passenden Zerstörungspfad hat.

3. Nutzen Sie Freigabe-Gates: Scheuen Sie sich nicht, bei risikoreichen Aktionen einen Menschen in die Schleife einzubauen. Eine „Pause für Freigabe" ist ein Feature, kein Bug.

4. Prüfen Sie den Operator: Protokollieren Sie, wer die Umgebung ausgelöst hat und warum. Nutzen Sie den Workflow-Kontext, um Ressourcen mit der User_ID des Anfragenden zu taggen.

5. Behandeln Sie Ops als Code: Versionieren Sie Ihre operativen Workflows genau wie Ihren Anwendungscode. Nutzen Sie die Git-Integration von SchemaBridge, um Änderungen an Ihrer Deployment-Logik zu überprüfen.

Fazit: Die Cloud ist eine Zustandsmaschine

Ihre Infrastruktur ist kein statischer Haufen Server; sie ist eine lebendige, atmende Komponente Ihres Geschäfts. Indem Sie sie als Zustandsmaschine behandeln, können Sie die komplexen, mehrstufigen operativen Abläufe automatisieren, die derzeit das Leben Ihres SRE-Teams auffressen. Sie können von „Ticket-basierten Ops" zu „Self-Service-Ops" wechseln, mit eingebauter Sicherheit und Durabilität.

In Teil 12 werfen wir einen Blick auf den „Cold-Start-Mythos" und wie man in einer serverlosen Event-Architektur Sub-Millisekunden-Latenz erreicht, ohne Server warmzuhalten.

Ansehen