Cloud-Migration
Strategisch sinnvoll in die Cloud
Oft wird der erste Schritt in die Cloud über die Verlagerung von virtuellen Maschinen in die Cloud getätigt. Dies wird als „Lift and Shift“ bezeichnet. Und genau damit fängt es an, interessant zu werden: Bleibt die Organisation in dieser Phase stecken, ist der Spaß an der Cloud nur mäßig groß.
Die Motivation von IT-Verantwortlichen, Workloads in der Cloud zu betreiben, wird immer wieder heiß diskutiert. Auf der Haben-Seite gibt es oft Aspekte wie den Wegfall der Verwaltung von Infrastrukturkomponenten, Möglichkeiten der Skalierung bei Last oder die Reduktion der Betriebskosten. Mittlerweile hat sich allerdings gezeigt, dass diese Argumente nicht pauschal haltbar sind und dass das Rechenzentrum in den Wolken professionell ausgestattet werden muss, um die gewünschten Vorteile zu erbringen. Unstrittig ist, dass Cloud-Technologien für die meisten Unternehmen in die Digitalisierungsstrategie gehören, da die Anforderungen an die IT an vielen Stellen flexibler und leistungsfähiger aus der Cloud als aus dem eigenen Rechenzentrum umgesetzt werden können.
Lift and Shift, auch als Rehosting bekannt, ist der Prozess der Migration der Kopie einer Anwendung samt ihres Datenspeichers und Betriebssystems von einer lokalen IT-Umgebung in die Cloud. Die Vorteile liegen dabei in der schnellen und kostengünstigen Durchführung der Migration. Bei einem Lift-and-Shift-Verfahren lassen sich On-Premises-Applikationen ohne Designänderung in die Cloud verschieben. In heutigen Rechenzentren laufen die Applikationen nahezu vollständig in virtuellen Maschinen. Durch entsprechende Konfiguration der Cloud-Infrastruktur besteht eine Migration daher im Allgemeinen aus dem Kopieren der virtuellen Maschinen in die Cloud. Sind dabei die Anwendungen neben dem Betriebssystem auch von der Systemumgebung wie Windows-Domäne, IP-Adressen oder Ähnlichem abhängig, steigt die Komplexität der Migration. Der Nachteil dieses Migrationsansatzes: Zwar wurde das Rechenzentrum ausgetauscht, aber die Pflege der Applikationen und des darunterliegenden Betriebssystems liegt immer noch beim Betreiber der Anwendung und nicht beim Cloud Provider. Das ist etwas ungünstig, da ein wichtiges Ziel der Einführung von Cloud die Ablösung des Musters „dedizierte Hardware für dedizierte Software“ sein soll. Dieses Muster beschreibt das typische Dilemma von Betriebsmodellen. Entweder die Hardware ist unter- oder überdimensioniert – in beiden Fällen entstehen wirtschaftliche Nachteile.
Um die Vorteile der Cloud voll ausnutzen zu können, empfiehlt es sich, in Richtung „Cloud Native“ zu gehen. Je nach Szenario stehen verschiedene Strategien bereit, um eine Anwendung über Zwischenschritte in eine Cloud-Native-Anwendung zu überführen.
Cloud Native – fix aufgefrischt
Eine Anwendung gilt als „nativ“, wenn sie die Mechanismen zu Abstraktion von Betriebssystem, Laufzeit oder Persistenz nutzt. Dazu zählen auch Container, aber keine virtuellen Maschinen. Es gilt: Je nativer eine Anwendung in die Cloud-Umgebung eingebracht wird, desto größer ist der Zugriff dieser Anwendung auf die elastischen Aspekte der Umgebung.
Ein Beispiel soll dies verdeutlichen: Kann eine Anwendung Konzepte wie „Serverless Computing“ nutzen, werden Aspekte wie Kapazitätsplanung, Konfiguration und Wartung vom Cloud Provider übernommen und stehen somit theoretisch unendlich elastisch zur Verfügung. Kann die Anwendung diese Konzepte nicht nutzen, müssen die Themen vom Betreiber übernommen werden und es entsteht der genannte Nachteil von dedizierter Hardware für dedizierte Software.
Herausforderungen von Cloud Native
Spezialisierung hat Grenzen, was auch für Software und Betriebsmodelle gilt. Je stärker eine Anwendung für die darunterliegende Infrastruktur optimiert ist, desto effektiver ist der Ressourcenzugriff. Allerdings steigt damit auch die Abhängigkeit von genau dieser Infrastruktur in gleichem Maße. Die Migration einer für Microsoft Azure entwickelten, nativen Lösung zu Googles GCP beziehungsweise AWS bedeutet praktisch jeweils eine Neuentwicklung weiter Teile dieses Systems. Wurde die Applikation mit einer Container-Lösung in die Cloud gebracht, die auf all diesen Hyperscalern verfügbar ist, fällt die Migration sehr viel leichter. Allerdings abstrahieren Container die Infrastruktur und sind daher eher als „native light“ zu betrachten. Wird jedoch die Unabhängigkeit vom Cloud Provider größer als „Performance“ bewertet, sind Container eine gute Wahl.
Handelt es sich bei der Lösung um eine gekaufte Software, ist die Neuentwicklung vom Tisch und Container sind fast das „nativste“, was hier möglich ist. Durch geschickte Konfiguration könnten gegebenenfalls von der Anwendung genutzte Systeme wie zum Beispiel eine Datenbank als nativer Dienst eingebunden werden. Um die Container-Bereitstellung vollständig zu nutzen, muss die vorhandene Anwendung in mehrere Container aufgeteilt werden. Idealerweise sollte ein einzelner Prozess einem einzelnen Container zugeordnet werden. Bei Kaufsoftware ist das nur eingeschränkt möglich, da kein Zugriff auf den Quellcode besteht.
- Strategisch sinnvoll in die Cloud
- Der richtige Weg? Teile und herrsche!
Lesen Sie mehr zum Thema
