Strangler Fig Pattern: Monolithen schrittweise auf AWS modernisieren

Einleitung: Warum Monolithen ein Problem werden

Der globale Markt für Application Modernization wächst von 18,5 Milliarden USD (2024) auf prognostizierte 61,3 Milliarden USD bis 2033 (Global Growth Insights, 2025). Der Treiber: Legacy-Systeme, die sich nicht mehr schnell genug anpassen lassen.

Für DACH-Unternehmen ist das Muster bekannt — eine monolithische Java-Anwendung, die seit 10+ Jahren organisch gewachsen ist, auf der geschäftskritische Prozesse laufen und die niemand vollständig versteht. Jede Änderung birgt Risiken. Deployments dauern Tage. Neue Features brauchen Monate.

Die Verlockung eines vollständigen Rewrites liegt nahe. Doch nur 15 % aller Migrationsprojekte werden im geplanten Budget und Zeitrahmen abgeschlossen. Das Strangler Fig Pattern adressiert genau dieses Dilemma.

Was ist das Strangler Fig Pattern?

Das Strangler Fig Pattern (eingeführt von Martin Fowler, 2004) beschreibt die schrittweise Ablösung eines Monolithen durch neue, unabhängige Services. Der Name stammt von der Würgefeige — einer tropischen Pflanze, die um einen bestehenden Baum wächst, ihn schrittweise ersetzt und schließlich eigenständig steht.

Die drei Kernprinzipien:

1. Facade als Routing-Schicht: Ein API Gateway oder Load Balancer steht vor dem Monolith und routet Anfragen. Initial gehen 100 % des Traffics an den Monolith.
2. Inkrementelle Extraktion: Einzelne Funktionen werden als eigenständige Services implementiert. Die Facade routet den Traffic für diese Funktionen auf die neuen Services.
3. Koexistenz statt Ablösung: Monolith und neue Services laufen parallel. Es gibt keinen Stichtag für den Umstieg.

Der fundamentale Unterschied zum Big-Bang-Rewrite: Das Risiko wird fragmentiert. Jeder extrahierte Service ist ein eigenständiges, überschaubares Projekt mit messbarem Ergebnis (AWS Prescriptive Guidance).

Der AWS-Stack für das Strangler Fig Pattern

AWS bietet alle Bausteine für eine schrittweise Modernisierung. Die folgende Architektur zeigt den typischen Aufbau:

Amazon API Gateway ist besonders geeignet, weil es vollständig konfigurierbare Pfad-Routings bietet. Initial proxied es alle Requests an den Monolith. Bei jeder extrahierten Funktion wird ein neues Routing-Rule hinzugefügt, das Traffic an den neuen Service leitet — ohne Änderung am Monolith selbst (AWS Prescriptive Guidance).

Implementierung in 6 Phasen

1. Phase 1 — Analyse und Scope-Definition: Domain Mapping des Monolithen. Identifikation von Bounded Contexts. Auswahl des ersten Extraktionskandidaten nach Kriterien: hoher Änderungsdruck, klare API-Grenze, geringes Cross-Cutting.
2. Phase 2 — Facade aufsetzen: API Gateway vor den Monolith schalten. Alle bestehenden Endpunkte als Proxy-Routen konfigurieren. Baseline-Metriken mit CloudWatch und X-Ray erfassen.
3. Phase 3 — Ersten Service extrahieren: Ausgewählte Funktion als neuen Service auf ECS/Fargate oder Lambda implementieren. Eigene Datenbank (Database-per-Service Pattern). API-Kontrakt definieren.
4. Phase 4 — Traffic-Shifting: Routing im API Gateway anpassen: Anfragen für die extrahierte Funktion an den neuen Service leiten. Canary-Deployment mit gewichtetem Traffic (z. B. 10 % → 50 % → 100 %).
5. Phase 5 — Validierung und Monitoring: Vergleich der Metriken (Latenz, Error Rate, Throughput) zwischen alter und neuer Implementierung. Rollback-Fähigkeit durch Traffic-Shift zurück auf Monolith.
6. Phase 6 — Iteration: Nächsten Service identifizieren und Phasen 3–5 wiederholen. Pro Iteration wird der Monolith kleiner, die neue Architektur wächst.

Entscheidungsmatrix: Wann welchen Service extrahieren?

Nicht jedes Modul im Monolith eignet sich gleich gut für die Extraktion. Die folgende Matrix hilft bei der Priorisierung:

„Nicht alles muss modernisiert werden. Module mit niedrigem Änderungsdruck können im Monolith verbleiben — solange die extrahierten Services den größten Business Value liefern."

Anti-Corruption Layer: Die kritische Grenze

Beim Strangler Fig Pattern kommunizieren neue Services zwangsläufig mit dem verbleibenden Monolith. Ohne klare Grenzschicht entsteht eine enge Kopplung, die das Ziel der Modernisierung untergräbt.

Der Anti-Corruption Layer (ACL) ist eine Übersetzungsschicht zwischen neuem Service und Monolith. Er stellt sicher, dass:

• Neue Services nicht die Datenmodelle des Monolithen übernehmen müssen
• Änderungen am Monolith die neuen Services nicht brechen
• Die Kommunikation über klar definierte Contracts läuft

Auf AWS lässt sich der ACL als Lambda-Funktion oder als Adapter-Service auf ECS implementieren, der zwischen den API-Formaten übersetzt.

