blackboard - stock.adobe.com
Wie Sie die richtige Methode zur Cloud-Migration wählen
Das 7-R-Modell bietet Unternehmen eine strukturierte Orientierung für die Cloud-Migration und zeigt praxisnah auf, welche Strategien je nach Anwendung sinnvoll sind.
Obwohl die Public Cloud bereits seit vielen Jahren existiert, arbeiten Unternehmen immer noch daran, Anwendungen, die in ihren Rechenzentren ausgeführt werden, in die Public Cloud zu migrieren. In einigen Fällen möchten sie eine Anwendung verschieben, um die Vorteile einer verbrauchsabhängigen Preisgestaltung zu nutzen. In anderen Fällen erleichtert die Cloud die Skalierung oder Modernisierung der Anwendung. Oder sie möchten einfach nur die Kosten für neue Rechenzentrums-Hardware vermeiden.
Aber zwischen der Entscheidung für eine Migration in die Cloud und der tatsächlichen Umsetzung liegt ein großer Unterschied. Während einige Anwendungen relativ einfach verschoben werden können, sind andere bekanntermaßen schwierig. Darüber hinaus gibt es viele Arten von Cloud-Migrationen und Methoden.
Das 7-R-Modell ist eine hilfreiche Methode, um sich diese zu merken.
Warum 7 R?
Das R-Modell ist nicht neu, hat sich aber im Laufe der Jahre erheblich weiterentwickelt. Seine Entstehung wird in der Regel Gartner zugeschrieben, die bereits 2010 das 5-R-Modell entwickelt hat. Die ursprünglichen fünf R waren Rehost, Refactor, Revise, Rebuild und Replace.
Da sich die Cloud weiterentwickelte und immer vielfältigere Workloads in die Cloud migriert wurden, fügte AWS ein sechstes R hinzu – Retire (ausmustern) – und schließlich ein siebtes für Retain (beibehalten). Dieses siebte R ist im Grunde eine Anerkennung der Tatsache, dass nicht alle Workloads für die Bereitstellung in der Cloud geeignet sind.
Im Folgenden wird erläutert, was die sieben R in der Praxis bedeuten.
1. Rehost
Rehosting wird oft als Lift and Shift bezeichnet. Dabei wird eine Anwendung unverändert in die Cloud verschoben.
Rehosting kann auf verschiedene Weise erfolgen, bedeutet jedoch häufig, dass Cloud-basierte virtuelle Maschinen erstellt werden, die die Infrastruktur nachbilden, auf der eine Anwendung derzeit ausgeführt wird. Da die Cloud-Infrastruktur der lokalen Infrastruktur sehr ähnlich ist, ist die Verlagerung der Anwendung an einen neuen Standort in der Cloud relativ einfach. Einige Unternehmen rehosten beispielsweise eine Anwendung, indem sie ihre virtuelle Infrastruktur in der Cloud aufbauen und dann eine Sicherung auf der neuen, Cloud-basierten Infrastruktur wiederherstellen. In der Regel fallen nach der Migration einige kleinere Aufgaben an, beispielsweise die Aktualisierung der DNS-Einträge, damit die Anwendung an ihrem neuen Speicherort aufgerufen werden kann.
2. Relocate
Das zweite R, Relocate (Verlegen), ähnelt dem Rehosting. Bei beiden Methoden wird eine lokal ausgeführte Anwendung auf eine VM-Instanz in der Cloud verschoben, es gibt jedoch einen wesentlichen Unterschied. Beim Rehosting einer Anwendung müssen Sie eine Cloud-VM-Instanz erstellen und die Anwendung dann auf diese Instanz verschieben. Beim Relocating hingegen wird eine vorhandene VM aus einer lokalen Umgebung in die Cloud verschoben, ohne dass wesentliche Änderungen daran vorgenommen werden.
Angenommen, Ihr Unternehmen verwendet die Virtualisierungssoftware VMware und Sie müssen eine Ihrer virtuellen Maschinen in die Cloud migrieren. Anstatt einen mühsamen manuellen Migrationsprozess durchzuführen, könnten Sie einen Anbieter suchen, der VMware in der Cloud anbietet, und die VM in die Cloud des Anbieters migrieren.
Der größte Vorteil dieser Art der Migration ist ihre Einfachheit. Ein weiterer Vorteil besteht darin, dass Sie eine Cloud-Version der Virtualisierungsplattform verwenden, die Sie bereits On-Premises eingesetzt haben, sodass für Ihre IT-Mitarbeiter kaum Einarbeitungsaufwand entsteht.
3. Replatform
Während Rehosting manchmal auch als Lift and Shift bezeichnet wird, handelt es sich beim Replatforming eher um ein Lift and Reshape. Ursprünglich Revise im 5-R-Modell von Gartner, wird es manchmal auch als Lift, Tinker and Shift bezeichnet.
Die Idee hinter dem Replatforming ist, dass Cloud-Anbieter bei der Migration einer Legacy-Anwendung wahrscheinlich viele Funktionen und Fähigkeiten bieten, die zum Zeitpunkt der Erstellung der Anwendung noch nicht existierten. Es kann sinnvoll sein, die Anwendung im Rahmen des Migrationsprozesses zu verbessern, damit sie die Vorteile der Cloud, wie Skalierbarkeit und Flexibilität, voll ausschöpfen kann.
Das Replatforming einer Anwendung ist in der Regel kostspielig und zeitaufwändig, aber in manchen Fällen ist der Aufwand gerechtfertigt. Dies gilt insbesondere, wenn Sie eine zentrale Geschäftsanwendung so aktualisieren, dass Sie Ihren Umsatz steigern oder die Anwendung über Jahre hinweg weiter nutzen können.
Nicht jede Anwendung eignet sich für ein Replatforming. Replatforming ist in erster Linie eine Option für Open-Source-Anwendungen oder selbst entwickelte Anwendungen. Kommerzielle Softwareanbieter stellen ihren Quellcode in der Regel nicht zur Verfügung, was für ein Replatforming jedoch zwingend erforderlich ist.
4. Refactor
Das vierte R, Refactoring, ähnelt dem Replatforming, da auch hier eine Anwendung modifiziert wird, um alle Vorteile der Cloud zu nutzen. Es gibt jedoch wichtige Unterschiede. Vor allem bleibt beim Replatforming die Architektur einer Anwendung erhalten, sodass sie weitgehend unverändert weiter funktioniert. Im Vergleich dazu bedeutet Refactoring, dass grundlegende architektonische Änderungen an der Anwendung vorgenommen werden. Beispielsweise können Sie eine Anwendung in eine Sammlung von Microservices aufteilen.
Refactoring ist wohl die schwierigste der Migrationsarten, aber manchmal lohnt es sich, um eine Anwendung zukunftssicher zu machen. Wie beim Replatforming benötigen Sie auch beim Refactoring Zugriff auf den Quellcode der Anwendung.
5. Repurchase
Das fünfte R, Repurchase (Wiederkauf), hat mehrere Bedeutungen. Zum einen kann es den Ersatz einer lokalen Anwendung durch eine konkurrierende, Cloud-native Anwendung mit denselben Funktionen bedeuten. Es kann auch den Ersatz einer lokalen Anwendung durch eine SaaS-Version der Anwendung bedeuten.
Schließlich kann Repurchase auch die schrittweise Abschaffung von Legacy-Architekturkomponenten zugunsten von serverlosen verwalteten Systemen bedeuten. Beispielsweise könnte ein Unternehmen seine SQL-Server-Datenbank durch einen Managed Service ersetzen, bei dem der Cloud-Anbieter SQL-Server in der Cloud ausführt. Der Vorteil dieses Ansatzes gegenüber der einfachen Ausführung von SQL-Server auf einer Cloud-basierten VM besteht darin, dass der Cloud-Anbieter die gesamte Wartung übernimmt, wenn eine Datenbank als Managed Service angeboten wird. Der Anbieter sorgt für den laufenden Betrieb des Dienstes, stellt die erforderliche Redundanz bereit und übernimmt das erforderliche Patch-Management.
6. Retire
Es ist nicht immer sinnvoll, alle Workloads in die Cloud zu verlagern. In manchen Fällen ist es besser, einige Legacy-Anwendungen aus dem Verkehr zu ziehen.
Ein Workload kann für die Ausmusterung in Frage kommen, wenn er vom Anbieter nicht mehr aktiv unterstützt wird. In solchen Fällen ist es wichtig, dass Sie eine Alternative bereitstellen, bevor Sie eine Anwendung ausmustern, die noch im Unternehmen verwendet wird. Dies kann die Einführung einer konkurrierenden Anwendung mit ähnlichen Funktionen oder die Entwicklung einer eigenen Lösung bedeuten.
Gelegentlich müssen Sie möglicherweise erhebliche Änderungen an den Geschäftsprozessen des Unternehmens vornehmen, bevor Sie eine veraltete Anwendung ausmustern können. Wenn beispielsweise eine Anwendung nicht mehr unterstützt wird und geeignete Ersatzprodukte zu teuer sind, ist es möglicherweise besser, stattdessen die Geschäftsprozesse zu ändern.
7. Retain
Das siebte R, Retain (Beibehalten), bedeutet im Wesentlichen, eine Anwendung vorerst unverändert zu lassen.
Angenommen, Ihr Unternehmen ist auf eine bestimmte Anwendung angewiesen, die derzeit vor Ort ausgeführt wird. Es besteht zwar Druck, diese in die Cloud zu migrieren, aber der Anbieter hat für später im Jahr eine SaaS-Version angekündigt. Es ist wahrscheinlich nicht sinnvoll, die Kosten und den Aufwand einer Cloud-Migration auf sich zu nehmen, wenn Sie auf die Cloud-Version warten können.
Die Beibehaltungsstrategie kann auch zum Tragen kommen, wenn Anwendungsabhängigkeiten berücksichtigt werden müssen. Beispielsweise verfügt Ihr Unternehmen über eine bestimmte Anwendung, die Sie in die Cloud verlagern möchten. Während der Planungsphase stellen Sie fest, dass eine andere lokal ausgeführte Anwendung von der Anwendung abhängt, die das Unternehmen migrieren möchte, und möglicherweise nicht mehr funktioniert. In dieser Situation muss die Anwendung in ihrem aktuellen Zustand beibehalten werden, bis die abhängigen Anwendungen migriert oder außer Betrieb genommen wurden.
