Case: VM → Kubernetes Migration

Lernziele

Nach dieser Lektion kannst du den Migrations-Case „200 VM-Anwendungen nach Kubernetes in 18 Monaten” strukturiert beantworten: Du klärst zuerst Portfolio und Constraints, baust deine Antwort um ein Assessment mit Tiering auf statt um Tools, kannst Lift-and-Shift gegen Containerisierung gegen Stilllegung abwägen und rechnest dem Interviewer vor, warum 200 Apps mit 12 Engineers nur mit einer Self-Service-Plattform funktionieren — nicht mit 200 Einzelprojekten.

Das Szenario: 200 Apps, 18 Monate, 12 Engineers

Die Aufgabe: „Ein Konzern will 200 VM-basierte Anwendungen innerhalb von 18 Monaten auf Kubernetes migrieren. Das Plattform-Team hat 12 Engineers. Designe die Plattform und die Migrationsstrategie.”

Die erste Erkenntnis, die du im Interview aussprechen solltest: Das ist kein Architekturproblem, sondern ein Durchsatzproblem. 200 Apps in 18 Monaten sind im Schnitt 11 Apps pro Monat, jeden Monat, ohne Pause. Wenn jede Migration ein handgeführtes Projekt des Plattform-Teams ist, sind 12 Engineers hoffnungslos unterbesetzt. Die einzige Antwort, die rechnerisch aufgeht: Das Plattform-Team baut eine Migrationsfabrik — Assessment-Prozess, Golden Path, Self-Service-Tooling — und die Anwendungsteams migrieren selbst.

Anforderungen klären: das Portfolio verstehen

Bevor du irgendetwas designst, brauchst du ein Bild vom Bestand:

1. Was läuft da eigentlich? Im Szenario: gemischte Stacks — Java-Monolithen, PHP, .NET. Die Folgefrage: Wie viele davon sind .NET Framework (nur Windows, also Windows-Container oder Rewrite) versus .NET Core/moderne Versionen (Linux-fähig)? Das verändert den Aufwand pro App massiv.
2. Wie viele Apps haben State? Datenbanken, lokale Dateisysteme, In-Memory-Sessions. Stateless-Apps sind Wochenaufgaben, Stateful-Apps Monatsprojekte.
3. Muss wirklich alles migriert werden? Erfahrungsgemäß ist ein Teil eines 200-App-Portfolios Kandidat für Stilllegung oder Ersatz durch SaaS. Jede stillgelegte App ist die billigste Migration.
4. Welche Constraints gelten? Hier vorgegeben: maximal 4 Stunden Downtime pro App. Das erlaubt Cutover-Fenster — du brauchst also keine Zero-Downtime-Strategie für alles, was die Sache deutlich vereinfacht. Sprich das explizit aus.
5. Was ist der Treiber der Migration? Kostendruck, Rechenzentrums-Exit mit Deadline, Modernisierung? Bei einem harten DC-Exit gewinnt Lift-and-Shift; bei Modernisierung als Ziel darf mehr refactored werden.

Strategie: Tiering statt Einheitsplan

Assessment zuerst. Die ersten vier bis sechs Wochen gehören einer Portfolio-Analyse, die jede App in ein Tier einsortiert — angelehnt an die bekannten Migrationskategorien (Rehost, Replatform, Refactor, Retire, Retain):

• Tier 1 — Containerisieren (Replatform): Stateless oder fast stateless, aktiv weiterentwickelt, Team vorhanden. Diese Apps gehen über den Golden Path: Dockerfile-Vorlagen pro Stack, Standard-Helm-Chart der Plattform, CI/CD-Template, GitOps-Onboarding. Ziel: Die Mehrheit des Portfolios.
• Tier 2 — Lift-and-Shift: Läuft, wird kaum angefasst, niemand kennt die Interna mehr. Optionen: als VM weiterbetreiben auf einem separaten, schrumpfenden VM-Pool — oder per KubeVirt als virtuelle Maschine im Kubernetes-Cluster, wenn einheitliches Management das Ziel ist. Ehrlich bleiben: KubeVirt vereinheitlicht die Plattform, macht aber aus einer Legacy-VM keine cloud-native App.
• Tier 3 — Stilllegen oder ersetzen (Retire): Geringe Nutzung, redundante Funktion, SaaS-Alternative vorhanden. Diese Kategorie aktiv zu suchen ist ein Reife-Signal im Interview.
• Refactor (echter Umbau zu Microservices) bleibt die Ausnahme für wenige strategische Systeme — nie der Default, dafür reicht weder Zeit noch Kapazität.

Reihenfolge: Quick Wins zuerst. Starte mit 5–10 stateless Tier-1-Apps freiwilliger, motivierter Teams. Das validiert den Golden Path, produziert interne Referenzen und liefert Migrationsmetriken für die Hochrechnung. Danach Wellen von 10–15 Apps pro Monat.

Stateful-Sonderfall: Datenbanken wandern in der ersten Welle nicht in den Cluster. Eine Java-App lässt sich containerisieren, während ihre Oracle- oder PostgreSQL-Datenbank auf der VM oder einem Managed Service (z. B. RDS) bleibt — die App bekommt nur einen neuen Connection String. Das entkoppelt das App-Risiko vom Daten-Risiko. Für schrittweise Traffic-Umstellung einzelner Funktionen aus Monolithen heraus ist das Strangler-Fig-Muster der richtige Begriff: ein Proxy/Router davor, neue Pfade zeigen auf den Container, alte auf die VM, bis die VM leer ist.

