Strangler-Fig-Muster: Ein pragmatischer Leitfaden für Engineering-Leiter

Strangler-Fig-Muster: Ein pragmatischer Leitfaden für Engineering-Leiter

Das Strangler-Fig-Muster, geprägt von Martin Fowler, ist ein architektonischer Ansatz zur schrittweisen Ablösung von Funktionen eines Legacy-Systems durch eine Fassade oder einen Proxy, der den Datenverkehr zu neuen Komponenten weiterleitet, bis das alte System sicher außer Betrieb genommen werden kann. Der Name stammt vom Würgefeigenbaum, der um einen Wirtsbaum herum wächst und ihn allmählich vollständig übernimmt, bis der ursprüngliche Wirt verschwunden ist. In der Software funktioniert der Mechanismus genauso: umschließen, umleiten, ersetzen, stilllegen.

Drei Konzepte bilden das Fundament des Musters: eine Fassade , die den gesamten Datenverkehr abfängt, schrittweise Extraktion von Funktionen in neue Services und ein Stilllegungskriterium , das bestätigt, dass das Legacy-System nicht mehr benötigt wird. Setzen Sie es ein, wenn:

• Eine vollständige Neuentwicklung ein nicht akzeptables Auslieferungs- oder Geschäftsrisiko birgt

• Das System während der gesamten Migration weiterhin Produktionsdatenverkehr bedienen muss

• Die Auslieferung von Funktionen kann nicht monatelang pausieren, während eine Neuentwicklung abgeschlossen wird

• Das Azure Architecture Center und AWS Prescriptive Guidance empfehlen es beide für die phasenweise Cloud-Migration monolithischer Anwendungen

Ridiculous Engineering setzt dieses Muster bei Modernisierungsprojekten ein, bei denen die Kosten eines Fehlers hoch und die Toleranz für Ausfallzeiten gering ist.

Inhaltsverzeichnis

• Warum Teams das Strangler-Fig-Muster einer vollständigen Neuentwicklung vorziehen

• Wie das Strangler-Fig-Muster auf Architekturebene funktioniert

• Konkrete Implementierungstechniken und Komponenten

• Ein phasenweiser Leitfaden von der Bestandsaufnahme bis zur Stilllegung

• Wie eine echte Migration aussieht: der Bestellservice

• Abwägungen, Fallstricke und wann dieses Muster nicht eingesetzt werden sollte

• Ridiculou Engineering führt Strangler-Fig-Migrationen von Anfang bis Ende durch

• Wichtigste Erkenntnisse

• Nützliche Quellen und weiterführende Literatur

• FAQ

Warum Teams das Strangler-Fig-Muster einer vollständigen Neuentwicklung vorziehen

Legacy-Systeme führen auf vorhersehbare Weise zu Problemen für Teams. Die Codebasis ist fragil, die Testabdeckung dünn, und die Ingenieure, die das ursprüngliche Design verstanden haben, sind weitergezogen. Eine vollständige Neuentwicklung klingt attraktiv, bis die erste Schätzung vorliegt und das Unternehmen erkennt, dass dies sechs bis achtzehn Monate paralleler Investitionen bei null ausgelieferten neuen Funktionen bedeutet.

Die konkreten Probleme, die Teams zur schrittweisen Modernisierung bewegen:

• Fragile Monolithen wobei eine Änderung in einem Modul unabhängige Funktionen beeinträchtigt

• Wissenslücken in älteren Sprachen (COBOL, PowerBuilder, frühes Java EE), die ein zuverlässiges Refactoring nahezu unmöglich machen

• Regulatorische Vorgaben und Verfügbarkeitsanforderungen die längere Wartungsfenster verbieten

• Anforderungen an kontinuierliche Bereitstellung bei denen Produkt-Roadmaps für eine Neuentwicklung nicht pausieren können

• Kosten- und Zeitrisiko bei umfangreichen Neuentwicklungen, die häufig die Budgeterwartungen überschreiten und zwar deutlich

