„Die 6 Rs“ Mit der passenden Migrationsstrategie in die Cloud

Autor / Redakteur: Christian Bachmann* / Elke Witmer-Goßner

Cloud Computing findet in vielen Fällen durch den Einsatz in neuen Projekten Einzug in die Unternehmen. Mit einer Migration lassen sich die Vorteile der Cloud nicht nur für neue, sondern auch für bestehende Anwendungen nutzen.

Die Cloud bietet großes Verbesserungspotenzial für bestehende Anwendungen, aber die möglichen Migrationspfade sollten Schritt für Schritt begangen werden.
Die Cloud bietet großes Verbesserungspotenzial für bestehende Anwendungen, aber die möglichen Migrationspfade sollten Schritt für Schritt begangen werden.
(Bild: © ra2 studio - stock.adobe.com)

Der Aufwand für eine Migration wird jedoch häufig gescheut, weil das Risiko zu hoch und der Nutzen zu gering eingeschätzt wird. Mit der passenden Migrationsstrategie lässt sich das Risiko jedoch minimieren, indem die Migration kleinschrittig durchgeführt wird, statt in einem großen Big-Bang-Projekt.

AWS hat dazu 6 Migrationsstrategien definiert, auch die 6 Rs genannt. Wie diese Strategien angewendet werden und welche Vorteile sie mitbringen, wird im Folgenden genauer betrachtet. Außerdem wird betrachtet, wie man die passende Migrationsstrategie auswählt und anwendet.

Gründe für die Migration einer Applikation in die Cloud

Durch eine Migration kann die bestehende Anwendung die Vorteile der Cloud nutzen. Als erstes kommt die Kosteneffizienz zum Tragen. Allein durch die automatische Skalierung und das Pay-per-Use-Preismodell lassen sich bereits mit geringem Migrationsaufwand Kosten reduzieren. Zudem wird ein Großteil der Verantwortung für den Betrieb der Anwendung und für die Wartung der Infrastruktur an einen Cloud-Anbieter ausgelagert. Die Cloud-Anbieter sind auf die Bereitstellung der Infrastruktur spezialisiert und können die Anwendung dadurch kosteneffizienter betreiben, im Vergleich zum Betrieb on-premises.

Ein weiterer wesentlicher Vorteil ist die Steigerung der Agilität bei der Entwicklung. Durch den Einsatz von Cloud-Native-Diensten können neue Features schneller umgesetzt werden. Infrastrukturkomponenten werden in der Cloud innerhalb von Minuten bereitgestellt. Im Wettbewerb ist eine schnelle „Time to Market“ ein großer Vorteil. Durch die Automatisierung der Infrastruktur mit Infrastructure as Code kann die betriebliche Qualität, bei gleichzeitiger Reduktion der Kosten, sogar gesteigert werden.

Migrationsstrategien: Die 6 Rs

Die sechs Strategien für die Migration einer Anwendung in die Cloud wurden von AWS definiert und sind angelehnt an das „5-R’s-Model“ von Gartner. Die Strategien beinhalten Rehosting, Replatforming, Repurchasing, Refactoring, Retain und Retire und können direkt oder aufeinander aufbauend angewendet werden.

1. Repurchasing
Mit der Repurchasing-Strategie können Unternehmen von einer selbst betriebenen Software auf ein Cloud Produkt umsteigen – beispielsweise von einem selbst betriebenen Ticket- oder Dokumentenmanagement-System zu einem Software-as-a-Service Produkt (SaaS). Dabei übernimmt der Cloud-Anbieter die Verantwortung für die Bereitstellung und den Betrieb der Software. Ein großer Vorteil ist, dass durch die Anwendung der Repurchasing-Strategie der Aufwand für die Bereitstellung und die Wartung der Infrastruktur entfällt. Hinzu kommt die Tatsache, dass die Überführung der Bestandsdaten von einem alten in ein neues System in der Regel durch Werkzeuge unterstützt wird. Dadurch ist der Migrationsaufwand bei dieser Strategie eher gering.
Die Einschränkung bei dieser Strategie ist jedoch, dass nur auf vorhandene Angebote zurückgegriffen werden kann. Eine Anpassung der Software an die eigenen Bedürfnisse ist demnach nur sehr eingeschränkt möglich. Wenn ein Unternehmen lediglich das Ziel verfolgt, die Kosten zu reduzieren und die Fokussierung auf das eigene Kerngeschäft zu legen, ist die Repurchasing-Strategie der richtige Weg.

