Cloud Migration: Definition, Typen, Vor- und Nachteile

Bei der Cloud Migration wird sowohl die Art und Weise geändert wie Anwender:innen die Software wahrnehmen als auch wie sie betrieben wird.

Nutzer:innen wünschen sich zunehmend Anwendungen, die immer und überall verfügbar sind. Das bedeutet, dass diese sowohl im Browser als auch auf einem Mobilgerät bedient werden können. Völlig unabhängig von einem geschützten Intranet. Dabei sollen sie leicht zu bedienen sein und stets gut performen. 

Aus Betriebssicht wird erwartet, dass die Software auf Standardkomponenten aufsetzt und keine individuellen Umgebungen benötigt. Dabei soll die Anwendung mit der Last skalieren und einen effizienten und kostensparenden Betrieb ermöglichen.

Ausgangspunkt ist in der Regel eine Anwendung, die im Netzwerk und im Kontext des Kunden bzw. der Anwender:innen betrieben wird. Das ist häufig eine Client-Server-Architektur mit einer Desktopanwendung, die auf eine Datenbank zugreift. Die Software ist hoch spezialisiert und sehr flexibel zu konfigurieren. Die Inbetriebsetzung ist komplex und der Betrieb erfordert entsprechende Kenntnisse bei der IT. 

Cloud Migration transformiert diese Art von Anwendungen, damit sie den modernen Anforderungen an Software und deren Betrieb entsprechen.

In der Praxis unterscheidet man im Wesentlichen drei Strategien zur Cloud Migration: Rehosting, Replatforming sowie Refactoring. Diese wirken sich unterschiedlich auf die Software selbst aus.

Beim Rehosting wird die Anwendung auf virtuellen Maschinen des Cloud-Anbieters betrieben. Das Bereitstellen kann automatisiert werden, die Kostenersparnis entsteht im wegfallenden Betrieb von Hardware und Rechenzentrum. Das Patch-Management, Installation, Konfiguration und der Betrieb der Anwendung bleiben bestehen. Häufig können auch Zusatzdienste wie Backup und Restore des Anbieters dazu genommen werden.

Folgende Probleme gilt es bei dieser Strategie zu meistern:

• Keine Konnektivität der Anwender:innen zum System: Insbesondere bei Client-Server-Anwendungen kann ein direkter offener Zugriff nicht gestattet werden. Dies lässt sich durch das Anbinden der Cloud-Anwendung an das Intranet per VPN lösen.
• Hohe Latenzen: Beim Nutzen der Anwendung führt die lange Netzwerkstrecke zwischen Endgerät und Rechenzentrum zu Latenzen. Der Grund ist häufig ein sogenanntes „Chatty-Interface“. Wird die Datenübertragung gebündelt, führt dies in der Regel zwar dazu, dass mehr Daten angefragt werden. Insgesamt betrachtet, muss dann jedoch seltener angefragt werden. Als Alternative sind virtuelle Arbeitsplätze in der Cloud oder Terminal-Server-Lösungen möglich. Diese verteuern jedoch die Lösung und sind auch weniger akzeptiert.

Die Lift-and-Shift-Strategie ist eine gute Zwischenlösung für Anwendungen, die schon über eine browserbasierende oder basierte Oberfläche verfügen. Bei Desktopanwendungen muss in der Regel mit Akzeptanzprobleme gerechnet werden. Und diese müssen auch adressiert werden.

Die Kernidee der Replatforming-Strategie ist es, erste Teile der Anwendung auf die Plattform-Dienste der Cloud zu migrieren. Hier wird mit den Teilen begonnen, die den größten Nutzen erzeugen. Mögliche Handlungsfelder dabei sind:

• Browserbasierte und mobile Benutzeroberflächen, für eine bessere User-Experience (UX) 
• Datenbanken und Storage als Software-as-a-Service-Lösung (SaaS), für einen kostengünstigeren und skalierenden Betrieb
• Teile des Backends als Micro-Services, für ein besseres und kostengünstigeres Skalieren

Ein großer Treiber für die Cloud Migration ist die Nutzererfahrung: Anwender:innen wünschen sich einfache Webanwendungen. Falls die Anwendung schon browserbasiert ist, liegt bereits eine Mehrschichtarchitektur vor. Hier muss dann in der Regel die Webtechnologie modernisiert und die Frontendanwendung auf die Plattform-Dienste wie App-Services angepasst werden.

Bei Desktop-Anwendungen muss oft erst eine Mehrschichtarchitektur hergestellt werden. Dies ist meist problemlos möglich, ohne die Gesamtanwendung zu erneuern. Teile der Benutzeroberfläche werden danach sukzessive als Webanwendung neu entwickelt, mit einem direkten Fokus auf die Plattformdienste.

Der große Vorteil dieser Strategie liegt darin, dass mit geringem Aufwand sehr schnell ein hoher Nutzen erzeugt wird. Da große Teile der Anwendung erhalten bleiben, werden bestehende Investitionen geschützt. Kompatibilität zu früheren Versionen sind gegeben und bestehende Kund:innen können weiter bedient werden. Zudem ist ein Parallelbetrieb mit den bestehenden Komponenten gewährleistet.

Die Lift,-Tinker-and-Shift-Strategie bietet die Möglichkeit, die Gesamtanwendung - so weit wie sinnvoll möglich - sukzessive zu migrieren. Fehlende Teile können im Parallelbetrieb erhalten bleiben. 

Unserer Erfahrung nach bildet die Refactoring-Strategie den Abschluss der Lift, Tinker and Shift-Maßnahmen. Sie bildet das eigentliche Zielbild der Anwendung ab. Die meisten Teile der Software werden auf die Zielplattform migriert. Und durch eine geschickte Planung können Kernkomponenten wieder verwendet werden.

