„Rehost“, „Replatform“ und „Rearchitect“ neu durchdacht: Cloud-Migration für die Praxis

Wenn wir Unternehmenskunden dabei helfen, umfassende Migrationen von Anwendungen in die Cloud vorzunehmen, erlebt unser Professional Services-Team gelegentlich, wie unzählige Stunden darauf verwendet werden, den Zustand der Anwendungen zu evaluieren und diese verschiedenen Migrationsstrategien wie „Rehost“, „Replatform“, „Refactor“ usw. zuzuordnen. Dies ist eine gängige Praxis, bei der die einzige Frage zu sein scheint, ob es 5, 6, 7 oder 8 verschiedene „R“-Strategien gibt. 

In Wirklichkeit sind die beliebten „R“-Strategien gar keine Strategien. Sie sind nur Platzhalter für alle Aspekte, die Sie von Ihren Anwendungen noch nicht kennen. Wir erleben, dass insbesondere die Richtlinien und Funktionen eines IT-Unternehmens den Migrationspfad bestimmen und letztendlich den früheren Top-Down-Plan der Entwicklerinnen und Entwickler nichtig machen. 

Noch wichtiger ist, dass so gut wie keine Anwendung in Bezug auf alle ihre Ebenen ausschließlich zu einer der Migrationsstrategien passt. Die Datenbank wird z. B. von selbstverwaltetem PostgreSQL auf verwaltetes Cloud SQL migriert, während die Anwendungsebene möglicherweise als dieselbe VM auf Compute Engine gehostet wird und der Load-Balancer durch den globalen Load-Balancer von Google ersetzt wird. 

In der Regel benötigen die meisten Unternehmen einen ganzheitlicheren Migrationsansatz. Aus diesem Grund achtet unser Professional Services-Team bei der Interaktion mit Unternehmenskunden nur wenig auf die Nennungen dieser Strategieebenen. In der frühen Planungsphase interessieren wir uns mehr für die Menschen und Prozesse, bevor wir uns näher mit der Technologie befassen. Zunächst sollten Sie vielleicht über das Google Cloud Adoption Framework nachdenken und überlegen, ob Ihre Anforderungen an die Cloud-Migration taktisch, strategisch oder transformativ sind. Wenn Sie dies ermittelt haben, sollten Sie drei grundlegende Migrationsansätze prüfen: 

Ansatz: Migration Factory

Der Migration Factory-Ansatz, bei dem wir virtuelle Maschinen oder Container in Gruppen kopieren oder bereitstellen, funktioniert gut, wenn es sich um einfache, einander recht ähnliche Anwendungen handelt, und wenn das Team, das die Migration durchführt, dies selbst ohne viel Koordination mit einzelnen Anwendungsteams bewerkstelligen kann. Dieser skalierte Ansatz eignet sich für Initiativen, die infrastruktur- statt anwendungsorientiert sind, insbesondere für umfassende Rechenzentrumsmigrationen, und kann mit Lösungen wie Google Cloud VMware Engine oder speziellen Tools wie Migrate for Compute Engine oder unserem Database Migration Service ausgeführt werden.  

Auf der anderen Seite eignet sich der Migration Factory-Ansatz nicht besonders gut für einen Change Management-Prozess (durch interne Richtlinien oder externe Regulierungen), bei dem jede Anwendung einzeln einer manuellen Prüfung unterzogen wird. Der für die Prüfung und Kontrolle der unausweichlichen Änderung erforderliche Aufwand überwiegt die durch die automatisierte Migration von Code und Daten erzielte Zeitersparnis. Dasselbe gilt, wenn Sie umfassende Änderungen an Ihrer CI/DC-Toolkette vornehmen müssen, bevor Sie die Änderungen in Ihrer Cloud-Umgebung vornehmen können. Wenn Sie den Änderungsprozess berücksichtigen, scheint eine einfache Migration der lokalen IT-Infrastruktur in die Cloud aus Kostensicht weniger attraktiv. 

Zusammengefasst lässt sich festhalten, dass es einige konkrete Szenarien gibt, in denen der Migration Factory-Ansatz die beste Option ist. Es gibt jedoch viele Szenarien, die diese Kriterien nicht erfüllen. 

Ansatz: Greenfield-Softwareentwicklung

Ganz im Gegensatz zum Migration Factory-Ansatz gibt es die Möglichkeit, keine vorhandenen Anwendungen zu migrieren, sondern stattdessen eine neue „Greenfield“- oder „cloudnative“ Anwendung zu zu entwickeln. Dieser Ansatz entspricht im Grunde den gängigen Methoden der agilen Softwareentwicklung. Der Ansatz bezieht sich nicht speziell auf die Cloud. Die verwalteten und serverlosen Dienste der Cloud eignen sich besonders gut für die schnelle Entwicklung einer solchen Softwarelösung. 

