Der Materna Blog – wissen was los ist

©SFIO CRACHO - stock.adobe.com

Wege in die Cloud: Die 6 R’s der Cloud-Migration

Strategien und Vorgehensweise für eine erfolgreiche Cloud-Migration

Grundsätzlich gibt es viele Beweggründe, warum ein Unternehmen in die Cloud wechseln möchte. Neben Kostenersparnis im Total Cost of Ownership (TCO) spielen Aspekte wie Elastizität und Flexibilität, aber auch Innovationsdruck oder Sicherheitsaspekte eine entscheidende Rolle. In diesem Artikel werden die unterschiedlichen Migrationswege in die Cloud skizziert und voneinander abgegrenzt.

Viele Wege führen in die Cloud

Wir von Materna versuchen unsere Kunden ganz im Zuge unseres Claims „Stressfrei in die Cloud“ sehr früh bei ihrer Cloud Journey abzuholen und stehen ihnen von Anfang an beratend zur Seite. Klassischerweise bietet die Materna GmbH zunächst einen Cloud Readiness Check an, der dem Kunden, aber auch uns, das Cloud-Potential in dem betreffenden Unternehmen offenbart. Unsere Experten für Softwareentwicklung und Operations prüfen gemeinsam beim Kunden die vorhandene Infrastruktur und analysieren die bestehende Softwarelandschaft, um dann gemeinsam gezielt erste Projekte zur Migration oder Neuentwicklung zu definieren und umzusetzen. Die Vorgehensweise des Cloud Readiness Checks orientiert sich an dem AWS Cloud Adoption Framework.

In Abbildung 1 werden die möglichen Pfade in die Cloud dargestellt und im Folgenden kurz erläutert.

