Andreas Zitzelsberger 25. Januar 2022

Cloud-Migration: Eine Strategie, die funktioniert

Wenn die Cloud-Technologie erst einmal beherrscht wird, dann will niemand mehr zurück. © Adobe: Romolo Tavani / stock.adobe.com / 420133164 — © Adobe: Romolo Tavani

Die Cloud lockt mit großen Versprechen: Einfacher und schneller soll alles werden, stabiler und sicherer. Mit einer zeitgemäßen Developer- und Operations-Experience. Eine moderne BizSecDevOps-Organisation wird ermöglicht. Und natürlich soll es billiger werden. Kurzum, die Cloud ist ein Hype. Aber ein Hype, der – wie ich bezeugen kann – seine Versprechen tatsächlich einlösen kann. Dorthin zu kommen kann aber anspruchsvoll sein und auf dem Weg lauern sehr reale Gefahren.

Die erste große Gefahr ist Stuck-in-PoC. So bezeichnet man den Zustand, wenn ein paar kleine Dinge in der Cloud laufen (der PoC), aber der Rest nicht vorankommt. Aus allen möglichen Gründen: Grabenkämpfende Silos, fehlende Skills, fehlender Wille, Sicherheits- und Compliance-Bedenken. Die zweite große Gefahr ist, mit voller Fahrt in das Cloud-Maturity-Messer zu laufen: Dies kann der Fall sein wenn man alles frohgemut in Container packt, ohne sich um Qualität zu kümmern, Prozesse so lässt, wie sie sind und dann mit verfehlten Zielen und schier unlösbar scheinenden Problemen im Betrieb konfrontiert zu sein. Die dritte große Gefahr ist, dass dem Migrationsprojekt mittendrin der Geldhahn zugedreht wird. Weil Transparenz gefehlt hat, die Kosten zu hoch werden, der Nutzen nicht klar ist oder sich die Prioritäten geändert haben.

In diesem Artikel stelle ich eine Migrationsstrategie vor, die diese Gefahren direkt adressiert und die wir in einem großen Migrationsprogramm mit hunderten Anwendungen erfolgreich gelebt haben. Die Kapitel in diesem Artikel sind grob nach Zeit sortiert, sollten aber nicht als strikt sequenzielle Phasen aufgefasst werden, sondern als ineinandergreifende und aufeinander einzahlende Aktivitäten in einer erfolgreichen Cloud-Migration.

Transparenz schaffen mit sorgfältiger Analyse

Für eine erfolgreiche Migration werden verlässliche Informationen über das zu migrierende Portfolio sowohl in der Breite als auch in der Tiefe benötigt. Das ist eine größere Herausforderung als man annehmen könnte, denn bestehende Werkzeuge sind entweder auf Breite oder Tiefe ausgelegt, nicht auf beides. Daneben gibt es Fragestellungen, für die es keine Werkzeugunterstützung gibt.

Die Analyse schafft die Grundlage für eine robuste Bottom-up-Bewertung der Aufwände und Risiken in der Migration und ermöglicht so eine seriöse Planung der Migrationen sowie die rechtzeitige Identifikation möglicher Problemquellen.

Für eine Migration wichtige Fragestellungen sind:

Welche Anwendungen sind im Portfolio? Dazu gehört auch die Klärung, wie eine Anwendung für die Migration definiert wird. Was im EAM als Anwendung hinterlegt ist? Eine technische Anwendung etwa in Form eines Java Enterprise (JEE) Application Archive (EAR)? Der Verantwortungskreis eines Teams? Wichtig ist, dass nichts hinten runter fällt. So könnte es etwa technische Anwendungen geben, die bisher durch ein Infrastrukturteam gepflegt wurden und nicht im EAM erfasst sind.

