Wie überlebe ich eine Cloud-Migration?

Eine Cloud-Migration umfasst drei voneinander abhängige Ebenen: Infrastruktur, Softwarearchitektur und Organisation. Technisch beginnt sie meist mit Lift and Shift, also dem unveränderten Verlagern einer Anwendung in die Cloud, gefolgt von schrittweisem Refactoring entlang fachlicher Domänenschnitte. Ohne automatisierte CI/CD-Pipelines, Resilienz-Tests und organisatorische Veränderungen scheitert die Migration.

Das Wichtigste in Kürze

• Greenfield-Neuimplementierungen scheitern regelmäßig: Teams, die parallel zum Monolithen ein neues System entwickeln, brechen solche Projekte nach etwa zwei Jahren meist ab.
• Vor jeder Migrationsarbeit muss eine funktionierende CI/CD-Pipeline stehen, nicht danach, denn ohne Automatisierung ist ein System mit vielen Microservices und Datenbanken schlicht nicht wartbar.
• Cloud-Migration verändert Berufsbilder konkret: DBAs verlieren Aufgaben, wenn Oracle durch einen Managed-Service ersetzt wird, und Entwickler, die nur Jar-Dateien liefern, müssen ihren Verantwortungsbereich ausweiten.
• Resilienz-Tests fehlen in klassischen Testsuiten, weil Container-Ausfälle, erhöhte Latenzen und kurze Nichtverfügbarkeiten bei On-Premise-Systemen kaum auftraten, in der Cloud aber zum Normalbetrieb gehören.

Warum Unternehmen in die Cloud gehen

Drei Motive treiben die meisten Cloud-Migrationen: Kostenhoffnung, Flexibilität und der Druck, weil es alle tun. Die ersten beiden sind handfest, das dritte ist ein Hype-Effekt, der seine eigene Dynamik entwickelt.

Bei den Kosten erwarten viele, dass eigene Infrastruktur und das dazugehörige Personal wegfallen. Die Rechnung sieht auf dem Papier gut aus. In der Praxis stellt sich das Bild oft anders dar, weil neue Komplexität an anderer Stelle entsteht.

Flexibilität ist das stärkere Argument. Die großen Hyperscaler betreiben Rechenzentren über den ganzen Planeten. Wer Kunden in Australien ansprechen will, kann das nicht sinnvoll von der Schweiz oder Deutschland aus tun. Diese geografische Reichweite hat kaum eine einzelne Firma in eigener Hand.

Eine VM in der Cloud ist nur ein Rechner, der woanders steht

Technisch betrachtet ist eine virtuelle Maschine in der Cloud zunächst genau das: ein Rechner an einem anderen Ort. Diese nüchterne Sicht hilft, eine verbreitete Illusion zu zerstören, nämlich dass die Cloud die alten Probleme automatisch löst.

Beim Wechsel kommen Probleme zum Vorschein, die lokal schon immer da waren. Security, Zugriffsschutz, Update-Zyklen. Plötzlich wird die Frage relevant, wie oft eine VM gebootet wird oder wie die Day-Two-Operations bei einem Datenbanksystem oder Kubernetes-Cluster aussehen.

Diese Fragen gab es on-premise genauso. Linux-Systeme mussten auch vorher alle zwei Wochen aktualisiert werden. Die Cloud macht diese Pflichten nur sichtbar, weil sie sich nicht mehr im eigenen Rechenzentrum verstecken lassen. Genau das macht eine Migration schwierig, zusammen mit den kulturellen Themen.

Drei Baustellen: Infrastruktur, Architektur, Organisation

Jede Cloud-Migration zerfällt in drei Bereiche, und nur einer davon ist rein technisch.

• Infrastruktur: Der Weg von lokaler zu Cloud-Infrastruktur. Cloud-Anbieter stellen eine API bereit, mit der sich das relativ schnell aufsetzen lässt. Die Managed Services dahinter bringen aber eine eigene Komplexität mit, die das gesamte Vorgehen schwerer macht.
• Architektur: Lang gewachsene Monolithen sind oft schlecht gebaut. Was viele übersehen: Auch ein Monolith kann eine Architektur haben, etwa über saubere Java-Packages. Die Aufgabe besteht darin, solche Monolithen sinnvoll zu zerteilen.
• Organisation: Rund um On-Premise-Datenbanken sind über Jahre Organisationseinheiten entstanden, die nicht mehr zur neuen Welt passen. Hier geht es um Eigenverantwortung und agile Arbeitsweisen.