Falls die Anwendung gleich als Ganzes migriert werden soll, ist ein starkes Risikomanagement sinnvoll. Es muss sichergestellt werden, dass bestehende Kundenanforderungen erfüllt werden, da in der Regel nicht alle Teile und Funktionen erneuert werden. Kompatibilitätsprobleme in den Daten, Anbindungen an Fremdsysteme und Prozesse sollten adressiert und kommuniziert werden. 

Für die Migration von großen Anwendungen ist zudem ausreichend Zeit einzuplanen. Auch werden dadurch Kapazitäten gebunden, die dann im bestehenden Kundengeschäft fehlen. Der große Vorteil liegt jedoch im „Ballast abwerfen“. Das können dann sowohl Funktionalitäten als auch konkrete Implementierungen und technische Plattformen sein.

Wie immer fangen Transformations- und Migrationsprojekte mit einer Analyse an. Typischerweise in einem Workshop mit allen Beteiligten (Geschäftsführung, Softwareentwicklung, Betrieb und eventuell Vertrieb). 

Bei der Cloud Migration geht es im ersten Schritt um eine Bestandaufnahme der Software: bestehende Architektur, verwendete Komponenten und die Abhängigkeit von Fremdsystemen wie Datenbanken, File-Shares, Windows-Komponenten und Authentifizierungsverfahren.

Im nächsten Schritt wird ein gemeinsames Verständnis bezüglich der Zielarchitektur und des Betriebsmodells für das Idealbild hergestellt. Wird die Anwendung ein SaaS-Produkt mit einem Self-Service-Anspruch oder eher eine dedizierte Instanz für einen Kunden. Wie werden die Features, das Customizing und das On-Boarding der Anwender:innen abgebildet? Sind Ausgangssituation und Zielbild geklärt, geht es um die Architektur. 

Im Wesentlichen wird hier zwischen zwei Richtungen unterschieden: Eine verteilte Applikation, die in Kubernetes oder Platform-Services der Hyperscaler Microsoft Azure, Amazon AWS oder Google GCP betrieben wird. Der große Vorteil des Betriebs über Kubernetes besteht darin, unabhängig von einem speziellen Hersteller zu sein (kein Vendor-Lock). Allerdings muss man sich selbst um das Integrieren, Skalieren und Orchestrieren kümmern. Bei den Plattform-Services wiederum erhält man eine deutlich höhere Abstraktion, verbunden mit schnelleren Entwicklungszyklen und einfacherem Betrieb. Natürlich ist die Welt nicht schwarz-weiß und die Vorteile beider Ansätze lassen sich auch gut miteinander kombinieren.

Sind die Themen Ausgangssituation, Zielbild, Betriebsmodell sowie Architektur geklärt, geht es darum eine Migrationsstrategie zu finden. Was sind die Mindeständerungen für einen Lift-and-Shift? Wie könnte eine erste Web-Anwendung aussehen? Wie kann man die Authentifizierung umstellen? Bei diesen Überlegungen entsteht dann eine Liste von Maßnahmen, die nach und nach angegangen werden. 

Je nach Ausbaustufe ergeben sich folgende Vorteile.

In der Regel ist der Betrieb einer Cloud-Anwendung deutlich wirtschaftlicher. Dabei gilt, je stärker die Abstraktion der Architektur ist, desto stärker ist auch ihre Wirtschaftlichkeit. Ein SaaS-Produkt kann mit deutlich mehr Effizienz betrieben werden als eine Lift-and-Shift-Migration in virtuellen Maschinen. Dies gilt vor allem, wenn die Last auf die Anwendung nicht konstant ist, sondern über den Tagesverlauf oder die Woche schwankt. Genau dann spielt die Cloud ihre Stärken voll aus.

Einfach zugängliche Browser- und Mobil-Anwendungen werden von den Anwender:innen deutlich besser akzeptiert als Desktop-Anwendungen, die eventuell über ein VPN auf die Daten im internen Netzwerk zugreifen. In Zeiten von Homeoffice und mobilem Arbeiten spielt vor allem dieser Aspekt eine zunehmend stärkere Rolle. Und auch für die IT-Verantwortlichen ist ein Self-Service-Onboarding und Customizing deutlich attraktiver, als wenn für jede Änderung eine spezialisierte Person einspringen muss. 

Es gibt immer mehr Entwickler:innen, die über Expertise in modernen Technologien verfügen als in Technologien, die vor zehn oder zwanzig Jahren populär waren. Das wiederum sichert auch die Zukunftsfähigkeit des Produktes.

Die Herausforderungen der Cloud Migration sind nur zu einem geringen Teil technischer Natur. Die größeren Herausforderungen liegen im organisatorischen Bereich. Das bedeutet, dass das vorhandene Geschäft bedient werden muss, während gleichzeitig in etwas Neues investiert wird. Dabei muss das gesamte Team für diese Transformation befähigt werden und die Kapazität muss entsprechend erhöht werden. Damit dieser Schritt gelingt, ist es wichtig darauf zu achten, dass alle Stakeholder abgeholt und mitgenommen werden und dass mögliche Bedenken ernstgenommen und ausgeräumt werden.

Sie haben Fragen zur Cloud Migration, dann lassen Sie uns reden. Wir bei bluehands haben den Anspruch, diesen Prozess zu begleiten und sorgen als Task-Force dafür, dass genau die richtigen Menschen zusammenkommen. Als Resulter kümmern wir uns darum, dass die Investitionen gesichert sind und Ergebnisse geliefert werden.