Während der Migration muss ein ununterbrochener, sicherer und zuverlässigen Betrieb garantiert werden.
Am alten Code sollten so wenig Änderungen wie möglich vorgenommen werden
wenn es nur nicht ausreichend Unittests gibt, um Tests nach dem Refaktoring durchführen zu können.
da Änderungen im Code neue Fehler erzeugen können.
Der alte Code muss eventuell so weit geändert bzw. vorbereitet werden, dass er die Migration unterstützt.
Migrationsmuster
Die am besten geeignete Methode hängt von den Umständen und den spezifischen Anforderungen des Projekts ab. Hier einige Beispiele:
Strangler Fig: Das Muster ist nach einer Feigenart benannt, die auf einem anderen Baum wächst und diesen nach und nach überwuchert. Genauso ersetzt ein neues System das alte schrittweise, bis es obsolet wird.
Big Bang Replacement: Dabei wird das bestehende System komplett und auf einmal durch ein neues ersetzt. Dies kann bei einem deutlich überlegenen neuen System der einfachste Weg sein, birgt aber die größten Risiken, da Probleme oft erst im laufenden Betrieb auffallen.
Parallelbetrieb: Bei diesem Ansatz laufen Alt- und Neusystem zeitgleich. Nutzer können beide Systeme verwenden und wechseln mit zunehmender Vertrautheit zum neuen System, bis das alte außer Betrieb genommen wird.
Chicken Little Strategie (auch „Stückweise“ aka Piecemeal): Benannt nach dem Kindermärchen, bei dem der Himmel herabfällt, werden Änderungen in kleinen, handhabbaren Schritten vorgenommen. Das System wird Stück für Stück ersetzt. Das senkt das Risiko, verlängert aber die Gesamtdauer der Migration.
Sandwich Layer (auch „Leverage“): Hier wird eine neue Schnittstellenebene zwischen Alt- und Neusystem geschaffen. Dadurch können neue Module entwickelt werden, während die Kernfunktionalität des alten Systems erhalten bleibt.
Phasenweise Migration: Ähnlich wie die Chicken Little Strategie, jedoch werden ganze Funktionalitäten oder Abteilungen auf einmal migriert. Das neue System wird schrittweise eingeführt, während das alte ausläuft.
Rehosting (auch „Lift and Shift“): Hierbei wird eine Anwendung von einer Umgebung in eine andere verschoben, ohne ihr Design zu verändern, z.B. von einer lokalen Infrastruktur in die Cloud.
Denke daran: Jedes Muster hat seine Stärken und Schwächen. Die Wahl der passenden Migrationsstrategie sollte sorgfältig an die spezifischen Projektumstände angepasst werden.
Strangler Fig Pattern
Die Brownfield-Migration unter Anwendung des Strangler Fig Patterns bietet zahlreiche Vorteile, da sie einen schrittweisen Ansatz ermöglicht, um eine monolithische Struktur in eine modularere Architektur umzuwandeln.
Hier sind einige Vorteile dieses Ansatzes:
“Non-Disruptive Transition”: Das Strangler-Fig-Pattern erlaubt es, Funktionalitäten nach und nach aus der monolithischen Anwendung herauszulösen, sodass Alt- und Neusystem parallel betrieben werden können. Ein großes, risikobehaftetes „Cut-over“-Deployment ist nicht nötig.
Risikomanagement: Da die Vorgehensweise iterativ ist, kann man bei Problemen sofort gegensteuern oder die Methode ändern. Fehler können schrittweise gefunden und behoben werden, ohne das Risiko eines Big-Bang-Releases.
Business Continuity: Während der Übergangsphase bleibt der Geschäftsablauf erhalten, da die alte Funktionalität weiterhin die Nutzer bedient, bis die neue bereitgestellt ist.
Flexibilität: Die schrittweise Ablösung von Services gibt Zeit zum Lernen und Adaptieren. Jede neue Komponente kann von bereits modernisierten Teilen profitieren. Außerdem besteht die Möglichkeit, unterschiedliche Technologien für verschiedene Features/Services zu wählen.
“Space for Agility”: Da Teams jeweils nur einen Bereich der Anwendung ersetzen, können Auswirkungen gemessen, neue Technologien ausprobiert und flexibel auf sich ändernde Geschäftsanforderungen reagiert werden.
Leistungsverbesserungen: Durch das Refaktorieren in kleine, autonome Services lassen sich Teile des Systems isolieren, Performance-Engpässe identifizieren, Abhängigkeiten reduzieren und die Komplexität senken.
Beachte jedoch, dass eine erfolgreiche Brownfield-Migration mittels Strangler-Pattern sorgfältige Planung und ein tiefes Verständnis des bestehenden Systems erfordert. Bei unsachgemäßer Umsetzung kann es zu Inkongruenzen zwischen alten und neuen Services kommen.
Überlegungen zur Auswahl der Strategie
Wie aufwändig wäre eine Neuentwicklung der Software?
Wie viele neue Anforderungen sind in der Zeit der Migration geplant?
Lässt das Altsystem ein Refaktoring zu?
Gibt es automatische Tests? Gibt es Unittests?
Gibt es eine Struktur, an der sich die Migration orientieren könnte?
Ist das Altsystem gut dokumentiert?
Workflow?
Architekturentscheidungen?
Je nachdem kann hier abgewogen werden, ob ein Big Bang Replacement auf der ‘grünen’ Wiese, eine Strangler Fig Migration im ‘Brownfield’ oder eine Kombination als
Parallel Run durchgeführt werden sollte.