Wie kompliziert sind die Anwendungen? Hier gibt es etliche Kenngrößen, die erhoben werden können: Lines-of-Code, Change-Dichte (Changes/Zeit), Nutzerzahlen, Teamgrößen, eingesetzte Technologien, Pflegestand, Qualitätskennzahlen wie Testquote und SonarQube-Findings, Sicherheits-Metriken wie Anzahl der Findings eines Security-Scanners oder auch von den Verantwortlichen und Entwicklern abgefragt, wie sie die Anwendung qualitativ einschätzen. Gerade letzteres kann sehr erhellend sein.

Welche Technologien werden eingesetzt? Toxische Technologien, also Technologien, die nicht mehr gewartet werden können, müssen identifiziert werden. Genauso Technologien, die eine Migration in eine Container-Umgebung verhindern könnten, z. B. Legacy-Netzwerkprotokolle, die dynamische Ports verwenden, oder Spezial-Hardware wie Dongles. Diese Frage hilft auch herauszufinden, welche Technologien zentral migriert werden sollten, und welche Anwendungen in Eigenregie übernehmen müssen. Wichtig hier: High-level reicht nicht. Es muss jede FOSS-Komponente, jedes Netzwerkprotokoll und alles weitere erfasst werden.

Wie sind die Beziehungen und welche Abhängigkeiten gibt es? Es geht einerseits um Beziehungen in der Anwendungslandschaft selbst, als auch zu anderen Anwendungen innerhalb und außerhalb des Unternehmens. Der Abhängigkeitsgraph ist wichtig für die Gestaltung der Landing Zones, die Aufplanung der Migrationen (Abhängigkeiten müssen in der richtigen Reihenfolge abgearbeitet werden) und für die Identifikation wichtiger Migrationsarbeiten. Kleine Details wie eine neue TLS-Version in der Cloud-Infrastruktur, die von der On-Premise Legacy (noch) nicht unterstützt wird, können gewaltige Auswirkungen haben, wenn sie nicht rechtzeitig erkannt und gelöst werden.

Wer sind die Stakeholder? Hier muss der erweiterte Impact-Kreis der Migration identifiziert werden. Einerseits die technisch und fachliche Verantwortlichen für die Anwendungen und ihre Organisationen, die Verantwortlichen für alte und neue Infrastruktur, andererseits aber auch Dritte wie interne und externe Partner sowie die für die Migration verantwortliche Organisation.

In der Praxis hat sich ein Single-Source-of-Truth-Ansatz bewährt. Diverse Informationsquellen werden angebunden und in einer zentralen Datenbank konsolidiert, die sowohl mit Berichten und Statistiken Planung und Steuerung unterstützt als auch explorative Analysen ermöglicht und so Reaktionsfähigkeit während der Migration sicherstellt (s. Abb. 1).

Abb. 1: Wir haben eine Graph-Datenbank als Single-Source-of-Truth verwendet. © QAware

In bereits vorhandener Enterprise-Architecture-Management-Software (EAM) findet man üblicherweise Informationen über Verantwortlichkeiten, Ansprechpartner und grobe Informationen zu Abhängigkeiten und Technik. Zeitgemäße EAM-Werkzeuge haben APIs, die sich direkt anbinden lassen. Nach meiner Erfahrung haben EAM-Systeme den Nachteil allen Papiers: Sie sind geduldig. Die dort abgelegten Informationen sind oft nicht aktuell und taugen hauptsächlich als erster Einstieg. Werkzeuge zur dynamischen und statischen Analyse helfen, automatisiert auch eine große Zahl an Anwendungen sinnvoll zu vermessen. Nützlich sind etwa SonarQube zur Ermittlung von Qualitätskennzahlen, sloccount o. ä. für Größenkennzahlen oder der OWASP-Scanner, um eine Einschätzung zu Sicherheit und Wartungsstand zu gewinnen [1]. Wir haben auch sehr gute Erfahrungen mit strukturierten Fragebögen gemacht, die Verantwortliche und Teams in Eigenregie mit wenig Aufwand ausfüllen können. Hier ist eine Nachverarbeitung notwendig, um qualitative Aussagen vergleichbar zu machen. Für Daten, für die es keine Werkzeugunterstützung gibt, ist es sinnvoll, die Möglichkeit zum Import von Excel-Dateien zu haben. Etwa für die strukturierte Erfassung von Ergebnissen aus persönlichen Gesprächen.