Praxisanwendungsfälle aus dem DACH-Markt

Die Herausforderung „Monolith modernisieren" ist im DACH-Mittelstand allgegenwärtig. Zwei Case Studies aus dem Storm Reply Portfolio zeigen verschiedene Ansätze:

Exom Group — Migration einer Microservice-Anwendung zu Amazon EKS

Die Genius Suite™ Plattform für klinisches Studienmanagement wurde zu Amazon EKS migriert. Hochverfügbare Infrastruktur mit horizontaler und vertikaler Skalierung, Zero-Downtime Security-Patching und automatisierten Backups (Case Study).

Lampemesteren — Contact Center Modernisierung

Migration eines Legacy-Contact-Centers zu Amazon Connect und AWS Lambda. Schnellere Workflow-Implementierung, verbesserte Skalierbarkeit und reduzierte Betriebskosten — Lastspitzen ohne Service-Unterbrechung (Case Study).

Storm Reply Perspektive

Storm Reply — AWS Premier Consulting Partner seit 2014 — begleitet DACH-Unternehmen bei der Application Modernization. Mit 16 AWS-Kompetenzen (darunter DevOps, Cloud Operations und Security) und über 1.500 AWS-Zertifizierungen in der Reply Group verfügt Storm Reply über die Breite und Tiefe, die komplexe Modernisierungsprojekte erfordern.

Die Erfahrung aus zahlreichen Projekten zeigt: Das Strangler Fig Pattern funktioniert besonders gut, wenn es mit einer klaren Domain-Analyse beginnt und der erste extrahierte Service innerhalb von 4–8 Wochen produktiv ist. Das schafft Momentum und beweist den Ansatz, bevor die Organisation große Budgets freigibt.

Regulatorische Aspekte: Compliance bei der Modernisierung

Modernisierungsprojekte im DACH-Raum müssen regulatorische Anforderungen von Anfang an berücksichtigen:

• DSGVO bei Microservices: Jeder Service, der personenbezogene Daten verarbeitet, braucht eigene Datenschutz-Maßnahmen. Das Database-per-Service Pattern vereinfacht die Zuordnung.
• BSI C5 für Container: Amazon ECS und EKS sind BSI C5 Type II attestiert — relevant für regulierte Branchen.
• EU Cyber Resilience Act: Seit 2024 in Kraft, betrifft die Sicherheitsanforderungen an Software-Produkte. Container-Images müssen SBOM (Software Bill of Materials) liefern können.

Vorteile und Herausforderungen

Vorteile

• Minimales Risiko: Kein Big-Bang — jeder Schritt ist reversibel durch Traffic-Shift zurück auf den Monolith
• Inkrementeller Business Value: Jeder extrahierte Service liefert sofort Wert (schnellere Deployments, unabhängige Skalierung)
• Kein Entwicklungsstopp: Der Monolith bleibt während der Modernisierung produktiv — Features können parallel entwickelt werden
• Team-Autonomie: Extrahierte Services können von unabhängigen Teams mit eigenen Release-Zyklen betrieben werden
• Messbarkeit: A/B-Vergleich zwischen alter und neuer Implementierung über Metriken möglich

Herausforderungen und Limitierungen

• Daten-Entkopplung: Gemeinsame Datenbanken sind das häufigste Hindernis — Database-per-Service erfordert Datenmigration und Event-basierte Synchronisation
• Distributed Tracing: Debugging über Service-Grenzen hinweg erfordert Tooling (X-Ray, CloudWatch ServiceLens)
• Organisatorische Reife: Das Pattern funktioniert nur, wenn Teams bereit sind, Service-Ownership zu übernehmen
• Langfristige Koexistenz: Die Betriebskosten steigen temporär, weil Monolith und neue Services parallel laufen

Häufig gestellte Fragen

Was ist das Strangler Fig Pattern?

Ein Modernisierungsmuster, bei dem ein Monolith schrittweise durch neue Microservices ersetzt wird. Ein API Gateway fungiert als Facade und routet Traffic graduell von der alten zur neuen Implementierung — ohne Big-Bang-Migration.

Welche AWS-Services werden eingesetzt?

Amazon API Gateway als Facade, Amazon ECS mit AWS Fargate für containerisierte Services, AWS Lambda für serverlose Funktionen, Application Load Balancer für Traffic-Routing und AWS X-Ray für Distributed Tracing.

Wann ist der Monolith fertig modernisiert?

Es gibt keinen festen Endpunkt. Module mit niedrigem Änderungsdruck können im Monolith verbleiben. Entscheidend ist der Business Value pro extrahiertem Service, nicht die vollständige Ablösung.

Ausblick: Von Strangler Fig zu Event-Driven Architecture

Das Strangler Fig Pattern ist oft der erste Schritt einer umfassenderen Modernisierung. Sobald die ersten Services extrahiert sind, eröffnen sich weitergehende Architekturen: Event-Driven Architecture mit Amazon EventBridge, Saga Patterns für verteilte Transaktionen mit AWS Step Functions und Service Mesh mit AWS App Mesh für komplexe Service-zu-Service-Kommunikation.

Container-basierte Modernisierung wächst mit einem CAGR von über 28 % — und AI-gestützte Migrationstools beschleunigen die Analyse und Extraktion zunehmend (N-iX, 2026). Für DACH-Unternehmen, die heute mit dem Strangler Fig Pattern starten, ist das der natürliche Evolutionspfad.