Cloud-Computing Softwarearchitektur

Wie komme ich am besten dahin?

Viele Firmen haben ihre ersten Erfahrungen mit der Cloud gemacht. Doch vielen steht der große Schritt, die meisten Anwendungen dort zu betreiben, noch bevor. Als eine Art Reiseplaner stellen wir hier unsere Erfahrungen mit dem Cloud Migration Framework vor und wie es hilft, bei der eigenen Multi-Cloud-Reise schneller und sicherer voranzukommen.

Frank Pientka

Principal Software Architect

28.08.2023
Lesezeit: 12 Minuten
136 Views

Am Anfang einer Reise ist es wichtig, sich einen groben Überblick über die vorhandenen Ressourcen und ihren Zustand zu schaffen.

Überblick verschaffen

Bei T-Systems hat sich dabei in den letzten Jahren das Cloud Migration Framework [CMF] bewährt. Es unterstützt dabei die großen Cloud-Plattformanbieter wie Microsoft, AWS, Google Cloud oder die eigene Open Telekom Cloud (OTC). Dabei wurden die eigenen jahrzehntelangen Erfahrungen mit Umzügen von Rechenzentren um aktuelle Cloud-Praktiken und Cloud-Anbieterbesonderheiten ergänzt. Es wird permanent an neue Anforderungen und Erfahrungen angepasst, um Kunden bei der weiteren Cloud-Transformation bestmöglich zu unterstützen. Das CMF umfasst drei Phasen (siehe Abbildung 1):

Am Anfang stehen eine Strategieberatung und Bewertung der bestehenden IT-Landschaft (Cloud Assessment).
In Phase 2 folgt die Migrationsvorbereitung (Cloud Mobilization): Applikationen und Systeme, aber auch die IT-Organisation mit ihren Mitarbeitern werden fit für die Cloud gemacht.
Phase 3 umfasst die eigentliche Migration von Workloads, einschließlich notwendiger Modernisierungen (Cloud Migration & Modernization).
Begleitende Phasen sind Betrieb (Ope- rations), Optimierung und Governance.

Abb. 1: Das Cloud Migration Framework (CMF)

Für jedes weitere Vertiefungsgebiet gibt es dann Cloud-spezifische Bereiche, wie Landezonen, Strategie, Kosten, Wissensaufbau, Migration oder Modernisierung.

Realistische Ziele und Bestandsaufnahmen

Am Anfang einer jeden Analyse steht ein Gespräch mit den relevanten Stakeholdern über die Ziele, die mit einer Cloud-Migration erreicht werden sollen, und wo aktuell die größten Schmerzpunkte sind, diese zu erreichen. Um sich ein realistisches Bild vom aktuellen Zustand der Organisation auf Ihrer Cloud-Reise zu machen, bietet es sich an, einen kurzen Cloud Readiness Check für die Bereiche Geschäftsmodell, Mitarbeiter, Prozesse, Plattformen, Betrieb und Sicherheit zu machen (siehe Abbildung 2).

Abb. 2: Migrationsziele festlegen

Wenn später mehr Informationen, zum Beispiel zu Kosten oder zum Nachhaltigkeitsziel, vorliegen, können diese als weitere Bereiche betrachtet werden. Da nicht Infrastrukturen migriert werden, sondern Anwendungen, ist es wichtig, diese gut zu verstehen. Dabei hat es sich bewährt, diese aus mehreren Gesichtspunkten zu betrachten (siehe Abbildung 3).

Abb. 3: Sichten auf eine Anwendung

Für jede Perspektive gilt es, mit den zuständigen Verantwortlichen die wichtigsten Anforderungen an Geschäft, Anwendung, Daten und Betrieb zu betrachten. Hier können gut Komponenten-, Systemkontextoder Verteildiagramme eingesetzt werden.

Koffer packen

Nachdem man sich pro Anwendung für eine Migrations- oder Modernisierungsstrategie entschieden hat, geht es an die Clusterung der Anwendung und ihrer Daten. Bei den Anwendungen hat es sich bewährt, diese nach technischer Komplexität und Geschäftskritikalität zu kategorisieren. Weiter sollten diese Technologieplattformen (Java, .NET, COTS) zugeordnet werden.

