Tipps für die Migration von Anwendungen in die Cloud

Sinkender Kosten für Cloud-Computing und von Hybrid-Cloud-Infrastrukturen sind das Argument: Viele Unternehmen wollen ihre Anwendungen in die Cloud migrieren. Allerdings ist das konkrete Vorgehen oft noch weitgehend unklar. Experten für Cloud Data Management haben deshalb notwendige Schritte, Aspekte und Fragestellungen zusammengefasst, die Unternehmen als Leitlinien dienen sollen.

Grundsätzlich gibt es eine Vielzahl von Gründen, warum Unternehmen die Migration von Anwendungen in die Cloud anstreben:

• Potenzielle Kosteneinsparungen
• Anwendungsfälle der Notfallwiederherstellung (Disaster Recovery)
• Anpassung oder Modernisierung von Anwendungen
• Zugriff auf Ressourcen
• Integration mit SaaS-Plattformen oder neuen Cloud-basierten Tools (z.B. Amazon RDS, Azure App Services und Google Cloud Spanner)

Es gibt verschiedene Konzepte und Anforderungen, die für die Migration einer Anwendung von einem lokalen Rechenzentrum an einen anderen Standort erforderlich sind. Dieser sekundäre Standort ist in der Regel ein Cloud-Provider, aber viele der Konzepte gelten für die Migration zu einem Disaster-Recovery-Standort oder sogar zu einem Entwickler-Laptop. In diesem Beispiel wird eine der gängigsten dreistufigen Anwendungen herangezogen: WordPress. Die folgende Abbildung beschreibt die Komponenten der Anwendung. Anwendungen können komplex sein. Angefangen von der Dokumentation bis hin zur Integration mit Geschäftsprozessen, gibt es einige Hausaufgaben zu erledigen. Alle Aspekte der Anwendung gilt es zu dokumentieren und vollständig zu verstehen, einschließlich:

• Plattform
• Anwendungszustand
• Datenformat und -speicherung
• Vernetzung
• Sicherheit und Governance
  

Der erste Schritt ist das Verständnis der Anwendungsplattform. Zwei grundlegende Fragen, die man sich stellen könnte, wären:

• Läuft die Anwendung auf einem dedizierten Bare-Metal-Server, auf einer VM oder in einem Docker-Container?
• Welcher Hypervisor wird für die Virtualisierung verwendet?

Jedes dieser Szenarien stellt bei der Migration einen anderen „Weg“ dar. Das WordPress-Beispiel besteht aus VMware-basierten VMs, was eine kleine Herausforderung darstellt, wenn wir sie aufgrund von Hypervisor-Inkompatibilität zu einem großen Cloud-Anbieter (z.B. AWS, GCP oder Azure) verschieben wollen. Dies wird typischerweise als „Lift and Shift“-Ansatz bezeichnet. Es steht eine Reihe von Tool-Sets zur Verfügung, um bestehende VMs in das Format des gewählten Anbieters zu konvertieren. Es gilt die Dokumentation für diese Tools gründlich zu durchdenken und auf einige Versuche vorbereitet zu sein.

Anwendungszustand 

Das nächste wichtige Prinzip ist der Anwendungszustand. Dieser hat je nach Anwendungsverhalten oder Framework unterschiedliche Definitionen, steht aber im Allgemeinen für die Orte, an denen die Anwendung Informationen speichert. Der Status kann eine Reihe von Dingen darstellen: Konfigurationseinstellungen, Inhalt des Warenkorbs, Produktbestellungen oder ein Blogbeitrag und Kommentare. Ohne diese Daten ist die Anwendung wie eine leere Tabelle mit geringem Wert. Diese Daten müssen zusammen mit der Anwendung übertragen werden, sonst fängt man bei Null an. Häufig, wie beim WordPress-Beispiel, wird der Zustand in einer Datenbank vorgehalten.

