Im Migrations-Deck stand „20.000 Microservices nach Kubernetes“. Niemand betreibt 20.000 Microservices — nur eine Handvoll Unternehmen weltweit betreibt auch nur einen Bruchteil davon. Das echte Inventar waren rund 900 verschiedene Services, die als etwa 20.000 VM-Instanzen liefen. Die aufgeblähte Zahl fiel ins Gewicht, denn ein darauf gebauter Plan behandelte jede Instanz als identisch, containerisierungsbereit und gefahrlos per Autopilot verschiebbar.

Der Plan

  • „Einfach containerisieren und deployen“
  • Automatisiertes Konvertierungs-Tooling, minimale Prüfung pro Service
  • Aggressive Cutover-Wellen, bemessen in Wochen

Was schiefging

In der ersten großen Welle fielen rund zwei Drittel der migrierten Services bei Readiness- oder Health-Checks durch. Die Ursachen waren selten exotisch:

  • Hartkodierte IP-Adressen in Konfigurationsdateien, die seit Jahren niemand geöffnet hatte
  • Services, die temporäre Dateien nach /opt/app/tmp schrieben — in den neuen Images read-only
  • Ein Service parste seinen eigenen Hostnamen, um zu entscheiden, in welcher Umgebung er lief; er erwartete, auf einer Maschine namens „prod-db-01“ zu leben
  • Hunderte hartkodierte localhost-Verweise auf Daemons, die nicht mehr neben der App liefen
  • Zeitzonen-Annahmen, die Batch-Jobs in dem Moment brachen, in dem Container standardmäßig auf UTC liefen

Nichts davon taucht in einem automatisierten Scan des Deployment-Artefakts auf. Es ist Infrastruktur-Archäologie, und sie kostet echte Zeit pro Service.

Was stattdessen funktioniert

  • Inventar zuerst. Instanzen zu tatsächlichen Services deduplizieren und jeden einzelnen klassifizieren — das ist der Assessment-Schritt jeder vernünftigen Cloud-Migrations-Roadmap, und in 6R/7R-Begriffen entscheidet er, welche Workloads replatformt, welche unverändert rehostet und welche stillgelegt werden.
  • Eine Container-Readiness-Checkliste pro Service: Dateisystem-Schreibzugriffe, Netzwerk- und Hostname-Annahmen, Konfigurationsquellen, Uhr und Locale.
  • Kleine Wellen, Stateless zuerst, mit stufenweiser Traffic-Verlagerung und sofortigem Rollback. Canary Releases gehören auf die Traffic-Ebene; Datenmigrationen — wo Muster wie Dual-Write greifen — sind ein eigener Workstream, kein Containerisierungs-Fix.
  • Ein Zeitplan in Monaten pro Tranche, kein Cutover-Wochenende.

Landschaften wie diese sind genau der Grund, warum wir Cloud-Migrations-Engagements um Discovery herum zuschneiden, bevor irgendjemand ein Dockerfile schreibt.

Lektion: Containerisierung ist nicht „docker build“. Undokumentierte Abhängigkeiten — nicht Kubernetes — sind es, die Replatforming-Projekte killen, und der einzige Weg, sie zu finden, ist, sich einen Service nach dem anderen anzusehen.

← Zurück zu Lessons Learned

Incidents wie dieser sind vermeidbar. Unser AWS Managed Services-Team überwacht Kundenumgebungen 24/7 mit KI-gestütztem Monitoring und Senior Engineers am Pager — damit Geschichten wie diese im Archiv bleiben.

Tags: #Kubernetes #Migration #Container #Architektur