Oft wird man feststellen, dass die bestehenden Anwendungen nicht auf einem aktuellen supporteten oder sicheren Versionsstand sind. Hier stellt sich die Frage, ob man diese vor der Migration noch mal aktualisiert. Bei kleineren Versionssprüngen und kürzeren Migrationen wird man diese bereits in der Zielumgebung durchführen. Bei größeren Versionssprüngen (Upgrades) kann man die Cloud-Umgebung schon mal nutzen, um die Lauffähigkeit und das Migrationskonzept zu testen. Eine direkte Virtualisierung oder Containerisierung der Anwendung können die Migration zwar beschleunigen, sind jedoch eine vertane Chance, um technische Schulden zu minimieren. Besser ist eine frische und automatisierte Installation und Konfiguration der benötigten Infrastruktur. Dadurch kann man später auch Aktualisierungen schneller durchführen und behält eher den Überblick über die aktuell eingesetzten Versionen.

Trotzdem kann eine Containerisierung eine valide Option für einen PoT (Proof of Trust) sein, um sich mit der Technologie vertraut zu machen und die technischen und prozessoralen Voraussetzungen für spätere Migrationen zu schaffen, indem zum Beispiel eine DevSecOps-Pipeline mit Repository eingeführt wird, Deployment-, Test-, Betriebs- und Überwachungsprozesse für die Cloud modernisiert werden. Gleiches gilt für die Modernisierung bestehender Deployment-, Überwachungsoder Disaster&Recovery-Prozesse (siehe Abbildung 4).

Abb. 4: Migrationsansätze wirken sich auf DevOps-Prozesse aus

Bei einer Multi-Cloud-Strategie stellt sich die Frage, welche gemanagten Dienste der Cloud-Anbieter man nutzt oder ob man besser eine einheitliche Plattform kauft, mietet oder selbst entwickelt. Hier setzen sich immer mehr SaaS-Lösungen durch, die Multi-Cloud fähig sind. Das hat den Vorteil, dass man sich um die Pflege und den Betrieb zum Beispiel einer Monitoring-, Servicemanagement- oder DevSecOps-Lösung nicht mehr selbst kümmern muss, sondern diese Leistung aus der Cloud-as-a-Service (XaaS) bezieht.

Route wählen

Nachdem jede Anwendung einem Cluster zugeordnet ist, kann man nach der Bestandsaufnahme einen passenden Migrationsplan pro Anwendung erstellen. Hier sollten nur noch die Anwendungen näher betrachtet werden, die für eine Migration in die Cloud infrage kommen. Hier stellt sich die Frage, ob die Systemumgebung noch vor der Migration aktualisiert wird oder erst bei der Migration. Da es in der Quellumgebung oft viele Versionsvarianten gibt, ist es im Sinne einer Vereinheitlichung und Standardisierung besser, mit einer aktuellen Systemumgebung zu starten und diese gleich mitzutesten.

Ein großes Einsparungspotenzial bietet sich auch an bei der Konsolidierung vieler Anwendungen auf eine größere Umgebung, da dort Ressourcen gemeinsam effizienter genutzt werden können. Eine Cloud-Migration bietet hier die Chance zur Modernisierung, Konsolidierung und Optimierung der bestehenden Umgebungen und Prozesse. Dadurch werden Prozesse vereinfacht und mehr Flexibilität mit Optionen geschaffen. Automatisch überprüfte Governance-Regeln, Landezonen und eine Kostenverrechnung mit Budgetüberwachung sind vor der ersten Migration zentral festzulegen.

Da eine Migration oft in mehreren Schritten erfolgt, kann es zum Beispiel sein, dass man eine Anwendung zunächst rehostet und seine Datenbankdienste auf eine gemanagte Plattform umzieht, um diese später zu einer Cloud-nativen Anwendung umzubauen. Liegt eine Anwendung bereits virtualisiert vor, kann man diese durch das standardisierte OVF (Open Virtualization Format) 2.0 einfach in ein neues Zielvirtualisierungsformat konvertieren. Um Informationen zum Sizing oder benötigte Netzverbindungen zu erhalten, kann man sowohl die physischen als auch die virtuellen Maschinen scannen, um die dort gewonnenen Informationen an einer zentralen Stelle einheitlich und aktuell zu sammeln.