Plattform-Seite: Jede migrierte App bekommt automatisch Namespace, Quota, NetworkPolicy, GitOps-Anbindung und Monitoring-Dashboards — idealerweise über ein Portal-Template („Migrate Existing App” in Backstage), das den Prozess auf Formular-Niveau bringt. Genau hier zahlt sich die Fabrik-Denkweise aus.

Einwände des Interviewers

„18 Monate sind unrealistisch — was tust du?” — Zustimmen und priorisieren: Tier-3-Apps stilllegen, Tier-2 per Lift-and-Shift entschärfen, und mit dem Sponsor klären, ob die Deadline für alle Apps gilt oder für den DC-Exit (VM-Pool woanders weiterbetreiben kann legitim sein). Eine ehrliche Hochrechnung nach Welle 1 schlägt jeden optimistischen Plan.

„Was machst du mit der App, deren Team es nicht mehr gibt?” — Tier 2, nicht Tier 1. Niemand kann sie sicher umbauen; Lift-and-Shift plus gutes Monitoring ist risikoärmer als blindes Containerisieren.

„Wie verhinderst du, dass das Plattform-Team zum Flaschenhals wird?” — Self-Service-Migrationspfad, Dokumentation, Office Hours und Pairing in Welle 1 statt Durchführung durch das Plattform-Team. Die Metrik dafür: Anteil der Migrationen ohne Plattform-Team-Beteiligung sollte über die Wellen steigen.

„Rollback-Plan?” — Pro App: Cutover im Downtime-Fenster, VM bleibt zwei bis vier Wochen eingefroren als Fallback, DNS/Load-Balancer-Umschaltung ist in beide Richtungen dokumentiert und geprobt.

Praxis

45 Minuten, Whiteboard. Spiele den Case komplett durch. Diese fünf Punkte müssen vorkommen:

1. Durchsatzrechnung (200 Apps / 18 Monate ≈ 11 pro Monat) als Begründung für Self-Service
2. Assessment-Phase mit Tiering und explizitem Retire-Tier
3. Stateful-Strategie: Datenbanken zunächst draußen lassen
4. Welle 1 mit Freiwilligen als Validierung, dann Hochrechnung
5. Rollback-Mechanik pro App innerhalb des 4-Stunden-Fensters

Zusatzübung: Erstelle in 10 Minuten eine Tabelle mit drei fiktiven Apps (Java-Monolith mit Oracle, PHP-Shop stateless, .NET-Framework-Tool ohne Team) und ordne jede begründet einem Tier zu.

Typische Stolperfallen

Alles containerisieren wollen. Wer für jede der 200 Apps den vollen Cloud-native-Umbau plant, fällt bei der Durchsatzrechnung durch. Die starke Antwort enthält Lift-and-Shift und Stilllegung ohne Verlegenheit.

Das Assessment überspringen. Ohne Portfolio-Analyse ist jede Zeitplanung geraten. Vier bis sechs Wochen Assessment sind keine verlorene Zeit, sondern die Grundlage jeder belastbaren Aussage.

Datenbank-Migration mit App-Migration verheiraten. Beides gleichzeitig verdoppelt das Risiko pro Cutover. Erst die App, die Daten später — oder nie (Managed Service).

Den Faktor Mensch ignorieren. 200 Apps heißt Dutzende Teams mit eigener Roadmap. Ohne Management-Rückendeckung, Anreize und sichtbare Erfolge aus Welle 1 migriert niemand freiwillig.

Interview-Vorbereitung

Kernbotschaft: „Bei 200 Apps und 12 Engineers baue ich keine Migration, sondern eine Migrationsfabrik: Assessment und Tiering zuerst, Golden Path für die Masse, Lift-and-Shift für Legacy, Stilllegung wo möglich — und die Teams migrieren self-service.”

Rechne mit diesen Follow-ups:

• „Welche Metriken trackst du?” — Migrierte Apps pro Monat gegen Plan, Migrationsdauer pro Tier, Anteil Self-Service-Migrationen, Incidents in den ersten 30 Tagen nach Cutover.
• „KubeVirt oder separater VM-Pool?” — KubeVirt bei strategischem Ziel „eine Plattform, ein Betriebsmodell”; separater Pool, wenn das Plattform-Team noch keine KubeVirt-Erfahrung hat und der Pool ohnehin schrumpft.
• „Wann brichst du eine Migration ab?” — Wenn das Downtime-Fenster reißt oder Smoke-Tests nach Cutover fehlschlagen: zurück auf die eingefrorene VM, Ursachenanalyse, neuer Termin. Abbruchkriterien gehören vor dem Cutover ins Runbook.
• „Was ist der häufigste technische Blocker?” — Implizite Abhängigkeiten: hartkodierte IPs, lokale Dateipfade, Latenzannahmen zwischen App und DB. Deshalb gehört Dependency-Mapping ins Assessment.

Zusammenfassung

Der Migrations-Case wird mit einer Rechnung eröffnet und mit einem Prozess gewonnen: 11 Apps pro Monat erzwingen Self-Service; Assessment und Tiering (Containerisieren, Lift-and-Shift, Stilllegen) verteilen den Aufwand realistisch; Datenbanken bleiben zunächst außen vor; Welle 1 mit Freiwilligen liefert die Hochrechnung, die deinen Plan glaubwürdig macht. In der nächsten Lektion geht es um das Worst-Case-Szenario für jede Plattform: Disaster Recovery mit hartem RTO und RPO über zwei Regionen.