Strangler Fig Pattern
Ein Architekturmuster zur schrittweisen Ablösung eines Monolithen durch neue Komponenten, indem Schnittstellen Stück für Stück umgeleitet werden.
Klassifikation
- KomplexitätMittel
- AuswirkungTechnisch
- EntscheidungstypArchitektur
- OrganisationsreifeFortgeschritten
Technischer Kontext
Prinzipien & Ziele
Use Cases & Szenarien
Kompromisse
- Inkonsistente Datenzustände bei unzureichender Synchronisation
- Fehlende Rollback-Strategien führen zu Betriebsstörungen
- Zu langsame Migration verlängert technischen Schuldenbestand
- Beginnen mit klar abgegrenzten, wenig gekoppelten Funktionen
- Sicherstellen von Observability und End-to-End-Tests
- Verwendung von Feature-Flags und Canary-Releases
I/O & Ressourcen
- Monolith-Quellcode und Architekturdiagramme
- Routing-Infrastruktur (API-Gateway, Load Balancer)
- Automatisierte Tests und Monitoring
- Modularisierte, inkrementell ausgelagerte Dienste
- Reduzierter Monolith und klare Schnittstellen
- Metriken zur Stabilität und Leistungsentwicklung
Beschreibung
Das Strangler-Fig-Pattern ermöglicht die schrittweise Modernisierung legacy-basierter Systeme, indem neue Funktionalität neben dem Monolithen entwickelt und Verkehr schrittweise umgeleitet wird. Es reduziert Big-Bang-Risiken und erlaubt inkrementelle Tests und Releases während der Migration. Geeignet für riskante, komplexe Ablösungen mit laufendem Betrieb.
✔Vorteile
- Reduziert Risiko durch gestaffelte Migrationen
- Ermöglicht parallele Entwicklung und Tests
- Verbessert schrittweise Wartbarkeit und Skalierbarkeit
✖Limitationen
- Erfordert zusätzliche Infrastruktur für Routing und Integration
- Kann temporäre Komplexität und Doppelarbeit erzeugen
- Nicht immer geeignet für stark kohärente, transaktionale Domänen
Trade-offs
Metriken
- Anteil umgeleiteter Requests
Misst den prozentualen Anteil des Verkehrs, der bereits an neue Komponenten geht.
- Mean Time To Recover (MTTR) bei Rollbacks
Zeit, die benötigt wird, um nach einem fehlgeschlagenen Umschaltversuch den stabilen Zustand wiederherzustellen.
- Fehlerquote neuer Komponenten
Beobachtete Fehlerraten nach schrittweisem Umschalten im Vergleich zum Monolithen.
Beispiele & Implementierungen
Legacy-Shop zu Microservices
Ein Online-Shop extrahiert den Checkout und Inventar in separate Dienste, um Skalierung und Release-Frequenz zu erhöhen.
Monolithische Buchungsplattform
Eine Buchungsplattform verschiebt Zahlungslogik und Benachrichtigungen nacheinander in neue Dienste, um Risiken zu minimieren.
Frontend-zu-Microfrontend-Migration
Das Frontend wird Modul für Modul aus dem Monolithen herausgelöst und über Gateway-Routing zusammengeführt.
Implementierungsschritte
Analyse und Priorisierung von Funktionalitäten zum Extrahieren
Aufbau der Infrastruktur für Routing und Observability
Inkrementelle Extraktion, Testing, Canary-Rollouts und Monitoring
Iterative Entfernung alter Monolith-Teile nach Stabilisierung
⚠️ Technische Schulden & Engpässe
Tech Debt
- Temporäre Verdopplung der Logik in Monolith und neuen Diensten
- Alte Datenmodelle bleiben länger bestehen
- Fragmentierte Observability-Ansätze während der Übergangsphase
Bekannte Engpässe
Beispiele für Missbrauch
- Extraktion großer, transaktionaler Domänen ohne Datenstrategie
- Verzicht auf Observability während kritischer Umschaltungen
- Unkoordinierte Teamaktionen, die zu Inkonsistenzen führen
Typische Fallen
- Unterschätzen des Aufwands für Datenmigration
- Schlechte API-Designs erhöhen langfristig technischen Schuldenstand
- Zu späte Entkopplung von Infrastrukturabhängigkeiten
Erforderliche Fähigkeiten
Drivers (Architectural Drivers)
Constraints
- • Vorhandene Legacy-Datenbankstruktur kann Extraktion erschweren
- • Limitierte Zeitfenster für Änderungen im Betrieb
- • Regulatorische Anforderungen an Datenhaltung und Integrität