Die Erkennungssoftware kann man entweder mit einem Agenten auf jeder Maschine oder zentral im Netzwerksegment ohne Agenten laufenlassen. Gegenüber einer CMDB (Configuration Management Database) hat das den Vorteil, dass man realistische Werte und Informationen für ein Rightsizing erhält. Deswegen sollte man solch einen Scan nicht nur initial über wenige Stunden, sondern am besten mindestens eine Woche laufen lassen, um möglichst alle Lastprofile und Kommunikationsbeziehungen abzudecken (siehe Abbildung 5).

Abb. 5: Auswahl der Modernisierungsstrategie

Eine besondere Herausforderung stellen oft die Daten dar, da die Menge und der Zeitfaktor eine größere Rolle spielen als bei den Anwendungen. Kommt noch ein Wechsel des Datenbankprodukts hinzu, müssen auch die Konvertierungen vorher ausreichend getestet werden. Bei kleineren Datenmengen wird man mit einem Offline-Backup und Downtimes eher leben können als bei Live-Migrationen großer Datenmengen. Hier wird man an einem kombinierten Ansatz und einer schrittweisen Migration von Teildatenbeständen nicht vorbeikommen. Als ein universelles Werkzeug mit einer Unterstützung vieler Cloud-Speichersysteme und Protokolle hat sich zum einmaligen Kopieren oder Spiegeln das auf dem Tool Rsync basierende kostenlose Rclone [RCLONE] bewährt.

Besonders wenn mehrere Rechenzentren in eine Cloud-Region migriert werden, stellt sich auch die Frage nach einem Notfall-, einem Disaster- und Recovery-Konzept. Zusätzlich zu redundanten Verfügbarkeitszonen kann es sinnvoll sein, zumindest für Backups oder im Cold-Stand-by eine zweite Region als Backup vorzubereiten und zu nutzen. Bei einem Mehrregionenkonzept kann es sinnvoll sein, seine Daten nach regionalen Gesichtspunkten zu partitionieren. Das kann aus regulatorischen, aber auch aus Kosten- oder Latenzgründen sinnvoll sein. Ebenso lohnt es sich, sein Netzzonenkonzept für die Cloud zu überarbeiten, um durch eine stärkere Segmentierung eine höhere Sicherheit zu erreichen.

Reise planen und dokumentieren

Um möglichst viele und große Arbeitslasten (typischerweise 100 bis 1000 Anwendungen) auf ihre Cloud zu heben, bieten alle Cloud-Anbieter Werkzeuge und Dienste an. Standen am Anfang der Datentransfer und die Konvertierung von virtuellen Maschinen im Vordergrund, sind hier sowohl für die Datenbank- als auch die Anwendungsmigration mehrere Optionen und Werkzeuge hinzugekommen. Naturgemäß bietet hier AWS [Pie22, Pie23] das größte Spektrum an.

Auch bei Azure gibt es für die Anwendungen einige Werkzeuge und Migrationsoptionen. Bei den Datenbanken steht klar das eigene Produkt Azure SQL im Vordergrund. Bei Google gibt es zwar auch Anleitungen für die Migration von virtuellen Maschinen oder Datenbanken. Die angebotene Werkzeugunterstützung geht jedoch hier nicht so weit wie bei den anderen beiden Konkurrenten. Dafür gibt es bei der Containerisierung und Migration auf Kubernetes eine große Unterstützung.

Gerade für die Migrationsplanung großer Projekte war man bisher oft auf Spezialanbieter angewiesen, die man zusammen mit Beratern einkaufen konnte. Da Migrationen jedoch irgendwann abgeschlossen sein sollten, kann es sich lohnen, hier direkt auf die Angebote der Cloud-Anbieter zu setzen, wo man meist wenig für die Nutzung, sondern mehr für den Verbrauch zahlt. Die von den Cloud-Anbietern zur Verfügung gestellten Lösungen stammen oft von zugekauften Spezialanbietern (StratoZone von Google, CloudEndure und TSO Logic durch AWS übernommen). Diese wurden inzwischen um eigene Anforderungen erweitert oder durch eigene Lösungen (bei AWS MGN statt SMS) abgelöst. Auch hier sind die übergreifenden Lösungen AWS Migration Hub [AWSMIG] oder Azure Migrate [AZMIG] dem Google-Angebot [GCMIG] überlegen.