Datenbanken nutzen verschiedene Methoden, um zustandsbehaftete Daten zu verschieben (z.B. Replikation, Backup/Restore), so dass die Methode zu wählen ist, die am besten zum Anwendungsfall passt. Für unser WordPress-Beispiel werden Snapshot-basierte Backups über Copy Data Management eingesetzt. Dies kann für Datenbanken problematisch sein, da ein Snapshot mitten unter dem Schreiben erstellt werden kann, was bei der Wiederherstellung zu einer nicht funktionierenden Datenbank führen kann. Dieses Konzept wird auch als „Backup-Konsistenz“ oder „Snapshot-Konsistenz“ bezeichnet und ist besonders wichtig zu verstehen, wenn eine Snapshot-basierte Sicherungsmethode verwendet wird.

Um konsistente Backups für zustandsabhängige Anwendungen wie Datenbanken zu erhalten, muss möglicherweise ein Agent auf dem Betriebssystem installiert werden oder es werden Pre- und Post-Snapshot-Skripte verwendet. Dieses Prinzip gilt sowohl für Storage-Array-basierte Snapshots als auch für VM-basierte Snapshots. Eine Möglichkeit, dies zu beheben, besteht darin, ein Pre-Snapshot-Skript zum Sperren der Datenbanktabellen und ein Post-Snapshot-Skript zum Entsperren zu verwenden. Dies ist eine praktikable Lösung für eine einfache MariaDB-Datenbank, aber es gibt auch anwendungsfähige Sicherungsmethoden für gängige Unternehmensdatenbanken wie Microsoft SQL und Oracle, um dieses Problem zu lösen.  Sobald ein Verständnis für die Anwendung und deren Zustand entwickelt wurde, ist es an der Zeit, sich die „Masse“ Ihrer Anwendung anzusehen.

• Wie viele Daten müssen mit der Anwendung übertragen werden?
• Wie hoch sind die Kosten für Konnektivität und Speicherkosten für Migration und Betrieb?
• Müssen alle Daten verschoben werden oder reicht eine Teilmenge aus?

Diese Berechnungen helfen, den Aufwand für das Verschieben der Anwendung zu ermitteln und wie viel es kosten wird, wenn sie verschoben wird. Ein weiteres zu berücksichtigendes Konzept ist das der „Datengravitation“. Dies steht im Zusammenhang mit der Vorstellung, dass Daten Masse haben. Mit zunehmender Datenmenge werden zusätzliche Anwendungen und Services angezogen, die immer schwieriger zu bewegen sind. Zu bedenken ist, dass das Verschieben einer kritischen Geschäftsanwendung mit jahrelang gesammelten wichtigen Daten über mehrere verwandte Anwendungen hinweggehen kann, die darauf angewiesen sind. Es ist vielleicht möglich, einige Anwendungen an verschiedenen Orten aufzubewahren, auch wenn sie auf dieselben Daten angewiesen sind, aber dies verursacht Kosten, ganz zu schweigen von der zusätzlichen Komplexität. 

Vernetzung

Betrachtet man das WordPress-Beispiel, das eine sehr einfache und unkomplizierte Netzwerkinstallation darstellt. Im Gegensatz dazu stehen Legacy-Anwendungen, die aus Dutzenden oder Hunderten von Servern oder Anwendungen ohne gut dokumentierte TCP/UDP-Portnutzung bestehen. Es ist offensichtlich, dass die Planung, um eine große oder schlecht dokumentierte Anwendung zu verschieben, schnell außer Kontrolle geraten kann. So ist ein solides Verständnis dafür nötig, wie die Anwendung kommuniziert und welche Ports sie zur Kommunikation verwendet. Wenn Netzwerkgeräte im Einsatz sind, wie z.B. Load Balancer, sollte geprüft werden, wie eng sie mit der Anwendung gekoppelt sind und ob es einen praktikablen Ersatz am Zielort für die Anwendung gibt. Das letzte Stück dieses Puzzles ist Sicherheit und Compliance:

• Gibt es irgendwelche Data-Governance-Gesetze oder Compliance-Vorschriften, die für die Anwendung oder deren Daten gelten? Wenn ja, kann dies zu Einschränkungen führen, wo die Anwendung ausgeführt werden kann.
• Gibt es eine klar definierte Sicherheitsrichtlinie für die Anwendung? Wenn nicht, sollte dies sofort nachgeholt werden.