Eine neu entwickelte Anwendung sollte wie ein Produkt, nicht wie ein Projekt behandelt werden. Das heißt, das Team stellt seine Arbeit nicht ein, wenn der letzte Meilenstein erreicht wurde. Stattdessen muss es die Anwendung weiter überwachen und ihre Funktionen ständig weiterentwickeln und erweitern (oder zumindest so lange, bis die Verwendung der Anwendung eingestellt wird). In dieser Hinsicht unterscheidet sich der Ansatz grundlegend von jeder anderen Art der Migration. Es gibt keine vordefinierten Zeitpläne und bei der Entwicklung werden keine einseitigen Voraussetzungen festgelegt. Es gibt lediglich Sprints einer inkrementell nutzbaren Software mit vielen Funktionen. Das mit der Entwicklung der Anwendung vertraute Team sollte klein, funktionsübergreifend und dauerhaft aufgestellt sein. Es braucht deutlich mehr Zeit, eine neue Anwendung zu entwickeln, als eine vorhandene zu migrieren.

Ansatz: Modernization Factory

Die Mehrzahl der Migrationen, die wir bei unseren Unternehmenskunden sehen, beinhaltet in irgendeiner Form die Modernisierung einer Anwendung nach der anderen. 

Softwaremodernisierung ist breit gefächert und umfasst zahlreiche unabhängige Vorgehensweisen und Best Practices zur Verbesserung von Skalierbarkeit, Verfügbarkeit, Sicherheit und Langlebigkeit der Anwendung an sich, während gleichzeitig der für Bereitstellung und Betrieb der Anwendung erforderliche Aufwand gesenkt werden soll. 

Es sind diese inkrementellen Modernisierungen, die in der Regel dazu führen, dass Unternehmenskunden echte TCO-Einsparungen erzielen – und sie sind auch der Grund, weshalb eine Verbesserung ihrer DevOps-Fähigkeiten Hand in Hand mit der Cloud-Einführung geht. Da in der Cloud immer APIs eingesetzt werden, kann alles automatisiert werden. 

So kann beispielsweise die Bereitstellung abgestimmter Projektumgebungen mithilfe der Infrastruktur entscheidend für eine effektive Modernisierung sein. Es kann für die Skalierung große Vorteile bringen, zustandsorientierte von zustandsloser Logik zu entkoppeln. Das Entfernen des Shell-Zugriffs von allen Servern, sodass stattdessen nur Änderungen durch eine CI/CD-Pipeline weitergegeben werden können, kann für Ihre Aufstellung in puncto Sicherheit von enormer Bedeutung sein. Es gibt Hunderte weitere Beispiele für inkrementelle Softwaremodernisierungen und keines davon lässt sich in eine „R“-Migrationsstrategie pressen.

Wenn wir unsere Unternehmenskunden dabei unterstützen, ihre Anwendungen mit einigen Modernisierungen zu Google Cloud zu migrieren, nutzen wir die gängigen Anwendungsebenen (bzw. „Archetypen“) in ihrem aktuellen Zustand und verständigen uns auf eine begrenzte Anzahl an angestrebten Cloud-Diensten, eine Reihe von Modernisierungstaktiken und ein bestimmtes Maß an Automatisierung über CI/CD und Infrastruktur als Code. Weitere Modernisierungen, die über diese grundlegenden Vereinbarungen hinausgehen, sollten zurückgestellt werden, bis die Anwendung für den Betrieb in der Cloud bereit ist.

Fazit

Welchen Ansatz sollten Sie für Ihre Anwendungen wählen? Um eine gute Migrationsstrategie zu entwickeln, sollten Sie zuerst Klarheit darüber erhalten, warum Ihr Unternehmen den Wechsel in die Cloud vollzieht. Ausgehend davon planen Sie Ihr weiteres Vorgehen. 

Nehmen wir noch einmal das Beispiel des Google Cloud Adoption Framework: Wenn Ihr Ziel darin besteht, Kosten zu senken und gleichzeitig nur minimale Änderungen an Ihren Anwendungen vorzunehmen (also ein taktisches Ziel), dann empfehlen wir den Migration Factory-Ansatz. Wenn Ihr Ziel darin besteht, die Vorteile zu maximieren, die Sie durch Ihre Software erhalten (also ein strategisches Ziel), dann empfehlen wir den Modernization Factory-Ansatz oder den Greenfield-Softwareentwicklungsansatz. Wenn Ihr Ziel darin besteht, mit neuen Anwendungen auf innovative Weise neue geschäftliche Herausforderungen zu meistern (also ein transformatives Ziel), empfehlen wir den Greenfield-Softwareentwicklungsansatz. 

Nachdem Sie ermittelt haben, warum Ihr Unternehmen in die Cloud wechseln möchte, und sich auf das weitere Vorgehen verständigt haben, ergibt sich alles andere von selbst – auch die Aspekte, die nicht durch „R“-Strategien abgedeckt sind. 

Weitere Informationen über eine Migration zu Google Cloud finden Sie in unserer Website zum Thema Rechenzentrumsmigration in die Cloud. Alternativ können Sie sich auch für eine kostenlose Evaluation des Kostenaufwands einer Cloud-Migration anmelden.

^{1. Die 5 Rs von Gartner
2. Die 6 Rs von AWS
3. Die 7 Rs von Citrix
4. Die 8 Rs von Infosys}