Tabelle 1 gibt einen kleinen Überblick über die Möglichkeiten bei den Cloud-Anbietern AWS, Azure und Google, ohne einen Anspruch auf Vollständigkeit.

Tabelle 1: Überblick Migrationswerkzeuge der Cloud-Anbieter

Diese Auswahl der geeigneten Werkzeuge hängt oft von den konkreten Anwendungs- und Migrationsszenarien ab. Bevor man anfängt, eigene Migrationswerkzeuge zu entwickeln oder produktspezifische (z. B. der Datenbankhersteller) zu verwenden, lohnt sich ein Blick auf die von den Cloud-Anbietern kostenlos angebotenen Werkzeugen. Oft decken diese mehre Phasen des Migrationsprozesses ab und sind in die anderen Dienste des Cloud-Anbieters einfacher zu integrieren.

Da es oft Überschneidungen bei den Einsatzgebieten der einzelnen Werkzeuge gibt, sollte man seine Anforderungen und die Optionen der Werkzeuge gut kennen. Hier hilft es auch, erfahrene Spezialisten verfügbar zu haben, die bereits Lösungen für kompliziertere Migrationsszenarien erfolgreich umgesetzt haben, um die Migrationen optimal und mit weniger Risiko durchzuführen.

Die Migration von Hunderten oder Tausenden von Arbeitslasten in die Cloud erfordert einen stufenweisen Ansatz, der Bewertung, Mobilisierung, die Migrationen selbst und Modernisierung umfasst, wobei jede Phase auf der vorherigen Phase aufbaut. Blaupausen, Leitfäden und Muster helfen, die gesamte Migrationsreise zu optimieren und zu beschleunigen. Trotzdem nehmen gut integrierte Werkzeuge einem viel Arbeit ab und helfen, frühzeitig Probleme zu erkennen und passende Lösungen zu finden. Eine gute Lösung für AWS ist hier zum Beispiel die Cloud Migration Factory [AWSMIGFAC], die unter einer Oberfläche und mit einer CloudFormation eine komplette Orchestrierungs-Plattform für einen Hostwechsel (Rehost, Replatform) von Servern nach AWS umfasst, um die Prozesse bei der Migration im AWS Migration Hub zu koordinieren und zu automatisieren.

Für jedes Anwendungscluster wird der passende Migrationstyp festgelegt. Nach der vollständigen Inventarisierung der Komponenten des Anwendungsclusters wird ein Business Case mit Kosten und Einsparungspotenzial berechnet und ein passender Migrationsplan erstellt, wie in Abbildung 6 dargestellt.

Abb. 6: Von der Anwendungsanalyse zum individuellen Cloud-Migrationsplan

Auf den Weg machen

Der Weg in die Cloud ist heute nicht mehr so steinig. Inzwischen gibt es genügend Erfahrungen, Vorgehensweisen und Werkzeuge, die helfen, auftretende Klippen frühzeitig zu erkennen und zu umgehen. Um einen für seine Anwendungen passenden Migrationsplan zu entwickeln, helfen umfassende und aktuelle Informationen, die Risiken und Möglichkeiten besser einzuschätzen.

Viele der auftretenden Schritte lassen sich automatisieren. Dadurch ist ein Wechsel auf modernere Plattformen und gemanagte Dienste einfacher möglich. Um das volle Potenzial der Cloud hinsichtlich Elastizität und Innovation nutzen zu können, wird man mittelfristig nicht daran vorbei kommen, seine Anwendungen Cloud-native zu gestalten. Denn nach der Migration ist vor der Modernisierung. Eine Reise in die Cloud endet nie. Es kann, im Sinne einer Multi-Cloud-Strategie, sein, dass die Reisemöglichkeiten sogar eher noch zunehmen. Wir wünschen viel Erfolg und gutes Geleit dabei.