Dieses Dokument sollte alle Sicherheitsanforderungen für die Anwendung definieren, einschließlich Authentifizierung, Autorisierung, rollenbasierte Zugriffskontrolle, Firewall-Regeln und Verschlüsselungsanforderungen. Wenn es eine bestehende Richtlinie gibt, ist festzulegen, was geändert werden muss, wenn die Anwendung verschoben wird. Es ist anzumerken, dass die Durchsetzung von Sicherheitsrichtlinien innerhalb eines Cloud-Providers ein hohes Maß an Recherche und Planung erfordert.

Empfehlenswert ist es, sich zu Beginn des Planungsprozesses mit den Sicherheits- und Compliance-Teams abzustimmen. Diese werden es zu schätzen wissen, von Anfang an Teil des Projekts zu sein, und können für die Planung wertvolle Ratschläge beisteuern. Niemand will Zeit in die Planung einer Anwendungsmigration stecken, nur um sie aus Sicherheits- oder Compliance-Gründen abzubrechen.

Die Migrationsdestination verstehen 

Was den Aufwand betrifft, wird es immer einfacher sein, eine Anwendung an ein Ziel zu migrieren, das einen ähnlichen Technologie-Stack verwendet als einen, der sich deutlich unterscheidet. Das vorliegende WordPress-Beispiel, das in VMware läuft, stellt ein Problem dar, da keiner der großen Cloud-Anbieter einen VMware-Hypervisor in seinem nativen Computing-Angebot betreibt. Dies kann dazu führen, dass der Anwendungsbesitzer einen der vielen kleineren Anbieter, die so etwas anbieten, oder in großen Anwendungsfällen VMware Cloud auf AWS in Betracht ziehen muss. Die großen Clouds bieten attraktive Preise, Konnektivität und Add-On-Services, so dass es sich oft lohnt, den Wechsel vorzunehmen, aber es gibt einige Dinge zu beachten.

Die Migration von VMs in die Cloud ist ein einfacher Weg, um sich mit der Oberfläche und den Tools vertraut zu machen, aber in einigen Fällen wird man gezwungen sein, „Cloud-native“ Prinzipien zu übernehmen. Cloud-native Anwendungen werden von Grund auf neu entwickelt, um die Vorteile von Cloud-Computing-Funktionen zu nutzen, und basieren in der Regel teilweise oder ganz auf der Zwölf-Faktor-Anwendungsmethodik für webbasierte Anwendungen. Ein vollständiges Refactoring der Anwendung auf eine Cloud-native Architektur ist eine Option für die Migration, kann aber aus zeitlichen oder finanziellen Gründen nicht möglich sein. Im Rahmen der Migration der VMs kann man damit beginnen, einige Cloud-basierte Prinzipien im eigenen Tempo zu übernehmen.

Die erste große Veränderung

Die erste große Veränderung für die meisten Unternehmen ist die Umstellung von VMs mit statisch zugewiesenen IP-Adressen auf dynamische Adressen, die über DHCP zugewiesen werden. Das bedeutet, dass DNS-Einträge verwendet werden müssen, um sich mit VMs und Diensten zu verbinden. Die großen Cloud-Anbieter machen dies so einfach wie möglich, indem sie DNS-Einträge für VMs sowie verwaltete DNS-Angebote generieren, die programmgesteuert über die API verwaltet werden können.