Wo die Hauptprobleme liegen, ist von Firma zu Firma verschieden. Banken und Versicherungen tragen besonders langlebige Systeme und ebenso langlebige Organisationen mit sich. An der schwächsten Stelle setzt man an.

Wie eine Migration schrittweise abläuft

Der sinnvolle Einstieg heißt Lift and Shift: Du nimmst die bestehende Anwendung, kontainerisierst sie eventuell und startest sie zunächst in einer Cloud-VM. Dieser erste Schritt dient vor allem dazu, Erfahrungen zu sammeln.

Darauf bauen weitere Stufen auf. Beim Re-Hosting wandert der Monolith in die Cloud, was bereits eine angelegte CI/CD-Pipeline voraussetzt. Beim Re-Platforming kommt das Ding in einen Kubernetes-Cluster, und Logging sowie Monitoring laufen über die Dienste des Cloud-Anbieters.

Erst danach folgt das Refactoring. Das ist die eigentliche Architekturfrage, bei der die Struktur verbessert wird, falls man das will. Es gibt durchaus Gründe, diesen letzten Schritt nicht zu gehen.

Greenfield-Neubauten scheitern, schrittweises Schneiden trägt

Der Versuch, einen Monolithen mit einem separaten Greenfield-Team komplett neu zu bauen, geht in der Praxis schief. Das Muster ist bekannt: Drei Teams pflegen den Monolithen, ein viertes soll ihn mit sauberen Schnitten neu implementieren. Nach etwa zwei Jahren werden solche Projekte normalerweise abgebrochen.

Der tragfähige Weg führt über den bestehenden Monolithen. Du arbeitest die fachlichen Domänen schrittweise heraus, über mehrere Iterationen verteilt, nicht in einem einzigen Sprint.

Sobald die Interaktionen zwischen den Domänen gering sind, saubere Interfaces stehen und das Datenbankschema getrennt ist, lässt sich eine Domäne herausschneiden und in einen eigenen Container verpacken. Der Schnitt ist fachlich, nicht technisch. Das ist das Grundprinzip von Microservices.

Ein Beispiel aus dem Bankenumfeld ist das Onboarding. Ein Kunde kommt herein, seine Daten werden aufgenommen, erste Produkte werden je nach Investitionssumme und Risikobereitschaft angeboten. Dieser Onboarding-Prozess bildet eine in sich geschlossene Domäne, mit der man anfangen kann.

Die Datenbank ist die härteste Baustelle

Viele Firmen betreiben eine große Oracle-Plattform, und davor sitzen DBAs, die Architekturänderungen oft verhindern. Dieses Thema ist gleichzeitig technisch und organisatorisch.

Eine Oracle-Datenbank lässt sich technisch vielleicht zu einem großen Hyperscaler portieren, aber meist will man das nicht. Genau hier liegt eine der größten Aufgaben jeder Migration.

Eine Datenmigration von einem Datenbanksystem in ein anderes muss sicherstellen, dass die Daten danach noch dieselben sind. Das beginnt bei Zeichensätzen und Feldlängen und reicht weiter. Beim Umstieg von einem alten System auf PostgreSQL wird mit Sicherheit einiges passieren, das auffallen muss, bevor es produktiv wird.

Ohne CI/CD-Pipeline ist ein Microservice-System nicht wartbar

Bevor du irgendetwas migrierst, legst du eine Continuous-Delivery-Pipeline an. Das ist der erste Schritt beim Gang in die Cloud, nicht der letzte.

Ein System aus 40 oder 50 Microservices mit Replikas und darunterliegenden Datenbanken ist ohne Tests und CI/CD-Pipeline gar nicht mehr wartbar. Die Automatisierung muss von Anfang an eingebaut sein.

Wenn man so einen Microservice macht, baut man immer zuerst die CI/CD-Pipeline ein und fängt dann erst an, den Code zu schreiben. Christopher Schmidt