Zusätzlich zur Analyse ist es wichtig, Pilot-Migrationen durchzuführen, um Erfahrungen zu sammeln und Kennzahlen zu bekommen, die mit den Informationen aus der Single-Source-of-Truth hochgerechnet werden können. Empfehlenswert ist hier eine kleine Auswahl an repräsentativen Anwendungen, z. B. eine besonders große und komplizierte Anwendung, eine kleine und einfache Anwendung und eine typische Anwendung. Bei den Pilot-Migrationen ist es ausdrücklich erlaubt, Abkürzungen zu nehmen, etwa um noch unfertige Teile in den Landing Zones zu umschiffen. Wichtig ist, dass die Aktivitäten sauber erfasst und ausgelassenes geschätzt wird.

Für Alignment in der Organisation sorgen

Abb. 2: Erwartete Vorteile einer Cloud-Migration, Prozentsatz der Nennungen, Mehrfachnennungen möglich. Quelle: IDG Cloud Migration Studie 2021 [2]

An dieser Stelle ist es wichtig, über das Warum – also die Ziele – zu sprechen. Die IDG Cloud Migration Studie 2021 gibt in Abb. 2 einen Überblick über typische Ziele einer Cloud-Migration [2]. Für die eigentliche Migration kann es ebenfalls ein wichtiges Ziel sein, einen gesteckten Kosten- und Zeitrahmen einzuhalten.

Welche Ziele auch immer Sie verfolgen, wichtig ist, sie sauber zu priorisieren und zu kommunizieren. Und sie nicht als reinen Top-Down-Prozess entstehen zu lassen, sondern "Alignment" (Ausrichtung) mit den Stakeholdern und Management herzustellen. Alle sollten am selben Strang ziehen. Dafür ist es essenziell, dass die Ziele glaubwürdig und Bottom-up validiert erreichbar sind. Das bedeutet, dass der Prozess der Zielfindung und Priorisierung mit dem Herstellen von Transparenz Hand in Hand geht. Die Zielerreichung sollte durch geeignete Metriken unterfüttert werden, um den Mehrwert der Migration auch greifbar zu machen. Im Folgenden finden sie einige Vorschläge für Metriken.

Lead Time For Changes: Zeit zwischen Commit eines Changes und Freigabe für Produktion.
Change Failure Rate: Anteil an Changes, die eine Korrektur in Produktion erfordern.
Deployment Frequency: Häufigkeit von Produktions-Deployments.
Mean Time to Recovery (MTTR): Lösungszeit für Fehler in Produktion.
Availability: Totale Verfügbarkeit der Anwendung.
Defect Escape Rate: Anteil der Qualitätsprobleme, die in Produktion sichtbar werden.
Mean Turn-Around Time: Zeit zwischen Anforderung und Umsetzung, inklusive Prozess.
Cycle time: Zeit zwischen Commit und Deployment in Produktion.
From-Scratch Turn-Around Time: Minimale Zeit, die es braucht, um eine neue Anwendung in Produktion zu bringen, unter Einhaltung aller Prozesse.
Anzahl toxischer (nicht gewarteter) Abhängigkeiten.
Anzahl Sicherheitsvorfälle/ Zeit.

Noch mehr Metriken finden sich in "Data-driven DevOps: Use Metrics to Guide Your Journey" von Gartner Research [3].

Der Wandel gelingt mit den Mitarbeiter:innen, nicht gegen sie.

