Die Big-Bang-Migration gilt als eines der größten Risiken in IT-Projekten. Die bewährte Alternative: das Strangler Fig Pattern. Statt eines harten Systemwechsels wird Legacy-Software hierbei schrittweise und bei laufendem Betrieb durch neue Services ersetzt. Dieser Ratgeber analysiert die technische Funktionsweise, vergleicht Ansätze und zeigt ein konkretes Praxis-Beispiel.
-
Das Wichtigste in Kürze
- Was ist das Strangler Fig Pattern? Eine inkrementelle Modernisierungsstrategie, bei der Legacy-Software schrittweise und modular durch neue Microservices ersetzt wird, bis das Altsystem vollständig abgelöst ist.
- Wie funktioniert die technische Umsetzung? Ein vorgeschalteter Proxy (Routing-Weiche) leitet Anfragen Stück für Stück vom Altsystem auf neue Komponenten um, sodass beide Systeme während der Migration parallel und ausfallsicher laufen.
- Warum ist es besser als eine Big-Bang-Migration? Das Betriebsrisiko sinkt massiv, da Fehler auf einzelne Module begrenzt bleiben und das Altsystem jederzeit als Fallback dient, statt alles auf einen Schlag umzuschalten.
- Wann lohnt sich der Einsatz? Besonders bei geschäftskritischen, komplexen Monolithen, die keine Downtime erlauben, und wenn eine schnelle Wertschöpfung (Time-to-Value) wichtiger ist als ein sofortiger Komplett-Umbau.
- Welche Herausforderungen gibt es? Die parallele Datenhaltung zwischen Alt- und Neusystem erfordert eine komplexe Synchronisation, zudem besteht die Gefahr, dass die Migration vor der finalen Abschaltung des Altsystems abgebrochen wird.
Was ist das Strangler Fig Pattern?
Die Modernisierung einer Software ist ein anspruchsvolles Projekt, das viele Herausforderungen mit sich bringt. Besonders der abrupte Wechsel von einem System auf ein anderes kann zu vielen Problemen führen.
Die Lösung: Anstatt das gesamte System auf einmal auszutauschen, werden die einzelnen Komponenten Schritt für Schritt erneuert – mithilfe des Strangler Fig Patterns.
Das Strangler Fig Pattern (auch Strangler Pattern) ist eine inkrementelle Methode der Software-Modernisierung, bei der ein Altsystem schrittweise durch neue Microservices oder Module ersetzt wird, bis das alte System vollständig abgelöst ist. Der Kernvorteil liegt darin, dass die Bestandsanwendung während des gesamten Prozesses voll funktionsfähig bleibt, während neue Features modular ergänzt werden.
Das Strangler Fig Pattern, auch Strangler Pattern, das erstmals von Martin Fowler beschrieben wurde, ist nach der australischen Würgefeige benannt. Diese Pflanze wächst um einen anderen Baum herum und ersetzt ihn im Laufe der Zeit vollständig.
Ähnlich funktioniert das Strangler Fig Pattern in der Software-Modernisierung: Das alte System bleibt zunächst bestehen, während neue Funktionen schrittweise hinzugefügt werden. Nach und nach übernimmt das neue System immer mehr Aufgaben, bis es schließlich das alte vollständig ersetzt.
Durch diese schrittweise Erneuerung bleibt die Anwendung jederzeit funktionsfähig. Es gibt keine abrupten Ausfälle oder großen Überraschungen, was das Risiko erheblich minimiert und einen reibungslosen Übergang gewährleistet.
Big-Bang-Migration vs. Strangler Fig Pattern
Der direkte Vergleich verdeutlicht, warum das Strangler Fig Pattern die überlegene Alternative zur riskanten Big-Bang-Migration ist:
| Merkmal | Big-Bang-Migration | Strangler Fig Pattern |
|---|---|---|
| Vorgehensweise | Sofortige Umschaltung (Alles auf einmal) | Schrittweise Ersetzung (Inkrementell) |
| Risiko | Hoch (Fehler betreffen das Gesamtsystem) | Gering (Fehler auf Komponenten begrenzt) |
| Parallelbetrieb | Nein (Alt aus, Neu an) | Ja (Alt und Neu laufen parallel) |
| Nutzererlebnis | Abrupter Wechsel (Harter Schnitt) | Kontinuierliche, kaum merkliche Updates |
| Time-to-Value | Spät (erst nach Projektabschluss) | Früh (nach Migration erster Features) |
Expertentipp
Das Strangler Fig Pattern kann in Web-, Desktop- und Mobile-Apps eingesetzt werden. Dabei spielt es keine Rolle, ob die Anwendung in Java, JavaScript, COBOL oder VBA als Teil eines Excel-Sheets geschrieben ist. Letzteres erfordert lediglich kreativere Lösungen.
Wie funktioniert das Strangler Fig Pattern?
Zur Erinnerung: Das Strangler Fig Pattern ist eine bewährte Methode zur Software-Modernisierung, die darauf abzielt, alte Anwendungen schrittweise durch neue zu ersetzen. Aber wie genau funktioniert das Strangler Fig Pattern? Schauen wir uns den Prozess im Detail an.
- Initiale Weiche einrichten (Routing): Zu Beginn wird eine Abfang-Ebene vor das bestehende System geschaltet. Bei Webanwendungen nutzen wir hierfür meist einen Reverse Proxy oder Load Balancer. Bei Desktop-Anwendungen sind oft individuellere Wrapper-Lösungen notwendig. Diese Weiche leitet initial noch 100% der Anfragen an das Altsystem (Monolith) weiter.
- Neue Komponente isoliert entwickeln: Anstatt das System am offenen Herzen zu operieren, wird eine einzelne Funktionalität als neuer, moderner Microservice oder Modul entwickelt und getestet.
- Weiche umschalten (Inkrementeller Rollout): Sobald das neue Modul stabil läuft, wird der Proxy konfiguriert. Er leitet nun spezifische Anfragen (z. B. /api/neue-funktion) an den neuen Service. Der restliche Traffic fließt weiterhin ungestört zum Altsystem.
- Kontinuierliche Wiederholung: Dieser Zyklus wiederholt sich für jede weitere Funktion. So „erwürgt“ (strangle) die neue Architektur das alte System schrittweise, ohne dass es zu Downtimes für die Nutzer kommt.
- Abschaltung (Decommission): Sobald die letzte Funktion migriert ist und der Monolith keinen Traffic mehr erhält, wird das Altsystem final abgeschaltet.
Was sind die Vorteile des Strangler Fig Pattern?
-
Risikominimierung: Die Bestandsanwendung bleibt während der gesamten Migration voll funktionsfähig, was das Risiko von Betriebsausfällen eliminiert.
-
Schnellerer ROI (Time-to-Value): Neue Funktionen und Verbesserungen stehen Nutzern sofort nach dem Release des jeweiligen Microservices zur Verfügung, nicht erst nach Projektabschluss.
-
Flexibilität & Priorisierung: Die Modernisierung erfolgt im eigenen Tempo; geschäftskritische Funktionen können priorisiert behandelt werden.
-
Kosteneffizienz: Investitionskosten fallen nicht punktuell an (wie beim Big Bang), sondern verteilen sich über die Projektlaufzeit.
Herausforderungen & Nachteile
-
Komplexe Datenhaltung: Der Parallelbetrieb erfordert oft eine aufwendige, kontinuierliche Synchronisation der Daten zwischen Alt- und Neusystem.
-
Disziplin bei der Fertigstellung: Es besteht die Gefahr, dass die Migration gestoppt wird, sobald die wichtigsten Features laufen. Dies führt zu dauerhaft doppelten Wartungskosten, wenn das Altsystem nicht vollständig abgeschaltet wird.
Wann ist ein Strangler Fig Pattern die beste Option?
Die Entscheidung für das Strangler Fig Pattern hängt primär davon ab, wie schnell ein Return-on-Investment (ROI) erzielt werden soll und wie komplex das Altsystem ist.
Strategische Einflussfaktoren
Ob diese Methode geeignet ist, wird durch vier zentrale Faktoren bestimmt:
- Kritikalität: Wie geschäftskritisch ist die Komponente und wie hoch ist das Risiko bei einem Ausfall?
- Technische Schuld: Ist der Code so veraltet, dass ein Refactoring (Transformieren) unwirtschaftlich wäre?
- Kopplung: Wie stark ist die Komponente mit dem Rest des Monolithen verflochten?
- Zielbild: Wie klar ist das fachliche Verständnis für den Neubau der Architektur?
Ideale Szenarien für den Einsatz
Das Strangler Fig Pattern spielt seine Stärken besonders in folgenden drei Fällen aus:
- Veraltete Komponenten: Wenn Teile der Software technologisch so obsolet oder schlecht geschrieben sind, dass ein komplettes Ersetzen ("Replace") effizienter ist als eine Reparatur.
- Isolierbare Funktionen: Wenn sich eine Komponente gut vom Rest des Systems trennen lässt (Lose Kopplung), ohne die Gesamtstabilität zu gefährden.
- Klar definierte Features: Wenn exakt bekannt ist, wie die neue Funktion aussehen soll, kann diese gezielt neben dem Altsystem hochgezogen werden.
Das Strangler Fig Pattern ist eine Methode zum Ersetzen von Komponenten auf Systemebene. Wenn Sie stattdessen bestehenden Code lediglich sanieren wollen, sind Refactoring-Ansätze oft zielführender.
Jochen Schweizer – ein erfolgreicher Use Case
Ein erfolgreiches Anwendungsbeispiel ist der Relaunch der Jochen Schweizer mydays Group (JSMDG). Die Herausforderung lag in der Konsolidierung der heterogenen Systemlandschaften nach der Fusion beider Unternehmen.
Lösung: Durch den Einsatz des Strangler Fig Patterns wurde eine zentralisierte Plattform um die bestehende Architektur herum gebaut. Diese neue Plattform löste die Legacy-Shops und Backend-Systeme graduell ab, ohne den laufenden Betrieb zu gefährden.
Das Strangler Fig Pattern ermöglichte bei der JSMDG folgende messbare Ergebnisse:
- Verfügbarkeit: 100 % (Zero Downtime während der Migration)
- Performance: Reduzierung der Ladezeiten um 37 %
- Business Impact: Signifikant höhere Conversion-Rate durch verbesserte UX
Häufig gestellte Fragen zu Strangler Fig Pattern
Wie wird das Strangler Fig Pattern technisch umgesetzt?
Die technische Umsetzung erfolgt primär durch einen Reverse Proxy oder ein API Gateway (die „Weiche“). Diese vorgeschaltete Komponente fängt alle Client-Anfragen ab und routet sie basierend auf URL-Pfaden entweder zum Altsystem oder zu den neuen Microservices.
Sobald eine neue Funktion bereit ist, wird die Weiche angepasst, sodass Anfragen für diese Funktion an die neue Anwendung geleitet werden. Die genaue Gestaltung dieser Weiche variiert stark je nach Anwendungslandschaft und muss individuell bewertet werden.
Was sind die Hauptgründe für die Wahl des Strangler Fig Patterns?
Die Hauptgründe für die Wahl des Strangler Fig Patterns sind die Minimierung von Risiken, die kontinuierliche Verfügbarkeit der Anwendung und die Möglichkeit, Modernisierungen schrittweise und kosteneffizient durchzuführen.
Was bedeutet der „Schneideprozess“ vor der Migration bei Strangler Fig?
Das Schneiden (Slicing) ist die analytische Zerlegung des Monolithen vor dem Start des Strangler Fig Patterns. Dabei wird der Code in fachliche Komponenten zerlegt, gruppiert und voneinander abgegrenzt. Dies ist notwendig, um zu entscheiden, ob ein Modul komplett durch einen neuen Service ersetzt oder lediglich transformiert (refactored) werden soll.
Richard Gross ist Head of Software Archaeology und arbeitet seit 2013 im Bereich der IT-Modernisierung. Als Mitglied der Bereichsleitung treibt er Themen wie technische Exzellenz voran. Als Teamleiter und Architekt unterstützt er Teams dabei, so früh und kontinuierlich wie möglich einen Return on Investment zu erzielen. Um dies zu erreichen, coacht er Teams in den Bereichen Codequalität, Testautomatisierung und Collective Ownership. Sein technischer Fokus liegt auf hexagonalen Architekturen, TestDSLs, Hypermedia-APIs und der ausdrucksstarken und eindeutigen Modellierung der Domäne als Code. Richard teilt sein Wissen durch aktives Pair Programming sowie durch Schulungen, Fachartikel und Präsentationen auf internationalen Konferenzen. Er engagiert sich seit langem auch in dem Open-Source-Projekt CodeCharta, das es Nicht-Entwicklern ermöglicht, ein Verständnis für die Qualität ihrer Software zu gewinnen.