Applikationen in die Public Cloud migrieren
Ab in die Wolke
Im Zeitalter sinkender Kosten für Cloud-Computing und zunehmend beliebter Hybrid-Cloud-Infrastrukturen versuchen viele Unternehmen, Bestandsanwendungen in die Public Cloud zu migrieren. Sie stehen aber vor der Frage, wie sie für ihren individuellen Fall "richtig" vorgehen sollen.
Anwendungen können komplex sein. Angefangen von der Dokumentation bis hin zur Integration mit Geschäftsprozessen gilt es, alles zu dokumentieren und vollständig zu verstehen, einschließlich Plattform, Anwendungszustand, Datenformat und -speicherung, Vernetzung sowie Sicherheit und Compliance/Governance. Zwei grundlegende Fragen stellen sich zunächst: Läuft die Anwendung auf einem dedizierten Bare-Metal-Server, auf einer VM oder in einem Docker-Container? Welcher Hypervisor findet für die Virtualisierung Verwendung?
Das nächste zu verstehende Prinzip ist der Anwendungszustand. Häufig wird der Zustand in einer Datenbank vorgehalten. Dieser umfasst zum Beispiel Konfigurationseinstellungen, den Inhalt des Warenkorbs, Produktbestellungen, Blog-Beiträge und Kommentare. Ohne diese Daten ist die Anwendung wie eine leere Tabelle und von geringem Wert. Diese Daten gilt es, zusammen mit der Anwendung zu übertragen. Datenbanken nutzen verschiedene Methoden, um zustandsbehaftete Daten zu verschieben (Replikation, Backup/Restore etc.), sodass die Methode zu wählen ist, die am besten zum Anwendungsfall passt.
Bei den Cloud-Kosten ist zu beachten, dass der Upload kostenlos ist, während der Download Geld kostet. Ein entscheidender Aspekt ist auch die Zeit für die Übertragung der Daten in die Cloud. Gibt es genügend Bandbreite? Wie lange wird es dauern? Dies ist ein wichtiger Aspekt. Probleme können auftreten, wenn eine sogenannte "Split Application" vorliegt, also wenn sich Abhängigkeiten nicht bewegen können oder bei einer schlecht geplanten Bestandsmigration notwendige Komponenten in der On-Premises-Umgebung verbleiben.
Exit-Stragtegie muss vorab definiert sein
Bevor die Migration beginnt, sollte eine Exit-Strategie definiert und klar verstanden sein: Was bedeutet es, alle Anwendungen wieder vor Ort zu haben oder zu einem anderen Public-Cloud-Anbieter zu migrieren? Wird das überhaupt möglich sein? Insbesondere gilt das für Anwendungen, die man durch SaaS ersetzt. Dies erfordert es, für einen Zeitraum von drei Jahren, fünf Jahren oder länger zu kalkulieren. Einer der Vorteile von Cloud-Architekturen ist das Fehlen einer Anforderung, bei jeder Aktualisierung eines Storage-Arrays eine Speichermigration durchzuführen, sodass die Unternehmen alle Aspekte des Cloud-Exits gegeneinander abwiegen sollten.
Für datenintensive Anwendungen wie Analytik oder Rendering eignet sich eine Architektur optimal, die große Datenmengen in die Public Cloud aufnehmen kann und genügend Knoten bereitstellt, um die Datenverarbeitung zu handhaben, also die Daten in irgendeiner Weise zu transformieren oder zu analysieren, um dann das Ergebnis zurückzuliefern. Ein Beispiel wäre ein kleines Designbüro in teurer Innenstadtlage, das aus Platz- und Kostengründen keine umfangreichen Rechenkapazitäten vorhalten kann, wie sie für große Animations- oder Industriedesign-Projekte erforderlich wären. Daher senden die Designer die Daten zum Rendering in die Cloud.
Dieses Szenario zeigt, wie Unternehmen heute denken müssen: Wie können sich unser IT-Team und unser Business über seine Gewichtsklasse hinaus durchsetzen? Wie können wir elastische, temporäre Rechen- und Speicherressourcen der Public Cloud nutzen? Diese Überlegungen helfen, Aufwand und Kosten für die Migration der Anwendung in die Cloud zu ermitteln.
Die Schwerkraft der Daten
Ein weiterer zu berücksichtigender Aspekt nennt sich "Data Gravity" (auf Deutsch etwa: "Datenschwerkraft"). Diese Metapher behandelt Daten so, als ob sie Masse besäßen: Mit zunehmender Datenmenge werden zusätzliche Anwendungen und Services "angezogen", die immer schwieriger zu bewegen sind. Außerdem gibt es auch ältere Anwendungen, die aus Dutzenden von Servern ohne gut dokumentierte TCP/UDP-Port-Nutzung oder Abhängigkeitsketten bestehen. Das Verschieben einer solchen schlecht dokumentierten Anwendung kann schnell außer Kontrolle geraten. Hier ist solides Wissen nötig, wie die Anwendung kommuniziert und welche Ports sie dabei verwendet. Sind beispielsweise Netzwerkgeräte wie Load Balancer im Einsatz, sollte das Projektteam prüfen, wie eng sie mit der Anwendung gekoppelt sind.
Das letzte Stück dieses Puzzles bilden Sicherheit und Compliance: Niemand will Zeit in die Planung einer Anwendungsmigration stecken, nur um sie aus Sicherheits- oder Compliance-Gründen wieder abzubrechen. Hier stellen sich insbesondere mehrere Fragen: Gibt es 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 sich die Anwendung ausführen lässt? Und: Gibt es eine klar definierte Sicherheitsrichtlinie für die Anwendung? Wenn nicht, sollte man dies sofort nachholen und jede vorgeschlagene Architektur aus der Sicherheitsperspektive begutachten. Für die Migration von Bestandsapplikationen in die Cloud stehen im Wesentlichen drei Ansätze zur Verfügung: Lift and Shift, Re-Factoring und Re-Architecting mit Micro-Services.
Ansätze für den Weg in die Cloud
Beim Lift-and-Shift-Ansatz geht es darum, eine Anwendung und die damit verbundenen Daten mit minimalen oder gar ohne jegliche Änderungen in die Cloud zu migrieren. Das Projektteam "hebt" die Anwendungen aus ihren Umgebungen "heraus" ("Lift") und verschiebt sie in die Cloud ("Shift"). Die Komplexität einer Anwendung oder eines Geschäftsprozesses ist hier ein Schlüsselfaktor bei der Entscheidung, ob man Lift and Shift einsetzen oder das Ganze von Grund auf neu als native Cloud-Anwendung erstellen sollte.
In den Anfängen des Cloud Computings war Lift and Shift eine gängige Option, um lokale Anwendungen in der Cloud zu replizieren und dabei ein kostspieliges, zeitaufwändiges Redesign zu vermeiden. Viele ältere migrierte Anwendungen konnten jedoch die Kosteneffizienz nativer Cloud-Funktionen, insbesondere die automatisierte Skalierung, nicht vollständig nutzen. So vergleichen Experten Lift and Shift mittlerweile mit dem Verlagern einer Zimmerpflanze von einer Umgebung in eine andere, wo die Pflanze mitunter nicht so gut gedeiht. Zudem kann ein solches Projekt leicht aus dem Ruder laufen, gerade wenn es sich um ressourcenintensive Anwendungen handelt. Das sogenannte "Noisy Neighbor"-Problem in der Public Cloud ist besonders für geschäftskritische Anwendungen von Bedeutung, und Lift and Shift ist für dieses Phänomen am anfälligsten. Ein Unternehmen muss Anwendungen möglicherweise von Grund auf für die Cloud neu gestalten, um Performance- und Latenzprobleme zu vermeiden.
Beim Re-Factoring hingegen kommen Container und PaaS (Platform as a Service) zum Einsatz. Beispiele wäre Dienste oder Server, die in einem dynamischen Container mit nicht-persistenten Daten innerhalb des Containers selbst enthalten sind. Die ursprüngliche Anwendung wird lediglich konvertiert und zertifiziert, um auf diese Weise korrekt zu funktionieren, beispielsweise in ein NoSQL-Ziel zu schreiben. Dies erfordert keine massive Neucodierung, aber das Projektteam muss ein Template für den Container definieren und eine Verbindung zu einer Form der persistenten Speicherung herstellen, da Container naturgemäß temporär sind. Mit zu- oder abnehmenden Leistungsanforderungen lassen sich mehr Container bereitstellen oder deaktivieren. Der Vorteil dabei ist die schnelle Bereitstellung und Integration mit CI/CD-Tools (Continuous Integration/Continuous Delivery) zur Orchestrierung sowie elastische Leistungsmöglichkeiten.
Re-Factoring ist der zeitaufwändigste und ressourcenintensivste Ansatz für die Cloud-Migration bestehender Anwendungen, verspricht aber, von den Vorteilen der Cloud-Plattform optimal zu profitieren. Unternehmen, die sich für ein Re-Factoring entscheiden, können die Betriebskosten in der Cloud senken. Ein Re-Factoring kann auch notwendig sein, wenn die Leistung nach einem Lift and Shift nicht den Erwartungen entspricht, insbesondere wenn nachträgliche Anpassungen das Problem nicht lösen. Eine migrierte Anwendung kann davon auch profitieren, wenn die Kosten aufgrund von Ineffizienzen unerwartet hoch sind oder Schwachstellen auftreten.
Cloud-gerechte Architektur für Altanwendungen
Ein Re-Architecting mit Micro-Services schließlich bedeutet, die Anwendung zu überdenken, um die Vorteile der nativen Cloud-Funktionen zu nutzen oder neue Funktionen, Upgrades etc. in Teilen der Anwendung einsetzen zu können: Das Projektteam modernisiert die Anwendung vollständig. Die neue Applikation unterscheidet sich im Allgemeinen sehr von der typischen monolithischen On-Premises-Anwendung. Re-Architecting erfordert ein tiefes Verständnis der Cloud-Plattform und der Anwendung, einschließlich ihrer Funktionalität, Daten, Leistungsanforderungen und Nutzungsmuster.
Bei der Nutzung von Micro-Services teilt man große Softwareprojekte in kleinere, unabhängige und lose gekoppelte Module auf. Sie machen die Anwendung agiler, besser skalierbar und ausfallsicherer. Dieser Ansatz folgt den Designprinzipien der Service-orientierten Architektur (SOA) und gilt als deren Weiterentwicklung. Der modulare Architekturstil basiert darauf, große Softwareprojekte in kleinere, unabhängige Module zu zerlegen, und verspricht Dynamik wie auch Agilität.
Lesen Sie mehr zum Thema