Neben Zielen, Stakeholdern und Metriken ist es wichtig, die Kolleg:innen mitzunehmen. Je nachdem wo ihre Organisation steht, kann eine Cloud-Migration große Veränderungen mit sich bringen. Der Wandel gelingt mit den Mitarbeiter:innen, nicht gegen sie. Die nötigen Skills und Erfahrungen mit der Cloud-Technologie und neuen Vorgehen müssen aufgebaut werden, gleichzeitig Ängste und Zweifel auch während der Migration überwunden werden. Es braucht Sicherheit, dass die Migration auch funktionieren wird und Transparenz darüber, wie der Weg sich gestaltet. Das geht nur mit einem Bottom-up validierten, glaubwürdigen und erreichbarem Ziel.

Ein flankierendes Schulungsprogramm kann eine gute Idee sein. Genauso, während der Migration Code-Fests oder Code-Camps zu veranstalten, in denen Themen gemeinsam bearbeitet werden. Man muss sich aber darüber im Klaren sein, dass der Wandel nur dann über die Migration hinaus nachhaltig ist, wenn auch nachgehalten wird und die Organisation sich in Richtung einer Lernorganisation bewegt.

Architektur und Blueprint

Für eine effektive und effiziente Migration ist einiges an Architekturarbeit notwendig. Landing Zones müssen definiert und gestaltet werden. Die Migrationsarchitektur und Blueprint für die Anwendungsmigrationen muss festlegt werden. Compliance muss sichergestellt werden. Und wir wollen bestmögliche Sicherheit ohne Prozess-Entschleunigung und ohne Frustelemente.

In der DevOps-Praxis hat es sich bewährt, einen Schnitt zwischen Zielplattform und Anwendungen und somit auch der Anwendungsmigration zu machen. Die Plattform wird von einem spezialisierten Infrastructure-Engineering-Team (CloudOps) verantwortet. Das hat den Vorteil, dass die Anwendungsteams DevOps mit einem hohen Service-Level betreiben können. Die Landing Zones fallen dann in den Verantwortungsbereich des CloudOps-Teams. Die enge Zusammenarbeit mit dem Migrationsprogramm ist erfolgskritisch.

Die Migration-Architektur sollte zentral bearbeitet werden und den Anwendungsteams in Form eines gemeinsamen Blueprints zur Verfügung gestellt werden. Der Blueprint beantwortet die wesentlichen Architekturfragen in der Migration:

Aufgabenstellung,
Ausgangssituation,
Migrationsstrategie,
Zielbild,
Entwicklungsrichtlinien,
Lösungsbausteine und
Lösungsstrategien.

Der Blueprint schafft Transparenz, steckt einen Rahmen ab, bietet den Anwendungsmigrationen ganz konkrete Vorlagen und bietet noch einen ganz wesentlichen Vorteil: Machbarkeit, Sicherheit, Compliance und die Passung zur strategischen Enterprise-Architektur muss nur einmal bearbeitet werden. Die notwendige Abstimmungs- und Gremienarbeit findet nur einmal statt, die Prozesse für einzelne Anwendungen verkürzen sich stark. Beim Blueprint ist die Haltung wichtig. Nicht ein feingliedriges Architektur-Korsett schaffen, sondern Leitplanken und Vorlagen, die effektive Anwendung-Migrationen ermöglichen.

Compliance ist eines der schwierigsten Themen bei Cloud-Migrationen, besonders in stark regulierten Unternehmen wie z. B. in der Finanz- oder Versicherungsbranche. Eine detaillierte Betrachtung sprengt den Artikel, aber ich möchte ein paar Beispiel für Regulierungen geben, die erhebliche Auswirkungen auf eine Migration haben können: Fast jede Migration ist vom Schutz personenbezogener Daten durch GDPR und DSGVO betroffen. Vorgeschrieben ist ein Schutzniveau auf dem Stand der Technik sowie diverse anwendungsseitig umzusetzende Regeln wie die Möglichkeit zum Löschen von Daten.