Zur Pipeline gehören Unit-Tests, Komponententests und sauber durchgetestete Microservices. Genau hier tauchen die Fehler auf, die bei einer Datenmigration garantiert kommen. Und auch die Pipeline selbst muss einem Prozess unterliegen. Wer sich vorher kein klares Vorgehen überlegt hat, baut etwas, das ständig wegbricht.

Migration verändert Menschen, nicht nur Maschinen

Eine Cloud-Migration lässt sich nicht als U-Boot-Projekt durchziehen. Wenn ein einzelnes Team beschließt, die lokale IT sei zu langsam, und still in die Cloud wechselt, hält das nicht lange. Wegen der organisatorischen Folgen muss die Geschäftsleitung solche Vorhaben mittragen.

Die klassische Silostruktur passt schlecht in die neue Welt. Ein Infrastruktur-Team, ein Ops-Team, Entwickler, die weder Basis-Images kennen noch Deployment-Manifeste schreiben, weil das Ops übernimmt. Diese Trennung soll aufgelöst werden, und das geht nur über Zielvereinbarungen und Incentives, die man anpasst. Das braucht Zeit.

Konkrete Rollen verändern sich. DBAs sind heute für die Query-Performance verantwortlich und optimieren Abfragen direkt im Datenbanksystem. Mit dem Wechsel auf einen Managed Service wie RDS von AWS sind sie in diesem Maße nicht mehr nötig. Auch Entwickler, deren Selbstverständnis bei “mein Artefakt ist ein Jar, alles andere interessiert mich nicht” endet, müssen sich bewegen.

Gleichzeitig kann in einem komplexen Umfeld nicht jeder alles wissen. Kernkompetenzen müssen in den Teams an einzelnen Stellen verbleiben. Der Anspruch, dass jeder Vollzugriff auf alles Wissen hat, funktioniert nicht.

Resilienz-Tests gehören in jede Cloud-Pipeline

Mit der Cloud kommt eine Testkategorie hinzu, die der klassische Funktionstest nicht abdeckt: Resilienz gegen Latenz und Ausfälle. Funktions-, Unit- und Komponententests hattest du vorher wahrscheinlich schon. Das reicht jetzt nicht mehr.

In einem Cluster sind Container zeitweise nicht da, etwa weil ein Knoten neu gebootet oder gestorben ist. Eine API fällt kurz aus, Latenzen steigen an. Aus einem Monolithen werden eigene Prozesse, verteilt über unterschiedliche Maschinen und teils unterschiedliche Rechenzentren. Damit entstehen Latenzen und Fehlersituationen, die es vorher so nicht gab.

Besonders im Hybrid-Cloud-Szenario wird das spürbar. Liegt ein Teil der Anwendung in der Cloud, während Service- oder Datenbanksysteme on-premise bleiben, läuft die Verbindung über VPNs oder SSL. Die Latenz springt dann etwa von zehn auf hundert Millisekunden. Oft reicht das schon, damit Thread-Pools überlaufen.

Solche Resilienz-Tests gehören in die CI/CD-Pipeline. Wer sie weglässt, wundert sich später, warum Teile der neuen Software regelmäßig abstürzen. Etwas Ähnliches gab es im eigenen Rechenzentrum vielleicht auch, nur hat man es ignoriert oder es kam seltener vor.

Wartungsfenster oder schnelle Reaktion

Managed Services lassen Update-Szenarien in Wartungsfenster verpacken, etwa auf Samstag oder Sonntag. Das klingt bequem, hat aber einen Preis, den du bewusst abwägen musst.

Legst du das Fenster ans Wochenende, kann eine Vulnerability bis dahin online bleiben. Gefixte Sicherheitslücken stehen in den Release Notes, und wer einbrechen will, prüft genau die bekannten Java- oder Linux-Standardprobleme darauf, ob ein System noch verwundbar ist.

Die Empfehlung ist klar: ohne Wartungsfenster arbeiten und schnell deployen. Eine Anwendung, die mit kurzen Ausfällen und höheren Latenzen umgehen kann, braucht das geplante Fenster ohnehin nicht im selben Maß. Damit verschiebt sich die Frage zurück zur Resilienz der Architektur.