2. Rehosting –  auch bekannt als „Lift-and-shift“
Die Rehosting-Strategie verfolgt das Ziel, Anwendungen von On-Premises in die Cloud zu überführen, ohne Anpassungen vorzunehmen zu müssen. Zudem ist sie leicht anzuwenden und durch Werkzeugunterstützung größtenteils automatisierbar. Die Strategie eignet sich insbesondere für Alt-Anwendungen, die nur schwer anzupassen sind und für Anwendungen die hohe Skalierungsanforderungen haben.
Ähnlich wie bei der Repurchasing-Strategie ist das Ziel im Wesentlichen die Kostenersparnis beim Betrieb der Anwendungen. Erfahrungsgemäß konnten Unternehmen in Einzelfällen allein durch den Umzug in die Cloud bis zu 25 Prozent oder mehr bei den Betriebskosten einsparen.

3. Replatforming
Bei der Replatforming-Strategie werden möglichst viele Komponenten einer Anwendung durch Cloud-Services ersetzt, ohne dabei die Architektur anzupassen. Dabei kann auf teilweise hunderte verschiedene Dienste der Cloud-Anbieter zurückgegriffen werden. Darunter fallen die typischen Komponenten wie Datenbanken, Messaging-Dienste und Speicherdienste. Diese Komponenten sind häufig schwer zu dimensionieren, fehleranfällig und wartungsaufwändig. Allerdings werden diese Probleme durch die vom Cloud-Anbieter verwalteten Dienste gelöst. Um den Anpassungsaufwand gering zu halten, werden bevorzugt Komponenten ersetzt, zu denen es ähnliche Dienste in der Cloud gibt. Die wesentlichen Vorteile nach Anwendung dieser Strategie sind der geringere Wartungsaufwand für den Betrieb sowie die höhere Skalierbarkeit und die höhere Zuverlässigkeit der Anwendung.

Einordnung der Migrationsstrategien nach Kosten und Nutzen.
Einordnung der Migrationsstrategien nach Kosten und Nutzen.
(Bild: Adesso)

4. Refactoring – auch Rearchitecting genannt

Beim Einsatz der Refactoring-Strategie wird auch die Architektur der Anwendung überarbeitet, um das volle Potenzial der Cloud zu nutzen. Nach der Anwendung der Refactoring-Strategie wird die Anwendung eine Cloud-Native-Anwendung eingesetzt, die das Geschäftsmodell und die kontinuierliche Weiterentwicklung bestmöglich unterstützt. Die Refactoring-Strategie sollte inkrementell nach den Grundprinzipien der agilen Softwareentwicklung angewendet werden. Das garantiert zu jeder Zeit lauffähige Software, die auch während der Cloud-Migration um neue Features erweitert werden kann. Google nennt das Vorgehen „move-and-improve“. Bei der Refactoring-Strategie werden möglichst viele Komponenten und Dienste der Anwendung an den Cloud-Anbieter ausgelagert, denn dieser ist auf den Betrieb dieser Dienste spezialisiert. Dadurch reduziert sich der Wartungsaufwand für Infrastrukturkomponenten und es kann mehr Fokus auf die Weiterentwicklung des Geschäftsmodells gelegt werden.

Ergänzendes zum Thema
Aus folgenden Schritten besteht die Refactoring-Strategie
  • Umstellung auf eine verwaltete Laufzeitumgebung: Falls noch nicht geschehen, wird die Anwendung nun als Docker Container ausgeführt. Alle Cloud-Anbieter bieten dafür hoch automatisierte Container-Laufzeitumgebungen an. Bei diesen Laufzeitumgebungen wird die Verantwortung für die Bereitstellung und die Wartung der darunterliegenden Infrastruktur an den Cloud-Anbieter ausgelagert.
  • Automatisierung mit „Infrastructure as Code“: Bei allen Cloud-Anbietern können Infrastrukturkomponenten wie virtuelle Maschinen, Datenspeicher, Netzwerkkomponenten und auch die zugehörigen Berechtigungen mit „Infrastructure as Code“ (kurz IaC) definiert werden. Durch IaC werden Änderungen an der Infrastruktur versioniert, was Nachvollziehbarkeit der Infrastrukturänderungen und Rollbacks ermöglicht. Ebenso ermöglicht IaC die Wiederverwendung von Infrastruktur-Definitionen. Die Automatisierung der Infrastruktur sorgt insgesamt für Stabilität und reduziert Fehler durch Anpassungen von Hand.
  • Cloud Native Services nutzen: Wie bei der Replatforming-Strategie werden möglichst viele Komponenten der Anwendung durch Cloud-Dienste ersetzt. Im Vergleich zur Replatforming-Strategie nimmt man bei der Refactoring-Strategie nun auch größere Anpassungen vor. Im Idealfall kommen dabei Serverless Services zum Einsatz, die den höchsten Grad an Skalierung bei gleichzeitig niedrigem Betriebsaufwand bieten. Darunter fällt auch das Auslagern von statischen Webseiten in einen Objektspeicher und die Nutzung von Logging-Diensten der Cloud-Anbieter.
  • Die Anwendung in kleinere Module zerlegen: Da die Cloud ein Pay-per-Use-Modell nutzt, ist es sinnvoll, die Anwendung in kleinere, eigenständige Komponenten aufzuteilen, denn kleinere Komponenten skalieren kosteneffektiver.
  • Innerhalb der Komponenten wird geprüft, ob einzelne Funktionen der Anwendung als Serverless Functions beziehungsweise „Functions-as-a-Service“ (FaaS) ausgelagert werden können. Dazu eignen sich besonders asynchrone oder event-basierte Abläufe, wie Dokumenten- oder Bildverarbeitung, die schnell hoch und runter skalieren müssen oder unregelmäßig verwendet werden. Einige Programmiersprachen beziehungsweise Frameworks wie Go, NodeJS oder Quarkus sind für FaaS deutlich besser geeignet als Java. Bei Letzterem sollte die Umstellung auf FaaS mit einer Umstellung der Programmiersprache einhergehen. Die Zerlegung kann unter Anwendung des „Strangler Fig Pattern“ für evolutionäre Architekturen inkrementell erfolgen. Die folgende Grafik veranschaulicht das Vorgehensmodell des „Strangler Fig Pattern“.