Größere, "systemrelevante" Unternehmen fallen meist unter die breit gefasste KRITIS-Regulierung, die den Schutz der Bevölkerung als Ziel hat. Eine wichtige Folge für Cloud-Migrationen ist, dass zur Aufrechterhaltung des Geschäftsbetriebs in betroffenen Unternehmen Maßnahmen nötig sind. Dazu kann der Betrieb in mehreren Availability Zones gehören wie auch mindestens eine glaubwürdige Vendor-Exit-Strategie, wenn nicht eine Multi-Cloud-Strategie.

Es kann hier besonders bei großen Installationen eine gute Idee sein, einen "Abstandshalter" zwischen Anwendungen und Cloud zu nutzen. Also eine Menge von infrastruktur-unabhängigen Plattform-Diensten, die die Anwendungen von der Cloud-Infrastruktur isolieren und die Abhängigkeit zum Infrastruktur-Provider reduzieren. Kubernetes hat sich als Plattform für Plattformen hier als provider-übergreifender Standard etabliert.

In der Versicherungsbranche gibt es spezielle Regularien. So ist Outsourcing streng reguliert und oft meldepflichtig (§ 32 VAG) und sogenannte Privatgeheimnisse stehen unter besonderem strafrechtlichen Schutz (§ 203 StGB). Beides muss berücksichtigt werden, der Verlust der Vertraulichkeit einer Krankenakte ist doch etwas anderes als der einer E-Mail-Adresse.

Bei der Sicherheit muss man wahrnehmen, dass sich die Bedrohungslage in der Cloud im Vergleich zu On Premise verschiebt. Innentaten, ob absichtlich oder unabsichtlich, sowie laterale Bewegungen von Angreifern rücken deutlich mehr in den Vordergrund.

Ein durchgängiger Zero-Trust-Ansatz passt sehr gut auf die Bedrohungslage in der Cloud und datenschutz-getriebene Anforderungen. Zero Trust bedeutet: Vertraue niemand, nirgendwo, keinem Nutzer, Gerät oder Dienst, auch nicht innerhalb der Infrastruktur, verifiziere jeden und vergib nur die Berechtigungen, die zur Erfüllung der Aufgabe notwendig sind [4].

Eine zweite wichtige Säule einer modernen Cloud-Sicherheitsarchitektur sind unveränderliche und reproduzierbare Infrastrukturen mit GitOps. Die Grundidee von GitOps ist, den Zustand einer Ausführungsumgebung versioniert zu pflegen und automatisiert auszurollen. Direkte Zugriffe auf die Umgebung finden nicht mehr statt. GitOps mitigiert ganze Klassen von möglichen Bedrohungen und hilft dabei, mehr Stabilität und eine bessere Developer und Operations Experience zu erreichen [5].

Acceleration als Migrationsansatz

Sobald mehr als eine Handvoll an Anwendungen migriert werden sollen, stellt sich die Frage nach dem Vorgehen in der Migration. Wir haben Acceleration als Migrationsansatz gewählt. Dahinter steht die Idee, dass die Anwendungen am effektivsten durch die Anwendungsteams selbst migriert werden können. Das hat eine Reihe von Vorteilen. Die Teams kennen ihre Anwendung am besten. Sie können auch das Vorgehen im Detail am besten einschätzen. Stop-the-World für eine Anwendung, oder besser doch Migrieren parallel zur Feature-Entwicklung? Sie nehmen in der Migration gleich das Wissen auf, dass sie zukünftig für Betrieb und Wartung der Anwendungen brauchen. Die Migration kann ohne Bottleneck über eine ganze Organisation skaliert werden. In der Praxis gibt es dabei mehrere Herausforderungen, die adressiert werden müssen.

Die Gesamtmigration muss zentral gesteuert werden – nicht zuletzt, um Geld zu akquirieren, zu verteilen und Fortschritt zu berichten. Genauso müssen Abhängigkeiten außerhalb des Migrationsprogrammes einbezogen werden, wie z. B. der Fortschritt bei den Landing Zones.