Wege in die Cloud
Wege in die Cloud (Quelle https://aws.amazon.com/de/cloud-migration/) Grafik bearbeitet: Materna, S. Seiler / T. Lansing

Rehosting (Lift & Shift)

Virtuelle Maschinen (VMs) oder auch hardwarebasierte Server werden mit geeigneten Hilfsmitteln, wie z.B. dem Dienst AWS Import / Export aus der bestehenden Infrastruktur (z.B. Rechenzentrum des Kunden) exportiert und auf virtuelle Maschinen (EC2-Instanzen) in der Cloud ausgerollt. Eine Anpassung beim Serversizing etc. findet zunächst nicht statt. Allerdings ist sehr wahrscheinlich eine Storage-Migration (z.B. NFS Mounts zu Amazon Elastic File System) und damit einhergehend ggf. auch minimale konfigurative Anpassungen an der Anwendung notwendig. Rehosting ist mitunter auch der erste sinnvolle Schritt, selbst wenn die spätere Einbeziehung von nativen Clouddiensten geplant ist. Zum einen, weil der schwierige Teil – die Migration der Applikation und Daten sowie des Traffics – damit bereits erledigt ist, zum anderen weil durch das Lift & Shift bereits weitere Erfahrung im Nutzen der Cloud dazu gewonnen wurde.

Replatforming (Lift & Reshape)

Replatforming, von Stephen Orban (früherer Head of Enterprise Strategy bei AWS) auch gerne als „lift-tinker-and-shift“ bezeichnet, erweitert „Lift & Shift“ dahingehend, dass bei der Migration eine Optimierung hinsichtlich der Infrastruktur (z.B. Anzahl der virtuellen CPUs in einer VM oder Update auf eine neuere Betriebssystemversion) vorgenommen wird. Gegebenenfalls sind kleinere Anpassungen an der Software notwendig oder muss eine Neuinstallation in der Zielplattform durchgeführt werden. In diesem Schritt werden – sofern sinnvoll – auch Datenbanken zu Amazon Relational Database Service migriert. Dabei unterstützt der AWS Database Migration Service , mit dem sich nahezu alle bekannten Datenbanken (Oracle, Microsoft SQL Server, MySQL, MariaDB, PostgreSQL) ohne nennenswerte Downtime zu AWS migrieren lassen. In diesem Zuge ist mitunter auch ein Wechsel der Datenbank-Engine möglich, um zukünftig Lizenzkosten zu sparen.

Ferner versteht man unter Replatforming auch den Umzug einer bestehenden Applikation auf eine andere Plattform. Bei Amazon bietet sich hier für einen „quick win“ der AWS Elastic Beanstalk an. Bei Elastic Beanstalk wird neben der Bereitstellung die Kapazitätsbereitstellung, Lastverteilung und automatische Skalierung bis zur Statusüberwachung der Anwendung übernommen, so dass sich Entwickler um die darunterliegenden Server nicht weiter kümmern müssen.

Refactoring (Decouple & Rewrite) / Rearchitecting (Replace)

Hierbei ist sicherlich der größte Aufwand einzuplanen, je nachdem wie weit die Neustrukturierung der Anwendung gehen soll. Versteht man unter dem Refactoring noch den teilweisen Ersatz bestehender Komponenten (bestimmte Use Cases der Anwendung durch Clouddienste ersetzen), wird bei einem Rearchitecting, bzw. Replace eine vollständige Neuentwicklung der Applikation mit cloud nativen Diensten angestrebt. Diese Strategie wird zumeist flankiert von der kompletten Ablösung der ursprünglichen Middleware und ggf. einem Wechsel der Betriebssysteme oder Plattform. Dies wäre dann klassischerweise die Neuentwicklung eines Monolithen zu einer Microservice-Architektur bis hin zu einer serverlosen Umsetzung auf Basis von AWS Lambda oder der Einsatz von weiteren sinnvollen Clouddiensten.

Repurchasing

Ein Shift in die Cloud muss nicht immer das sinnvollste Ziel sein. Ein gangbares Mittel ist auch die Ablösung einer bestehenden Applikation durch ein neues Produkt. Heutzutage wird dies möglicherweise der Wechsel von einer On-Premise- zu einer SaaS-Lösung sein, oder der Austausch des Anbieters, wie z.B. von Salesforce CRM zu Microsoft Dynamics.

Wenn die bestehende Standardsoftware eines Dienstleisters nicht (mehr) alle ihre Bedürfnisse erfüllt, kann es sinnvoll sein, über eine individuelle Softwarelösung nachzudenken. Hier hilft unser Team der Materna Software Factory gerne weiter.

Retire

In einigen Rechenzentren werden Anwendungen betrieben, die gar nicht mehr genutzt werden. Wenn sich bei der Durchführung des Cloud Readiness Check herausstellt, dass dem so ist, ist es ein adäquates Mittel, diese abzuschalten.

Retain

Applikationen in diesem Pfad werden (oft nur im ersten Schritt) nicht weiterverfolgt, sei es, weil die Migration für das Business schlichtweg keinen Sinn macht (Kosten- / Nutzenbetrachtung), eine bestimmte Rechnerarchitektur für den Betrieb vonnöten ist oder weil Regularien gegen eine Migration sprechen.

Retain könnte man auch als „re-visit“ oder „Zur Wiedervorlage“ bezeichnen. Applikationen in diesem Pfad sollten regelmäßig erneut geprüft werden. Die Cloud entwickelt sich so schnell weiter, dass mitunter schon in Kürze ein passender Dienst verfügbar ist.

 

Zusammenfassung

Die oben skizzierten Migrationspfade bieten sich zur Orientierung für eine Migrationsstrategie an. Dabei sind vor allem die Grenzen zwischen „Lift & Shift“ und „Lift & Reshape“ nicht wirklich trennscharf. Oftmals lässt sich allerdings festhalten, dass zunächst ein 1:1 Umzug der bestehenden Infrastruktur den sinnvollsten Einstieg darstellt. Auf dieser Basis (und den bereits migrierten Daten / Applikationen) lässt sich dann sukzessive das volle Cloud-Potential ausschöpfen und im Bereich TCO viel Geld sparen.

Kontaktieren Sie uns gerne für ein erstes Gespräch, wir helfen Ihnen weiter bei ihrem stressfreien Einstieg in die Cloud.

Alle Beiträge dieser Blog-Serie zum Thema Cloud:

Teil 1 Darf es etwas weniger sein – wie man in der Cloud Kosten sparen kann
Teil 2 Wege in die Cloud: Die 6 R’s der Cloud-Migration
Teil 3 Designermuster für Cloud-Systeme – Design Patterns
Teil 4 AWS Cloud Adaption Framework

Schlagwörter: , ,

Autoreninfo

Unser Blog wird von unseren Mitarbeitenden aus unterschiedlichen Bereichen geschrieben. Wir richten uns an alle IT-interessierten Leser:innen. Komplexe IT-Themen und IT-Projekte sind unser Alltagsgeschäft. Unser Fokus liegt daher auf spannenden Themen rund um die Welt der IT und wie diese unser Leben sowie die Gesellschaft beeinflusst und verändert.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Bitte füllen Sie dieses Feld aus.
Bitte gib eine gültige E-Mail-Adresse ein.
Bitte füllen Sie dieses Feld aus.
Bitte füllen Sie dieses Feld aus.
Sie müssen den Bedingungen zustimmen, um fortzufahren.

Darf es etwas weniger sein? Wie man in der Cloud Kosten sparen kann
Personalausweis und Smartphone als Lesegerät