5. Retain
Retain und Retire sind keine Migrationsstrategien im eigentlichen Sinne. Die Retain-Strategie wird angewendet, wenn eine Migration in die Cloud keinen erhöhten Nutzen bringt. In diesem Fall wird die Anwendung weiter on-premises betrieben und nicht in die Cloud migriert. Die Entscheidung für die Retain-Strategie ist keine endgültige Entscheidung gegen eine Migration. Es sollte regelmäßig überprüft werden, ob eine der anderen Migrationsstrategien angewendet werden soll.

6. Retire
Die Retire-Strategie wird angewendet, wenn die Anwendung nur noch selten genutzt wird. In dem Fall wird die Anwendung stillgelegt, um die Betriebs- und Wartungskosten einzusparen.

Veranschaulichung des „Strangler Fig Pattern“: Neue Features werden als neue Module in die Anwendung integriert. Ein Dispatcher sorgt für die Verteilung der Anfragen auf die Module. Gemeinsam genutzte Funktionalität wird anschließend als neues Modul aus der bestehenden Anwendung herausgelöst. Über die Zeit wird die Anwendung dadurch in kleinere Module zerlegt. Die Zerlegung der Anwendung fördert außerdem die unabhängige Entwicklung der Teams, wodurch Features einfacher in Produktion gebracht werden können.
Veranschaulichung des „Strangler Fig Pattern“: Neue Features werden als neue Module in die Anwendung integriert. Ein Dispatcher sorgt für die Verteilung der Anfragen auf die Module. Gemeinsam genutzte Funktionalität wird anschließend als neues Modul aus der bestehenden Anwendung herausgelöst. Über die Zeit wird die Anwendung dadurch in kleinere Module zerlegt. Die Zerlegung der Anwendung fördert außerdem die unabhängige Entwicklung der Teams, wodurch Features einfacher in Produktion gebracht werden können.
(Bild: Adesso)

Vergleich und Auswahl der Migrationsstrategien

Die Auswahl der passenden Migrationsstrategie ist eine Abwägung zwischen Kosten und Nutzen. Abbildung 2 zeigt die Einordnung der vorgestellten Migrationsstrategien. Die Repurchase-Strategie bietet den größten Nutzen im Vergleich zum Migrationsaufwand. Daher ist diese die erste Wahl, insofern es eine passende Software-as-a-Service-Lösung auf dem Markt gibt. Die Strategien Rehosting, Replatforming und Refactoring können allerdings nacheinander angewendet werden. Mit jeder Strategie steigt dabei der Migrationsaufwand, aber auch der Nutzen. Die Strategien nacheinander anzuwenden ist insofern hilfreich, als dass die weiteren Migrationsstrategien daraufhin leichter anzuwenden sind.

Die Überführung der Anwendung in die Cloud sollte mit der Rehosting-Strategie begonnen werden, da der Migrationsaufwand überschaubar und kosteneffizient ist.

Christian Bachmann, Adesso SE.
Christian Bachmann, Adesso SE.
(Bild: Adesso)

Im nächsten Schritt wird die Replatforming-Strategie angewendet. Mit dieser können weitere Kosten eingespart werden und die betriebliche Qualität und die Agilität in der Entwicklung steigt an. Die Refactoring-Strategie erfordert den höchsten Migrationsaufwand, bietet aber auch den größten Nutzen. Sie eignet sich vor allem für wettbewerbsintensive Geschäftsmodelle oder hochfrequentierte Anwendungen.

* Der Autor Christian Bachmann arbeitet als Software Architekt bei der Adesso SE in unterschiedlichen Bereichen. Er ist Cloud-Enthusiast und zertifizierter Solutions Architekt für die AWS Cloud.

(ID:47006070)