Die Skills in den Anwendungsteams sind oft sehr heterogen. Es kann nicht erwartet werden, dass die Kolleg:innen aus dem Stand mit neuen Technologien und Vorgehen effektiv sind. Die Anwendungsteams brauchen also mehr oder weniger intensive Unterstützung während der Migration, ggf. flankiert durch ein Schulungsprogramm.

Es gibt viele Gleichteile zwischen den Anwendungsmigrationen, vielfach genutzte Werkzeuge und Halbzeuge, gleiche Arbeiten, gleiche Architekturen. Im Sinne von Geschwindigkeit, Effizienz und Qualität ist es sinnvoll, all das so gut es geht zu zentralisieren.

Die Informationen müssen fließen. Zwischen dem zentralen Team und den Anwendungsteams und zwischen den Anwendungsteams selbst. Während der Migration wird überall Neues gelernt, Probleme entdeckt, clevere Lösungen gefunden. Randbedingungen und Vorgaben können sich ändern. Die Erfahrung zeigt, dass Informationsaustausch verantwortet, gefördert und moderiert werden muss.

Abb. 3: Diese Migrations-Programmstruktur hat sich bewährt. Nicht dargestellt: Die Programmleitung. © QAware

In unserem größtem Migrationsprojekt haben wir das zentrale Team wie in Abb. 3 strukturiert:

Ein übergreifendes Programm-Management koordiniert und bindet Stakeholder ein.
Ein Architekturteam, das die Gesamtarchitektur und den Blueprint für die Anwendungsmigrationen verantwortet.
Ein Acceleration-Team, das gemeinsame Lösungen, Werk-und Halbzeuge entwickelt, den Blueprint in ein Cookbook mit konkreten Anleitungen übersetzt, auftretende Probleme löst und eng mit Architektur und Coaching zusammenarbeitet.
Ein Coaching-Team, das die Anwendungsteams Hands-On begleitet und gemeinsam mit dem Acceleration-Team Veranstaltungen wie Code-Fests durchführt.

Einige Faktoren haben besonders zum Erfolg der Acceleration-Strategie beigetragen. Wichtig ist ein Hands-on-Vorgehen und kommunikative Nähe zu den Anwendungsteams, in unserem Fall bis hin zur Co-Location während der Migration und Pair Programming. Dafür braucht es geeignete Flächen bzw. technische Lösungen für hybrid verteiltes Arbeiten. Wichtig: Damit es angenommen werden kann, muss ein solch intensives Hilfsangebot auch ein Angebot sein – keine Pflicht oder Vorgabe.

Größtmögliche Transparenz hat sich bewährt, zusammen mit einem Inner-Source-Ansatz. Der gesamte Code und alle Dokumente stehen allen an der Migration Beteiligten offen, genauso ist Status, Fortschritt und Planung jeder Anwendungsmigration allen transparent. Das ist vor allem in traditionellen silo-artigen Organisationen eine Herausforderung, zudem werden oft Sicherheitsbedenken vorgeschoben. Auch hier gilt: Sind die neuen Arbeitsweisen erst mal etabliert, möchte kaum noch jemand davon wieder weg.

Um den Informationsaustausch zu erleichtern, empfiehlt sich ein Cookbook: Ein zentrales, lebendiges Wiki-Dokument mit konkreten Anleitungen, das von allen bearbeitet werden kann. Das Cookbook wird vom zentralen Team verantwortet und vorbefüllt. Das sorgt dafür, dass sofort ein nutzen-stiftender Grundstock an Information da ist und die Hemmschwelle zum Beitragen niedrig ist.

Eine wichtige Erkenntnis aus verschiedenen Experimenten zur Teamstruktur: Klare Verantwortungsbereiche ermöglichen Ownership, intensive Kommunikation und wechselseitige Unterstützung erweckt alles zum Leben.