Martin Fowlers ursprüngliche Darstellung bringt den zentralen Zielkonflikt gut auf den Punkt:

Diese Risikoreduzierung ist der wichtigste geschäftliche Antrieb. Fowlers empfohlener Ansatz priorisiert stetige, sichtbare Erfolge gegenüber einem einzelnen Einführungsereignis. Für einen CTO, der ein Modernisierungsbudget gegenüber dem Vorstand verteidigt, ist „Wir haben in diesem Quartal drei neue Funktionen ausgeliefert und gleichzeitig den Bestellservice migriert“ ein deutlich leichteres Gespräch als „Wir werden im vierten Quartal des nächsten Jahres etwas vorzeigen können.“

So funktioniert das Strangler-Fig-Muster auf Architekturebene

Die Architektur ist konzeptionell einfach. Jede Client-Anfrage läuft durch eine Strangler-Fassade, bei der es sich typischerweise um ein API-Gateway, einen Reverse-Proxy oder eine speziell entwickelte Routing-Schicht handelt. Die Fassade prüft jede Anfrage und leitet sie je nach bereits migrierten Funktionen entweder an das Legacy-System oder an den neuen Service weiter.

Der Ablauf sieht folgendermaßen aus: Client → Strangler-Fassade → Legacy-Monolith (für nicht migrierte Funktionen) oder neuer Microservice (für migrierte Funktionen). Das Legacy-System und die neuen Services bestehen während der Migration parallel. Am Client ändert sich nichts.

Zentrale Verantwortlichkeiten der Fassade:

• Anforderungsrouting basierend auf Pfad, Header, Mandant oder Feature-Flag

• Anti-Corruption Layer (ACL) Übersetzung zwischen Legacy-Datenmodellen und Verträgen neuer Services, wie vom Azure Architecture Center dokumentiert

• Telemetrie und Nutzungsprotokollierung zur Messung, welche Legacy-Endpunkte noch aktiv sind

• A/B- und Canary-Routing um den prozentualen Datenverkehr schrittweise auf neue Services zu verlagern

Der Wikipedia-Eintrag zum Muster weist darauf hin, dass es auf mehreren Granularitätsebenen angewendet werden kann – vom Umschließen einer einzelnen Methode bis zur Migration einer gesamten Anwendung. Diese Flexibilität macht es praktisch: Sie müssen sich nicht am ersten Tag auf eine vollständige Microservices-Architektur festlegen.

Profi-Tipp: Statten Sie die Fassade mit Instrumentierung aus, bevor Sie auch nur eine einzelne Funktion extrahieren. Die Nutzungs-Telemetrie der ersten Woche zeigt Ihnen, welche Endpunkte am häufigsten aufgerufen werden, welche nur von einem Client aufgerufen werden und welche seit Monaten nicht mehr verwendet wurden. Diese Daten bestimmen Ihre Prioritätenliste für die Extraktion und machen häufig toten Code sichtbar, den Sie einfach löschen können.

Konkrete Implementierungstechniken und Komponenten

Die Fassade einzurichten ist der einfache Teil. Die technische Komplexität liegt in der Routing-Logik, der Datensynchronisierung und der Aufrechterhaltung eines konsistenten Verhaltens beider Systeme während ihrer parallelen Existenz.

Kernkomponenten

1. Strangler-Fassade (API-Gateway oder Reverse-Proxy): NGINX, AWS API Gateway, Azure API Management oder ein benutzerdefinierter Routing-Service. Dies ist der einzige Einstiegspunkt für den gesamten Datenverkehr.

2. Anti-Corruption Layer (ACL): Eine Übersetzungsschicht, die Legacy-Datenmodelle und -Semantik in das Domänenmodell des neuen Services umwandelt. Entwerfen Sie ACLs von Anfang an mit expliziten Übersetzungsregeln und einem Plan für ihre Außerbetriebnahme.

