Cloud-Migration auf Kubernetes: Lessons Learned aus der Behörde

Die Anwendung lief seit Jahren auf WebLogic. Ein Fachverfahren für den elektronischen Rechtsverkehr, das Gerichte und Behörden jeden Tag brauchen. Ein Deployment dauerte einen Tag. Nicht wegen der Bits. Wegen Freigaben, Testfenstern und einem Wartungsslot, den mehrere Abteilungen absegnen mussten.

Das Ziel war klar: auf Kubernetes, ohne den Betrieb zu gefährden. Der Weg dorthin war das eigentliche Projekt. Vier Jahre lang war ich mit meinem Anteil daran beteiligt, Architektur, Plattform, Cutover.

Warum kein Big Bang

Ein Wochenende, ein Schalter, fertig: Das hätte in einem regulierten Haus niemand unterschrieben. Zu viele Abhängigkeiten, zu viel Risiko für einen Dienst, den Gerichte täglich nutzen. Also Strangler Fig statt Cutover an einem Stichtag. Jede Phase musste für sich stehen und einzeln abnehmbar sein.

Vier Phasen

Zuerst containerisieren, noch ohne Kubernetes: die Anwendung im Docker-Container, Verhalten identisch zum WebLogic-Deployment. Erst als das lief, kam die nächste Änderung.

Dann J2EE nach Quarkus: die J2EE-spezifischen APIs Stück für Stück ersetzt. Quarkus startet in Sekunden statt Minuten, und für Rolling Updates und Autoscaling ist das der Unterschied zwischen möglich und theoretisch.

Danach auf die Plattform: Rancher als Kubernetes-Distribution, Terraform für die Cluster, Helm für die Deployments, Istio als Mesh, GitLab CI/CD für die Pipeline. Keine der Komponenten war verhandelbar, jede schloss eine Lücke aus der Vorstufe.

Zuletzt absichern: Prometheus und Grafana für Metriken, SonarQube für Code-Qualität, NexusIQ für Dependency-Scans. Ohne diese Schicht hätte niemand dem Team erlaubt, wöchentlich statt quartalsweise zu releasen.

Die Dashboards, die am Ende zählten, waren nicht die mit den meisten Panels. Latenz pro Endpunkt, Fehlerquote nach Deployment, Pod-Neustarts über die Zeit. Drei Werte, die zusammen zeigen, ob ein Release sauber war, bevor ein Nutzer sich meldet. Alles andere war für den Nachweis gegenüber der IT-Sicherheit wichtig, aber nicht für die tägliche Frage, ob der letzte Deploy hält.

Was Terraform und Istio tatsächlich brachten

Terraform war nicht Ordnung um der Ordnung willen. Jede Infrastrukturänderung ging durch Review, war versioniert, ließ sich zurückrollen. Konfigurationsdrift, die vorher Tage Fehlersuche gekostet hätte, wurde ein Diff im Merge Request.

Istio lieferte mTLS zwischen Services, Traffic-Splitting für Canary-Deployments und Observability, ohne eine Zeile Application-Code zu ändern. Das ist der Punkt, an dem ein Service Mesh aufhört, Buzzword zu sein: wenn die Entwickler nichts davon merken und der Betrieb trotzdem messen kann, was läuft.

Der Cutover selbst

Der eigentliche Umzug war kein Schalter, sondern ein Parallelbetrieb über Wochen. WebLogic und die Quarkus-Version liefen gleichzeitig, der Traffic wanderte über Istio schrittweise von der alten auf die neue Seite. Erst ein kleiner Prozentsatz, dann mehr, mit Rollback-Option auf jeder Stufe.