Cloud-friendly Migration

Für die Cloud-Migration von Anwendungen gibt es vier Grundmuster:

Lift-And-Shift	Die Software wird bis auf Konfiguration unverändert in die Cloud übertragen.
Lift-And-Extend	Die Software wird für den Betrieb auf einer Cloud-Plattform angepasst.
Hybrid Extension	Die Software verbleibt On Premise. Neue Funktionen werden in der Cloud nachgebaut. Der alte Kern On-Premise wird so Stück für Stück abgelöst, bis er entfällt (Strangler Pattern).
Full Rebuild	Anwendungen werden cloud-nativ neu gebaut.

Die Muster sollten mit einer verbindlichen Cloud Maturity Baseline verbunden werden: Ein Mindestlevel, das Anwendung erreichen müssen und sicherstellt, dass sie in der Cloud betriebsfähig sind und die Vorteile einer Cloud-Umgebung gut nutzen können (Abb. 4).

Abb. 4: Grobe Einteilung der Cloud Maturity von Anwendungen. Cloud Friendly hat sich als Baseline für die meisten Anwendungen bewährt. © QAware

Lift-and-shift sollte nur dann erste Wahl sein, wenn die zu migrierende Anwendung bereits cloud-ready, d. h. in einer Cloud-Umgebung uneingeschränkt betriebsfähig ist. Lift-and-shift aus Kostengründen ins Auge zu fassen ist ein guter Weg in den Abgrund, vor allem wenn keine ausreichende Transparenz über den Zustand und das Cloud-Maturity-Level des Portfolios besteht. Hier macht man sich etwas vor. Die Erfahrung zeigt, dass für viele Anwendungen ein gewisses Maß an Re-engineering unverzichtbar ist.

Lift-and-shift aus Kostengründen ins Auge zu fassen ist ein guter Weg in den Abgrund.

Lift-and-shift kann dennoch in gewissen anderen Fällen notwendig sein, wenn gewichtige Ziele wie die Abschaltung eines Rechenzentrums nur so erreicht werden können und die durch Lift-and-Shift entstehenden Probleme weniger Gewicht haben.

Lift-and-extend ist das Verfahren der Wahl für Software, die wirtschaftlich angepasst werden kann. Wir haben sehr gute Erfahrungen damit gemacht, Bestandssoftware "cloud-friendly" zu machen und diese in die Lage zu versetzen, die meisten Vorteile einer Cloud-Umgebung zu nutzen, ohne den vollen Schritt zu "cloud native" zu gehen. Der Fokus bei "cloud friendly" liegt also auf dem Outcome: Sichere Anwendungen, die sich gut betreiben und anpassen lassen. In der Praxis bedeutet das, bei Stabilität und Sicherheit kompromisslos zu sein, aber nicht den vollen Weg eines Refactoring in Microservices zu gehen. Einem zukünftigen Rebuild steht nichts im Wege, nur ist dieser von der Migration entkoppelt.

Hybrid Extension bringt eine erhöhte Komplexität und einige Pferdefüße mit sich. So kann z. B. die erhöhte Latenz zwischen Daten bereitstellenden und nutzenden Systemen zu Problemen führen, besonders bei Bestandssoftware mit Qualitätsproblemen.
Hybrid Extension kann aber ein guter Weg sein, um zügig erste Schritte zu gehen und Know-how und Vertrauen in die neuen Cloud-Umgebungen aufzubauen, bevor Kernsysteme umgezogen werden.

Full Rebuild funktioniert natürlich immer – solange genügend Geld und Zeit vorhanden ist. Die Erfahrung zeigt aber, dass es meist zu teuer und langwierig ist, komplette Anwendungslandschaften neu zu bauen. Daher empfehle ich dieses Verfahren im Rahmen einer Migration nur dann, wenn Anwendungen nicht sinnvoll cloud friendly saniert werden können.

