Cloud Migration to Kubernetes: Lessons Learned from Government

Ausgangslage: Legacy J2EE auf Oracle WebLogic

Die Ausgangssituation ist vielen IT-Verantwortlichen in Behörden und Unternehmen vertraut: Eine geschäftskritische Anwendung läuft seit Jahren stabil auf einem Application Server (in diesem Fall Oracle WebLogic). Deployments dauern Stunden, Releases sind selten und riskant, und die Infrastruktur ist schwer zu skalieren.

Das Ziel: Migration auf eine moderne Container-Plattform mit Kubernetes, ohne den laufenden Betrieb zu gefährden.

Die Migrationsstrategie

Statt einer riskanten Big-Bang-Migration haben wir einen schrittweisen Ansatz gewählt:

Phase 1: Containerisierung

Der erste Schritt war die Containerisierung der bestehenden Anwendung – noch ohne Kubernetes. Ziel: Die gleiche Anwendung läuft im Docker-Container, verhält sich aber identisch zum WebLogic-Deployment.

Phase 2: Framework-Migration (J2EE → Quarkus)

Parallel zur Containerisierung haben wir die J2EE-spezifischen APIs schrittweise durch Quarkus-Äquivalente ersetzt. Quarkus bietet native Container-Unterstützung und deutlich schnellere Startzeiten.

Phase 3: Kubernetes-Deployment

Mit der containerisierten Anwendung ging es auf die Kubernetes-Plattform (Rancher):

Terraform für die Cluster-Provisionierung

HELM Charts für das Application Deployment

Istio als Service Mesh für Traffic Management und mTLS

GitLab CI/CD für automatisierte Build- und Deploy-Pipelines

Phase 4: Monitoring und Absicherung

Prometheus + Grafana für Metriken und Dashboards

SonarQube für kontinuierliche Code-Qualität

NexusIQ für Security-Scans der Dependencies

Ergebnis

Deployment-Zeit: Von Stunden auf Minuten reduziert

Release-Frequenz: Von quartalsweise auf wöchentlich

Verfügbarkeit: 99.9% dank automatischer Health Checks und Rolling Updates

Sicherheit: Automatisierte Security-Scans in der CI/CD-Pipeline

Die 5 wichtigsten Lessons Learned

1. Strangler Fig Pattern funktioniert

Die schrittweise Migration nach dem Strangler Fig Pattern war der richtige Ansatz. Jede Phase lieferte eigenständigen Mehrwert und war separat abnehmbar.

2. Infrastruktur als Code von Tag 1

Terraform war nicht verhandelbar. Jede Infrastruktur-Änderung ging durch Code Review und wurde versioniert. Das hat uns mehrfach vor Konfigurationsdrift bewahrt.

3. Service Mesh ist kein Luxus

Istio hat sich als unverzichtbar erwiesen: mTLS zwischen Services, Traffic Splitting für Canary Deployments und detaillierte Observability – alles ohne Änderungen am Application Code.

4. Behörden-Compliance braucht Zeit

Sicherheitsfreigaben, Datenschutz-Prüfungen und Abnahmen dauern in Behörden länger als in Startups. Diesen Overhead muss man einplanen – er kann leicht 30% der Projektzeit ausmachen.

5. Entwickler-Onboarding nicht unterschätzen

Der Wechsel von WebLogic auf Kubernetes ist für Entwickler ein Paradigmenwechsel. Wir haben interne Workshops und Pair-Programming-Sessions eingeplant.

Fazit

Cloud-Migrationen in regulierten Umgebungen sind machbar – wenn man schrittweise vorgeht, die richtigen Tools einsetzt und den organisatorischen Overhead einplant. Kubernetes mit Terraform, HELM und einem Service Mesh bilden die technische Basis, aber der Erfolg hängt genauso an Change Management und Stakeholder-Kommunikation.

Sie planen eine Cloud-Migration? Ich bringe Erfahrung aus regulierten Branchen mit und begleite Sie vom Assessment bis zum produktiven Betrieb.