Der Ausgangspunkt.
Die Plattform bestand aus verbundenen Komponenten für Dokumentverarbeitung und AI-gestützte Workflows. Ihre Umgebungen teilten keinen einzigen verlässlichen Einrichtungsweg. Ein Deployment konnte an einem Ort funktionieren und am nächsten schwer reproduzierbar sein.
Nur von einer Cloud-Migration zu sprechen, hätte das Ziel beschrieben, nicht die eigentliche Arbeit. Entscheidend war, einmalige Infrastruktur und Abläufe durch ein Modell zu ersetzen, das lesbar, prüfbar und wiederholbar ist.
Was das Design lösen musste.
Das neue Plattformmodell musste vier Dinge sichtbar machen:
- Mehrere Anwendungskomponenten mussten derselben Delivery-Logik folgen.
- Unterschiede zwischen Umgebungen mussten Konfiguration sein, keine undokumentierte Handarbeit.
- Infrastrukturänderungen mussten vor einer aktiven Umgebung prüfbar sein.
- Anwendungs-Workloads und verwaltete Cloud-Dienste brauchten eine klare Betriebsgrenze.
Die Diagnose.
Der fragile Teil war kein einzelner Dienst. Es war der Weg vom Quellcode zu einer laufenden Umgebung. Wenn dieser Weg je Umgebung variiert, trägt jede Änderung versteckte Annahmen mit sich.
Ich behandelte Reproduzierbarkeit als zentrale Anforderung. Infrastrukturdefinitionen, Cluster-Workloads und Umgebungswerte brauchten getrennte Verantwortlichkeiten, sollten aber denselben Delivery-Weg durchlaufen.
Das resultierende Plattformmodell.
GitLab CI/CD bildet den Delivery-Weg. Terraform definiert das Google-Cloud-Fundament, GKE die Workload-Schicht, und verwaltete Dienste übernehmen Plattformaufgaben, die nicht in Anwendungscontainer gehören.
Entscheidungen, die zählten.
Die Migration wurde durch bewusst gesetzte Grenzen verlässlich.
Module wiederverwenden, Eingaben variieren
Wiederverwendbares Terraform hält das Fundament konsistent. Umgebungsspezifische Werte bleiben sichtbare Eingaben, statt zu kopierter Infrastruktur zu werden.
Das verlangt strengere Modulverträge. Genau dort ist diese Disziplin sinnvoll.
Ein Laufzeitmodell für alle Workloads
GKE gibt den Anwendungskomponenten ein einheitliches Deployment-Ziel und macht ihre Laufzeitkonfiguration gemeinsam verständlich.
Ein gemeinsames Clustermodell braucht weiterhin klare Verantwortung für Namespaces, Konfiguration und Rollouts.
Managed Services gezielt einsetzen
Verwaltete Google-Cloud-Dienste nehmen den eigenen Workloads Plattformaufgaben ab, wo diese Grenze nützlich ist.
Der einfachere Betrieb bringt providerspezifische Entscheidungen mit, die in der Architektur sichtbar bleiben müssen.
Delivery und Prüfung.
Das Delivery-Modell führt Infrastruktur- und Workload-Änderungen über einen prüfbaren Weg in GitLab CI/CD. Terraform macht den gewünschten Cloud-Zustand sichtbar; das GKE-Modell gibt den Komponenten ein gemeinsames Ziel.
Die Prüfung folgt derselben Grenze: zuerst die Infrastrukturdefinition, dann die Plattformressourcen und schliesslich die darauf laufenden Workloads. Fehler lassen sich so leichter eingrenzen als mit einem eigenen Deployment-Skript pro Umgebung.
Das qualitative Ergebnis.
Infrastruktur und Delivery folgen nun einem wiederholbaren, nachvollziehbaren Weg. Die Plattform lässt sich als System besprechen, nicht als Sammlung von Umgebungsausnahmen.
Das wichtigste Ergebnis ist nicht allein, dass das System auf Google Cloud läuft. Der Weg zu einer laufenden Umgebung ist codiert, prüfbar und konsistent.