Neben diesen Migrationsmustern kommt noch ein Ersatz der Anwendung in Frage. Das kann etwa ein fertiges Produkt sein oder ein SaaS oder Business-Process-Outsourcing-Dienst. Oft ist hier aber auch die Komplexität des Vorhabens so, dass es von der Migration entkoppelt sein sollte.

Der Nachbrenner

Je nachdem wie teuer die bisherige Infrastruktur war, gibt es nach der Migration oft lange Gesichter, weil sich die anvisierten Kostenersparnisse nicht von selbst eingestellt haben. Wenn ein Kostenvergleich zwischen Alt und Neu gewünscht ist, braucht es eine gemeinsame Messgrundlage zwischen alter und neuer Infrastruktur. Faktoren wie Nutzung und Leistungsfähigkeit der Infrastruktur, Stabilität und Service Level müssen vergleichbar gerechnet werden. Ist das in der alten Infrastruktur nicht oder nicht mit vertretbaren Kosten möglich, dann sollte das allein die Notwendigkeit einer Modernisierung rechtfertigen.

In jedem Fall gilt: Die Kosten sinken nicht automatisch. Das hat vorwiegend den Grund, dass während der Migration defensiv überprovisioniert wird und Möglichkeiten zur Elastizität noch nicht genutzt werden. Und das ist aus Gründen der Stabilität auch gut so und sollte nicht verhindert werden. Es hat sich bewährt, während der Migration den Fokus auf Effektivität und Qualität zu legen, nicht auf Infrastruktur-Kosten, die sich zu Beginn nur mit hohem Risiko vermeiden lassen.

Wichtig ist ein "Cost-Control-Nachbrenner" nach der Migration. Dazu muss Kostentransparenz geschaffen werden. Welche Anwendungen verursachen welche Infrastruktur-Kosten? Im Allgemeinen muss dazu ein Modell entwickelt werden, wie Kosten geteilter oder elastischer Infrastruktur zugerechnet werden. Z. B. kann man Compute-Ressourcen einfach auf CPU und Speichernutzung umlegen. Mit dieser Transparenz ausgestattet kann nun aktiv gesteuert werden. Die Zahlen sollten den Teams selbst zur Verfügung stehen. Daneben ist es eine gute Idee, die Kosten regelmäßig zentral mit Experten zu analysieren. Oft gibt es große Hebel, die mit kleinem Aufwand bewegt werden können.

Auch für die Stabilitäts- und Performance-Ziele ist ein Nachbrenner in Form einer Hypercare-Phase eine gute Idee. Für einen begrenzten Zeitraum werden die Anwendungen eng beobachtet und betreut. Das zentrale Team hilft, Probleme zu erkennen, zu lösen und das dabei entstehende Wissen für alle zu heben.

Fazit

Der Weg in die Cloud lohnt sich. Doch um den Bestand erfolgreich in die Cloud zu migrieren und die Vorteile der Cloud zu heben, ist Arbeit und strukturiertes Vorgehen angesagt. Es braucht:

Verlässliche Transparenz über den Ist-Zustand, durch sorgfältige Analyse sowohl in der Breite als auch in der Tiefe, konsolidiert in einer Single-Source-of-Truth.
Klar definierte Ziele, eine Organisation die am selben Strang zieht und klare Kommunikation. Die Business-Sicht und die technische Basis müssen im Einklang sein.
Gute Migrations- und Zielarchitekturen und einen Blueprint für die Anwendungen.
Einen Ansatz, um die Migration über die Organisation zu skalieren.
Eine Strategie für die Anwendungsmigration. Cloud friendly hat sich bewährt.
Einen Nachbrenner der sicherstellt, dass die Kosten, Stabilitäts- und Performance-Ziele erreicht werden.

Zum Schluss noch ein Versprechen: Wenn die Cloud-Technologie erst einmal beherrscht wird, dann will niemand mehr zurück.

Quellen