Der unangenehme Teil war nicht die Anwendung, sondern der Zustand darum: Sessions, die auf dem Application-Server lagen, und ein Datenbankschema, das beide Versionen gleichzeitig bedienen musste, solange der Parallelbetrieb lief. Wir haben Sessions vor dem Umzug bewusst kurz gehalten und Schema-Änderungen so geschnitten, dass sie abwärtskompatibel blieben, bis die letzte WebLogic-Instanz abgeschaltet war. Ohne diese Regel hätte jeder Rollback eine Datenmigration in die falsche Richtung bedeutet, und genau das darf in einem Cutover nicht passieren.

Was Behörden anders macht

Sicherheitsfreigaben, Datenschutzprüfungen, Abnahmen. In einem Startup dauert das Tage. Hier waren es Wochen, teils Monate, und das lag nicht an schlechter Arbeit, sondern an der Zahl der Stellen, die zustimmen mussten. Wer das nicht einplant, verliert die Zeit trotzdem, nur ungeplant und an der falschen Stelle im Projektplan. Bei uns waren das grob 30% der Kalenderzeit, nicht der Aufwandsstunden.

Der zweite Punkt, der unterschätzt wird: der Wechsel von WebLogic auf Kubernetes ist für ein Team, das seit Jahren auf einem Application Server arbeitet, kein Tooling-Update. Es ist ein anderes mentales Modell für Deployment, Skalierung und Fehlerbehandlung. Workshops und Pairing-Sessions haben das aufgefangen. Ohne sie hätte die Übergabe am Ende länger gedauert als die Migration selbst.

Was am Ende stand

Deployment von einem Tag auf 20 Minuten. Zero Downtime beim Cutover. Release-Frequenz von quartalsweise auf wöchentlich. Verfügbarkeit über 99,9%, getragen von Health Checks und Rolling Updates statt von Handarbeit am Wochenende.

Die Zahlen sind kein Zufall aus guten Tools. Sie sind das Ergebnis davon, dass jede Phase abnehmbar war, dass Infrastruktur als Code lief und dass die Organisation die Zeit bekam, die sie brauchte.

Was ich heute anders angehen würde

Die Reihenfolge Containerisieren, dann Framework wechseln, dann Plattform würde ich wieder so wählen. Was ich früher einplanen würde: die Session- und Schema-Frage aus dem Cutover-Kapitel gehört an den Anfang der Zielarchitektur, nicht erst in die Umsetzung. Wer erst beim Parallelbetrieb merkt, dass zwei Versionen dasselbe Schema unterschiedlich lesen, verliert Wochen, die im Zeitplan nicht vorgesehen waren.

Der zweite Punkt: Das interne Team so früh wie möglich an die neue Pipeline setzen, nicht erst zur Übergabe. Wissen, das nur bei mir liegt, ist nach vier Jahren ein Risiko für den Kunden, nicht ein Vorteil für mich.

Was das für Ihre Migration heißt

Wer eine ähnliche Altlast betreibt, WebLogic, altes J2EE, ein Deployment-Prozess, der Stunden statt Minuten braucht, sollte nicht mit dem Werkzeug anfangen. Zuerst die Frage: was bleibt, was wandert, was stirbt. Dafür ist ein Architektur-Review der richtige erste Schritt, vor jedem Cutover-Plan.

Wenn intern niemand die Rolle für die Plattform-Migration hält, brauchen Sie jemanden auf Zeit, der Entscheidungen trifft und wieder abgibt: Interim CTO. Die Plattformarbeit selbst, Cluster, Pipelines, Mesh, sitzt unter Cloud- und Kubernetes-Plattformen.

Der schriftliche Einstieg vor der Entscheidung ist das Kubernetes-Migrations-Assessment. Fünf Tage, Zielarchitektur, Cutover-Strategie, Risiken. Keine Migration im Preis, nur die Vorlage, mit der Sie intern entscheiden können.

Die Behörde in diesem Fall hätte die Migration ohne diese Reihenfolge vermutlich trotzdem irgendwann geschafft. Nur später, teurer, und mit einem Team, das die Plattform am Ende nicht versteht, weil sie ihm übergestülpt wurde statt mit ihm gebaut.