3. Service-Adapter:Dünne Wrapper, die es dem neuen Dienst ermöglichen, Legacy-APIs oder -Datenbanken aufzurufen, ohne Legacy-Logik zu importieren.

4. Feature-Flags:Laufzeitumschalter (LaunchDarkly, Unleash oder ein selbst entwickelter Flag-Speicher), die steuern, welche Benutzer oder Mandanten an den neuen Dienst weitergeleitet werden.

5. Intercept-Punkte:Hooks innerhalb des Monolithen, die es der Fassade ermöglichen, Ereignisse oder Datenänderungen zu erfassen, ohne die zentrale Legacy-Logik zu ändern.

Routing-Techniken

• Pfadbasiertes Routing:Leite /orders/v2/* an den neuen Dienst weiter, /orders/* an das Legacy-System.

• Routing nach Header oder Mandant:Leite bestimmte Mandanten oder API-Clients für Tests mit frühen Anwendern an den neuen Dienst weiter.

• Feature-Flag-gesteuertes Routing:Verschiebe mithilfe eines Flag-Speichers schrittweise einen Prozentsatz des Datenverkehrs (1 %, 10 %, 50 %, 100 %).

• Canary-Releases:Leite einen kleinen Teil des Produktionsdatenverkehrs an den neuen Dienst weiter und vergleiche Fehlerraten und Latenz, bevor du die Einführung ausweitest.

Datenmigration und Synchronisierung

Bei Strangler-Migrationen ist die Datenmigration meist der Punkt, an dem es am langsamsten vorangeht. Die Optionen, ungefähr nach Komplexität geordnet:

• Dual-Write:Die Anwendung schreibt gleichzeitig in die Legacy-Datenbank und den neuen Datenspeicher. Einfach zu implementieren, aber Schreibfehler erfordern eine sorgfältige Logik zur Abstimmung.

• Change Data Capture (CDC):Tools wie Debezium streamen Änderungen auf Zeilenebene nahezu in Echtzeit aus der Legacy-Datenbank an den neuen Dienst. Bevorzuge CDC bei schreibintensiven Systemen, wenn die Latenz von Dual-Write nicht akzeptabel ist.

• Event Sourcing:Gib Domänenereignisse erneut wieder, um den Zustand im neuen Dienst aufzubauen. Leistungsfähig, erfordert aber, dass das Legacy-System saubere Ereignisse ausgibt.

• Massen-Nachbefüllung:Einmalige Migration historischer Daten, die üblicherweise vor dem Go-live ausgeführt und mit CDC-Deltas abgeglichen wird.

Profi-Tipp: Für nicht kritische Lesezugriffe ist letztendliche Konsistenz in der Regel akzeptabel. Bewahre die Komplexität des synchronen Dual-Write für Finanztransaktionen, Bestandszählungen und alle Daten auf, bei denen ein veralteter Lesezugriff eine tatsächliche geschäftliche Konsequenz hat.

Checkliste für Tests und Monitoring

• Ende-zu-Ende-Tests, die sowohl den Legacy- als auch den neuen Codepfad über die Fassade ausführen

• Vertragstests zwischen der Fassade und jedem nachgelagerten Dienst

• Canary-Dashboards, die Fehlerrate, p95-Latenz und die Übereinstimmung der Geschäftsmetriken verfolgen

• Alarme bei Verhaltensabweichungen: Wenn der neue Dienst für dieselbe Eingabe andere Ergebnisse als das Legacy-System zurückgibt, solltest du es erfahren, bevor es die Benutzer tun.

Ein phasenweiser Leitfaden von der Bestandsaufnahme bis zur Außerbetriebnahme

Phase	Wichtige Aktivitäten	Rollen	Erfolgskriterium
1. Erkundung	Endpunkte inventarisieren, Abhängigkeiten abbilden, Telemetrie instrumentieren	Architekt, Dateningenieur	Abhängigkeitskarte vollständig; die 10 Endpunkte mit dem höchsten Aufrufvolumen identifiziert
2. Nahtstellen identifizieren	Servicegrenzen definieren, ACL-Übersetzungspunkte identifizieren	Architekt, Product Owner	Begrenzte Kontexte dokumentiert; ACL-Schema entworfen
3. Fassade und ACL erstellen	Routing-Schicht bereitstellen, ACL implementieren, Parität validieren	Architekt, SRE	100 % des Datenverkehrs fließen ohne Regression durch die Fassade
4. Erstes Feature extrahieren	Einen risikoarmen, wertvollen Endpunkt zum neuen Service migrieren	Entwicklungsteam, QA	Der neue Service verarbeitet den Zielendpunkt; die Fehlerrate entspricht der Ausgangsbasis des Legacy-Systems
5. Weiterleiten und überwachen	Datenverkehr mithilfe von Feature-Flags und Canary schrittweise umleiten	SRE, Migrationsleitung	p95-Latenz innerhalb von 10 % des Legacy-Systems; keine Warnungen zu Dateninkonsistenzen
6. Iterieren und skalieren	Die Extraktion der verbleibenden Features in Prioritätsreihenfolge wiederholen	Gesamtes Team	Jedes extrahierte Feature besteht Vertragstests und die Canary-Freigabe
Legacy-System außer Betrieb nehmen	Bestätigen, dass keine eingehenden Aufrufe mehr erfolgen, Datenverantwortung übertragen, archivieren	Architekt, Dateningenieur, SRE	30 aufeinanderfolgende Tage kein Datenverkehr zum Legacy-System; Datenparität bestätigt; Rollback-Plan dokumentiert

Das Kriterium für die Außerbetriebnahme verdient besondere Beachtung. Ein Legacy-Modul ist erst dann bereit für die Stilllegung, wenn drei Bedingungen erfüllt sind: Es gibt während eines festgelegten Zeitraums keine eingehenden Aufrufe mehr (30 Tage sind ein sinnvoller Mindestzeitraum), die Übertragung der Datenverantwortung auf den neuen Service ist bestätigt, und historische Daten wurden archiviert oder migriert, wobei ein verifizierter Lesezugriff besteht. Das Überspringen einer dieser Bedingungen führt zum schlechtesten Ergebnis: einem „außer Betrieb genommenen“ System, das weiterhin unbemerkt Datenverkehr bedient.

Was die Zeitplanung betrifft, dauert ein kleiner Umfang typischerweise einige Monate, ein mittlerer Umfang wie eine vollständige Domäne weniger als ein Jahr, und ein großer Umfang, der die vollständige Zerlegung eines Monolithen umfasst, ist ein langfristiges, mehrjähriges Programm, wie Fowler ausdrücklich anerkennt.

Wie eine echte Migration aussieht: der Bestellservice

Ein üblicher Ausgangspunkt für Strangler-Migrationen ist der Bestellservice in einem Retail- oder SaaS-Monolithen. Die Migrationsabfolge sieht wie folgt aus:

• Schritt 1 — Lesemodell extrahieren: Einen neuen Microservice für Bestellabfragen erstellen, der aus einer replizierten Kopie der Legacy-Bestelltabelle liest. Alle GET-/orders/*-Anfragen über die Fassade an den neuen Service weiterleiten. Das Legacy-System verarbeitet weiterhin alle Schreibvorgänge.

• Schritt 2 — Fassaden-Routing für Bestellendpunkte hinzufügen: Die API-Gateway-Fassade bereitstellen. Bestätigen, dass 100 % des Bestelldatenverkehrs ohne Latenzregression durch sie fließen.

• Schritt 3 — ACL implementieren: Das Legacy-Bestellmodell enthält wahrscheinlich denormalisierte Felder, Statuscodes als Ganzzahlen und Kunden-IDs, die einem anderen Schema zugeordnet werden. Die ACL übersetzt diese, bevor der neue Service sie überhaupt sieht.

• Schritt 4 – Schreibvorgänge mit CDC migrieren: Debezium (oder eine gleichwertige Lösung) einrichten, um Bestellschreibvorgänge aus der Legacy-Datenbank in das Ereignisprotokoll des neuen Dienstes zu streamen. Die Datenparität zwischen beiden Speichern validieren.

• Schritt 5 – Validieren und als Canary bereitstellen: 5 % des Schreib-Traffics an den neuen Dienst weiterleiten. Auf Abweichungen bei der Anzahl der Bestellungen, fehlgeschlagene Zustandsübergänge und Fehler bei nachgelagerten Benachrichtigungen achten.

• Schritt 6 – Umschalten und außer Betrieb nehmen: 100 % des Traffics an den neuen Dienst weiterleiten. 30 Tage lang überwachen. Die Legacy-Bestelltabellen außer Betrieb nehmen, nachdem bestätigt wurde, dass keine direkten Lesezugriffe mehr erfolgen.

Die Architektur während der Koexistenz: Client → API-Gateway-Fassade → Legacy-Monolith (zunächst Schreibvorgänge) und neuer Bestell-Microservice (zunächst Lesevorgänge, anschließend Schreibvorgänge). Beide Dienste nutzen während des Übergangs einen gemeinsamen CDC-Replikationsstream. Die herunterladbaren Diagramme des Azure Architecture Center veranschaulichen dieses phasenweise Routing deutlich.

Migrationsphase	Legacy-System verarbeitet	Neuer Dienst verarbeitet	Validierungsprüfung
Extraktion der Lesevorgänge	Alle Schreib- und Lesevorgänge	Bestell-Lesevorgänge (GET)	Datenparität bei den Leseergebnissen
Migration der Schreibvorgänge (Canary)	95 % der Schreibvorgänge	5 % der Schreibvorgänge	Fehlerrate, Parität der Bestellanzahl
Vollständige Umschaltung	Nichts	Der gesamte Bestell-Traffic	Bestätigung von null Traffic über 30 Tage
Außerbetriebnahme	Archiviert	Der gesamte Bestell-Traffic	Datenverantwortung übertragen

Profi-Tipp: Führen Sie die Checkliste für Unternehmensmigrationen durch für alle kundenorientierten Endpunkte, die sich auf SEO oder öffentliche URLs auswirken. Eine Strangler-Migration, die URL-Strukturen ohne geeignete Weiterleitungen ändert, kann den organischen Traffic genauso stark beeinträchtigen wie eine fehlerhafte Neuentwicklung.

Abwägungen, Fallstricke und wann dieses Muster nicht verwendet werden sollte

Das Strangler-Fig-Muster ist nicht immer die richtige Wahl. Bei unachtsamer Anwendung entstehen eigene Problemklassen.

Risiken und Gegenmaßnahmen:

• Komplexität des Routings: Die Fassade wird zu einer kritischen Pfadabhängigkeit. Mildern Sie dies durch Circuit Breaker, Health Checks und ein getestetes Fallback auf das Legacy-System für jede Route.

• Herausforderungen bei der Datenkonsistenz: Dual Writes und CDC führen beide zu Zeitfenstern mit Inkonsistenzen. Teams unterschätzen häufig den erforderlichen Entwicklungsaufwand, um Datenbanken synchron zu halten.

• Fassade als Engpass: Ein zu klein dimensioniertes API-Gateway fügt jeder Anfrage Latenz hinzu. Testen Sie die Fassade unter Produktionslast, bevor Sie echten Traffic darüber leiten.

• Kosten einer langfristigen Koexistenz: Der parallele Betrieb zweier Systeme verdoppelt den operativen Aufwand. Planen Sie dies ausdrücklich ein; einige Legacy-Module werden eine vollständige Migration möglicherweise nie rechtfertigen und sollten dauerhaft hinter der Fassade isoliert werden.

• Verborgene Kopplung: Legacy-Systeme haben oft undokumentierte Nebenwirkungen (Audit-Trigger, Batch-Jobs, nachgelagerte Integrationen), die erst nach der Herauslösung sichtbar werden. Eine gründliche Erkundungsphase deckt die meisten davon auf.

Kurze Entscheidungscheckliste — verwenden Sie das Strangler-Fig-Muster, wenn:

1. Das System während der gesamten Migration live bleiben muss (keine Wartungsfenster)

2. Eine Big-Bang-Neuentwicklung länger als 6 Monate dauern und die Bereitstellung von Funktionen blockieren würde

3. Sie klare Servicegrenzen oder Nahtstellen in der bestehenden Codebasis definieren können

4. Das Team über die Kapazität verfügt, zwei Systeme parallel zu betreiben

5. Die Komplexität der Datenmigration mit CDC oder Dual-Write beherrschbar ist

Verwenden Sie es nicht, wenn:

1. Das Legacy-System keine identifizierbaren Nahtstellen hat (ein echter „großer Schlammklumpen“ ohne fachliche Grenzen)

2. Dem Team die SRE-Kapazität fehlt, zwei Systeme gleichzeitig zu überwachen

3. Der Migrationsumfang so klein ist (ein einzelner Microservice mit sauberen APIs), dass ein direkter Ersatz ein geringeres Risiko darstellt

4. Regulatorische Vorgaben den parallelen Betrieb von Legacy- und neuen Systemen verbieten

Für Teams, die sich allgemeiner mit der Integration von Legacy-Systemen befassen, ist das Muster ein Werkzeug in einem größeren Modernisierungsbaukasten und keine universelle Lösung.

Ridiculous Engineering führt Strangler-Fig-Migrationen durchgängig durch

Die meisten Teams wollen schrittweise modernisieren. Weniger Teams verfügen jedoch über die Architekturerfahrung, die Tiefe im Data Engineering und die SRE-Kapazität, um dies umzusetzen, ohne dass sich die Migration über Jahre hinzieht oder die Fassade unbemerkt zum neuen Legacy-System wird.

Ridiculous Engineering-Custom-Softwareentwicklung-Praxis führt Strangler-Fig-Projekte von der Erkundung bis zur Stilllegung durch: Abhängigkeitszuordnung, Entwurf von Fassade und ACL, Einrichtung der CDC-Pipeline, Management des Canary-Rollouts und langfristiger Support, sobald die neuen Services live sind. Wir setzen in jeder Phase messbare Meilensteine, damit Sie genau wissen, wann eine Funktion für die Umschaltung bereit ist und wann das Legacy-Modul sicher außer Betrieb genommen werden kann. Wenn Sie einen Monolithen haben, der weiterentwickelt werden muss, und ein Geschäft, das währenddessen nicht stillstehen darf, vereinbaren Sie eine Erkundung mit unserem Team.

Wichtigste Erkenntnisse

Das Strangler-Fig-Muster ist die richtige Wahl, wenn eine Big-Bang-Neuentwicklung zu riskant ist, das System live bleiben muss und Sie klare Nahtstellen in der bestehenden Codebasis definieren können.

Punkt	Details
Vor der Herauslösung instrumentieren	Stellen Sie zuerst die Fassade bereit und fügen Sie Telemetrie hinzu; Nutzungsdaten bestimmen die Priorität der Herauslösung.
ACLs verhindern eine Verunreinigung durch das Legacy-System	Entwerfen Sie Anti-Corruption-Layer mit expliziten Übersetzungsregeln und einem Stilllegungsplan ab dem ersten Tag.
Die Datensynchronisierung ist der schwierige Teil	Replikation auf CDC-Basis bewältigt schreibintensive Systeme; Dual-Write eignet sich für einfachere Abläufe, erfordert jedoch eine Logik zur Abstimmung.
Die Stilllegung erfordert eine verbindliche Freigabe	Kein Legacy-Datenverkehr an 30 aufeinanderfolgenden Tagen sowie bestätigte Datengleichheit, bevor ein Modul außer Betrieb genommen wird.
Ridiculous Engineering	Führt durchgängig Strangler-Fig-Projekte mit messbaren Phasenfreigaben, ACL-Design und Einrichtung von CDC-Pipelines durch.

Nützliche Quellen und weiterführende Lektüre

• Martin Fowler — StranglerFigApplication: Der Ursprung des Musters, die Metapher und die zentrale Begründung für die Risikoreduzierung. Beginnen Sie hier.

• Azure Architecture Center — Strangler-Fig-Muster: Phasenweise Routing-Diagramme, ACL-Leitlinien und Implementierungshinweise vom Cloud-Architekturteam von Microsoft.

• AWS Prescriptive Guidance — Strangler Fig: Routing- und ACL-Anwendungsfälle mit Hinweisen zur cloudnativen Implementierung; behandelt Dual-Write- und CDC-Ansätze.

• Wikipedia — Strangler-Fig-Muster: Prägnante Referenz zu Granularitätsoptionen und Nutzungsprotokollierung als Migrationstool.

• Ridiculous Engineering — Integration von Legacy-Systemen: Praktische Muster für eine nicht-destruktive Modernisierung vom Team von Ridiculous Engineering.

• Ridiculous Engineering — COBOL-Modernisierungskosten: Erkenntnisse zu Budget und Zeitplan aus Modernisierungsprojekten für Legacy-Sprachen.

FAQ

Was ist das Strangler-Fig-Muster in der Softwarearchitektur?

Das Strangler-Fig-Muster ist ein Ansatz, bei dem ein Legacy-System schrittweise ersetzt wird, indem der Datenverkehr über eine Fassade an neue Dienste weitergeleitet wird – Funktion für Funktion –, bis das Legacy-System außer Betrieb genommen werden kann. Martin Fowler prägte den Begriff in Anlehnung an die Biologie des Würgefeigenbaums.

Wie unterscheidet sich das Strangler-Fig-Muster von einer Komplettneuentwicklung?

Bei einer Komplettneuentwicklung wird das gesamte System auf einmal ersetzt, wodurch die Bereitstellung von Funktionen blockiert und das gesamte Risiko auf einen einzigen Start konzentriert wird. Der Strangler-Fig-Ansatz migriert eine Funktion nach der anderen, liefert kontinuierlich Mehrwert und ermöglicht in jeder Phase ein Rollback.

Was ist eine Anti-Corruption Layer, und warum ist sie wichtig?

Eine Anti-Corruption Layer (ACL) ist eine Übersetzungskomponente, die Legacy-Datenmodelle und -semantik in das Domänenmodell des neuen Dienstes umwandelt und verhindert, dass Designentscheidungen des Legacy-Systems in das neue System einfließen. Ohne sie übernehmen neue Dienste tendenziell dieselben strukturellen Probleme wie das System, das sie ersetzen.

Wie lange dauert eine Strangler-Fig-Migration normalerweise?

Der Zeitrahmen hängt vom Umfang ab: Eine kleine Migration dauert typischerweise einige Monate, eine vollständige Domäne wie ein Bestellservice weniger als ein Jahr, und die vollständige Zerlegung eines Monolithen ist ein langfristiges Programm über mehrere Jahre.

Wann sollte man das Strangler-Fig-Muster nicht verwenden?

Vermeiden Sie es, wenn das Legacy-System keine identifizierbaren Schnittstellen besitzt, wenn dem Team die SRE-Kapazität fehlt, um zwei Systeme parallel zu betreiben, oder wenn der Migrationsumfang klein genug ist, dass ein direkter Ersatz weniger Risiko birgt als der Aufbau und die Wartung einer Fassade.

Empfohlen

• Vibe Coding: Machen wir es falsch? | Ridiculous Engineering

• Wie KI die Engineering-Kultur und die berufliche Entwicklung verändert | Ridiculous Engineering

• Die Tech-Branche setzt auf Analytics-Kompetenzen, um ihre Belegschaft zu stärken | Ridiculous Engineering

• Kreativität mit der Theorie der Beschränkungen freisetzen | Ridiculous Engineering