In einer traditionellen Umgebung ist es normalerweise kein Problem, eine IP-Adresse in den Konfigurationsdateien für MariaDB, WordPress oder NGINX fest zu codieren. Das ist genau das, was in diesem Beispiel erfolgt ist, als WordPress im Labor konfiguriert wurde. Bei der Migration der VMs zu AWS wurden die Konfigurationsdateien angepasst, um die für jede VM erstellten DNS-Einträge zu verwenden, und sie funktionierten genau wie erwartet. Die folgenden Diagramme stellen eine vereinfachte Darstellung der VMs vor und nach der Migration dar. Für eine große Produktionsumgebung ist dies ein perfekter Anwendungsfall, um die Automatisierung zu nutzen. So können Sie beispielsweise programmgesteuert DNS-Einträge erstellen, die auf Ihre Cloud-basierten VMs verweisen. Hätte man DNS überhaupt verwendet und so gestaltet, dass die Hostnamen m Labor und AWS gleich sind, wären keine Konfigurationsänderungen erforderlich gewesen. Letztendlich ist DNS eine viel flexiblere Lösung als fest programmierte IPs, erfordert aber zusätzliche Planung.

Netzwerkplanung und -überlegungen

Netzwerkkonfigurationen wie Routing, Firewall-Regeln, Network Address Translation (NAT), VPNs und Load Balancing erfordern ein gutes Stück Planung, um sicherzustellen, dass sie den Geschäftsanforderungen entsprechen. Alle notwendigen Teile sind verfügbar, aber die Implementierung wird anders aussehen und sich anders anfühlen als in einer traditionellen Umgebung. Cloud-Provider-Netzwerke sind vollständig softwaredefiniert, so dass es keine zentrale Firewall oder Load Balancer zu konfigurieren gibt. Dies bedeutet auch, dass die Menge der Ressourcen, die verbraucht werden können, in Bezug auf Netzwerk-Präfix-Routen, öffentliche IP-Adressen, VPN-Tunnel etc. begrenzt ist. Daher sollte man die vom Cloud-Anbieter vorgegebenen Limits kennen und wissen, welche Maßnahmen zu ergreifen sind, wenn man das Limit erhöhen muss. Manchmal kann dies mit einem API-Aufruf erreicht werden, aber in anderen Fällen muss man ein Supportticket öffnen.

Sobald die VMs migriert und verschiedene Netzwerk- und Sicherheitsfunktionen konfiguriert sind, gelangt man an eine Weggabelung. Es ist möglich, die Anwendung in der Cloud so zu belassen, wie sie ist, oder mit der Evaluierung zusätzlicher Dienste des Anbieters beginnen, um Geld zu sparen oder den Verwaltungsaufwand zu reduzieren. Datenbanken sind ein gutes Beispiel für einen Cloud-Service, der es wert ist, in Betracht gezogen zu werden. Warum sollte man MariaDB in einer VM laufen lassen, wenn man die Daten zu geringeren Kosten in eine kompatible verwaltete Datenbank importieren kann? Dies ist ein Beispiel für viele ähnliche Dienste, die in den großen Clouds verfügbar sind.

Weniger Aufwand 

Dieser Beitrag hat einige wichtige Punkte hervorgehoben, die bei der Migration von Anwendungen zu beachten sind, und es mangelt dabei nicht an schwierigen Problemen, die zu lösen sind. Cloud Data Management kann auf elegante Weise einen Großteil dieser Probleme lösen. Nachdem auch andere Methoden zur Migration von VMs zu einem Cloud-Provider verwendet werden können, fiel die Entscheidung hier für Rubrik CloudOn, um eine WordPress-Anwendung auf AWS zu migrieren. Abgesehen von den oben genannten Änderungen an der Konfigurationsdatei hätte es nicht einfacher sein können. Die VMs wurden dem entsprechenden SLA hinzugefügt und die Cloud-Konvertierung aktiviert. Nachdem die Snapshots auf AWS repliziert und die Konvertierung von VMware VM zu Amazon AMI abgeschlossen war, ließ sich jede VM problemlos in der AWS Virtual Private Cloud starten. Dies ist eine gute Option für Unternehmen, die einen praktikablen Weg in die Cloud suchen.

Der entscheidende Ansatz ist, die betreffende Anwendung und die Änderungen, die erforderlich sind, um sie in die Cloud zu verschieben, zu verstehen. In Kombination mit der umfassenden Automatisierung und den Ressourcen von Rubrik Build lässt sich eine maßgeschneiderte Lösung entwickeln.

Rubrik (fah)