Was ist Cloud-Migration?

Was ist Cloud-Migration?

Cloud-Migration ist das Verschieben von Anwendungen, Daten und Workloads von einer Umgebung in eine andere, meist von eigenen Servern in eine Public Cloud wie AWS, Azure oder Google Cloud. Dazu zählen auch Umzüge zwischen Clouds und zurück ins eigene Rechenzentrum (Repatriierung). Eine Migration kann der schlichte Umzug eines Servers sein oder ein Umbau der Anwendung auf verwaltete Cloud-Dienste.

Die 7 Rs der Cloud-Migration

AWS beschreibt sieben Migrationsstrategien, meist die 7 Rs genannt. Du wählst eine Strategie je Anwendung, nicht eine für die gesamte Landschaft.

• Rehost (Lift and Shift). Die Anwendung unverändert verschieben.
• Replatform (Lift, Tinker and Shift). Verschieben und einige Optimierungen vornehmen, etwa eine selbst betriebene Datenbank durch eine verwaltete ersetzen.
• Refactor bzw. Re-Architect. Die Anwendung für Cloud-native Funktionen neu entwerfen. Die aufwendigste und teuerste der sieben Strategien.
• Relocate. Server oder Instanzen auf die Cloud-Variante derselben Plattform oder in ein anderes Konto, VPC oder eine andere Region verschieben, ohne die Architektur zu ändern.
• Repurchase (Drop and Shop). Die Anwendung durch ein SaaS- oder neueres Produkt ersetzen.
• Retire. Anwendungen abschalten, die niemand braucht. AWS nennt als Kandidaten etwa Apps ohne eingehende Verbindung in 90 Tagen.
• Retain. Alles so lassen, etwa wegen Datenresidenz, Spezialhardware, Mainframe oder kürzlich gekaufter Hardware.

Für große Migrationen empfiehlt AWS, zuerst zu rehosten, zu relocaten oder zu replatformen und erst danach zu modernisieren, weil ein Refactoring während des Umzugs am schwersten zu steuern ist.

Phasen einer Migration

1. Bewerten und planen

Anwendungen, Abhängigkeiten, Datenflüsse, Netzwerkbedarf und Lizenzen erfassen. Anwendungen in Wellen gruppieren und je eine Strategie wählen. Die heutige Performance festhalten, denn sie ist später deine Vergleichsbasis.

2. Landing Zone aufbauen

Konten, Netzwerk, Identität, Logging und Kostenkontrolle einrichten, bevor etwas umzieht. Als Code definiert mit Infrastructure as Code bleibt das wiederholbar. Welche Regeln früh gelten sollten, steht unter Cloud Governance.

3. Pilotwelle

Zuerst einige risikoarme Anwendungen verschieben, um Landing Zone, Cutover-Schritte und Rollback-Plan zu erproben.

4. Migrationswellen

Jede Welle hat eine Datensynchronisation, einen DNS-Cutover-Plan, einen Rollback-Plan und Monitoring. Teste vor dem Cutover, nicht danach.

5. Optimieren und betreiben

Instanzen richtig dimensionieren, ungenutzte Ressourcen entfernen, Datentransferkosten prüfen und das Gerehostete modernisieren. Das Ergebnis verfolgst du mit Cloud-Monitoring.

Beispiel

Ein Unternehmen betreibt einen Webshop auf zwei eigenen Servern mit einer selbst betriebenen MySQL-Datenbank. Es entscheidet sich für Replatform: Die App zieht auf virtuelle Maschinen in der Cloud, die Datenbank auf einen verwalteten MySQL-Dienst. Vor dem Cutover läuft ein Lasttest mit der erwarteten Spitzenlast gegen den neuen Stack, und Antwortzeiten sowie Fehlerrate werden mit den Werten der alten Server verglichen. DNS wird erst umgestellt, wenn die neue Umgebung die Werte erreicht oder übertrifft, und die alten Server bleiben für einen festgelegten Zeitraum als Rückweg bestehen.

Häufige Fehler bei der Cloud-Migration

• Alles rehosten und aufhören. Der Umzug ist schnell, aber ohne Right-Sizing und Aufräumen zahlst du für überdimensionierte Maschinen.
• Die Vergleichsbasis auslassen. Ohne Messwerte vom alten System weißt du nicht, ob die Cloud-Version langsamer ist.
• Nicht unter Last testen. Netzwerkpfade, Storage-Durchsatz, Limits verwalteter Dienste und Identitätsaufrufe verhalten sich anders als im alten Rechenzentrum.
• Datentransferkosten ignorieren. Verkehr zwischen Zonen, Regionen und ins Internet wird berechnet, deshalb zählt die Datenplatzierung.
• Identität zuletzt behandeln. Verzeichnis- und Single-Sign-on-Abhängigkeiten blockieren oft den Cutover.
• Keine Kostenleitplanken. Budgets, Tags und Alarme sollten stehen, bevor die erste Last landet.
• Die alte Umgebung zu früh abschalten. Behalte sie, bis der Rollback über einen vereinbarten Zeitraum nicht gebraucht wurde.
• Ein Refactoring in den Umzug zwängen. Einen Monolithen während der Migration in Microservices zu zerlegen erhöht das Risiko. Erst migrieren, dann modernisieren.

Migration mit Tests und Monitoring absichern

Der am häufigsten übersprungene Schritt ist der Nachweis, dass die migrierte Anwendung performt. Führe einen Lasttest gegen die neue Umgebung mit der erwarteten Spitzenlast aus und vergleiche ihn mit deiner Vergleichsbasis. Die LoadFocus-Load-Testing-Plattform führt JMeter- und k6-Tests aus 25 Cloud-Regionen aus, sodass du Traffic von dort erzeugen kannst, wo deine Nutzer sind. Nach dem Cutover prüft API-Monitoring zeitgesteuert Statuscodes, Response-Bodys und Antwortzeit und alarmiert bei Fehlern. Zur Testseite der Entscheidung siehe Cloud vs. On-Premise Load Testing (englisch).

Häufige Fragen: Cloud-Migration

Wie lange dauert eine Cloud-Migration?

Das hängt von der Zahl der Anwendungen, ihren Abhängigkeiten und der gewählten Strategie ab. Ein Rehost weniger einfacher Server kann Wochen dauern, ein großes Portfolio wird in Wellen über Monate oder Jahre geplant. Betrachte jede einzelne Zahl als Schätzung, bis die Bewertung abgeschlossen ist.

Was ist der Unterschied zwischen Rehost und Replatform?

Rehost verschiebt die Anwendung unverändert. Replatform verschiebt sie und nimmt einige Optimierungen vor, etwa den Wechsel auf eine verwaltete Datenbank, ohne die Anwendung neu zu entwerfen.

Sollte jede Anwendung in die Cloud?

Nein. Manche Anwendungen werden abgeschaltet, andere bleiben wegen Compliance, Spezialhardware oder einer jüngeren Investition, wo sie sind. Die 7 Rs enthalten beide Optionen aus diesem Grund.

Was ist Cloud-Repatriierung?

Der Umzug von Workloads aus der Cloud zurück ins eigene Rechenzentrum oder in eine Colocation. Teams tun das aus Kostengründen, wegen Compliance oder bei planbaren Workloads, die von elastischer Kapazität nicht profitieren.

Wie teste ich eine Migration vor dem Cutover?

Antwortzeiten und Fehlerraten der alten Umgebung als Basis festhalten, einen Lasttest mit der erwarteten Spitzenlast gegen die neue fahren, die Ergebnisse vergleichen und den Rollback üben. Den Traffic erst umschalten, wenn die Werte passen.