Kurz gesagt (TL;DR)
Das Strangler-Fig-Pattern bietet Banken eine sichere Strategie zur Modernisierung von Legacy-Monolithen unter Vermeidung der operativen Risiken eines Big Bangs.
Die Integration einer Facade-Ebene orchestriert den schrittweisen Übergang zu Cloud-Native-Microservices, während die Operabilität der bestehenden kritischen Systeme intakt bleibt.
Fortschrittliche Techniken wie Change Data Capture garantieren die Datenkonsistenz zwischen Mainframe und Cloud und überwinden die Tücken des Dual-Write.
Der Teufel steckt im Detail. 👇 Lesen Sie weiter, um die kritischen Schritte und praktischen Tipps zu entdecken, um keine Fehler zu machen.
In der Fintech-Landschaft des Jahres 2026 ist Anpassungsgeschwindigkeit die wertvollste Währung. Für etablierte Finanzinstitute wird Innovation jedoch oft durch jahrzehntelange technische Schichten auf Mainframes gebremst. Die Legacy-zu-Microservices-Migration ist keine bloße architektonische Wahl mehr, sondern ein Überlebensimperativ. Die Abkehr vom riskanten „Big Bang“-Ansatz zugunsten des Strangler-Fig-Patterns stellt die sicherste Strategie dar, um kritische Systeme zu modernisieren, ohne den Bankbetrieb zu unterbrechen.
Dieser technische Leitfaden richtet sich an CTOs und Lead Architects, die den Übergang von COBOL/Java-Monolithen zu Cloud-Native-Architekturen auf Kubernetes (GKE) orchestrieren müssen, während sie die Komplexität der Datenkonsistenz und die Servicekontinuität verwalten.
1. Das Banking-Paradoxon: Innovieren ohne zu zerstören
Der Bankensektor erlebt ein Paradoxon: Er muss Benutzererfahrungen bieten, die so reibungslos sind wie die der Neobanken, dabei aber die Stabilität von Kernbankensystemen wahren, die täglich Millionen von Transaktionen verarbeiten. Migrationen vom Typ „Big Bang“ (komplette Neuschreibung und sofortige Umschaltung) haben historisch gesehen Fehlerraten von über 40 %, mit inakzeptablen Risiken für Ausfallzeiten und Datenverlust.
Das von Martin Fowler theoretisierte Strangler-Fig-Pattern (oder „Würgefeigen-Muster“) bietet die Alternative: Das alte System wird mit einer neuen Struktur umhüllt, Aufrufe werden abgefangen und schrittweise an neue Microservices umgeleitet, bis das alte System sicher abgeschaltet werden kann.
2. Referenzarchitektur: Die Abfangebene (The Facade)
Das Herzstück der Strangler-Fig-Strategie ist die Facade (oder Abfangebene). In einem modernen Bankkontext auf der Google Cloud Platform (GCP) wird diese Rolle typischerweise von einem fortschrittlichen API-Gateway oder einem Service Mesh übernommen.
Schlüsselkomponenten der Architektur
- Legacy Mainframe (AS/400 oder z/OS): Das aktuelle System of Record (SoR).
- Strangler Facade (API Gateway/Ingress): Der einzige Einstiegspunkt für den gesamten Client-Traffic. Sie entscheidet, ob die Anfrage an den alten Monolithen oder den neuen Microservice weitergeleitet wird.
- Microservices (GKE): Die neuen Services, entwickelt in Go oder Java (Quarkus/Spring Boot), containerisiert und orchestriert auf der Google Kubernetes Engine.
- Anti-Corruption Layer (ACL): Eine Übersetzungsebene, die verhindert, dass das Datenmodell des alten Systems das Design der neuen Microservices verunreinigt.
3. Schritt-für-Schritt-Implementierungsstrategie
Phase 1: Identifizierung der Bounded Contexts
Beginnen Sie nicht mit der Migration des „Core Ledger“. Wählen Sie periphere Funktionen mit hohem Kundeneinfluss, aber geringem systemischen Risiko, wie das Digitale Onboarding oder die Saldoanzeige. Nutzen Sie Domain-Driven Design (DDD), um diese Kontexte zu isolieren.
Phase 2: Implementierung der Facade
Bevor Sie auch nur eine Zeile Code für den neuen Microservice schreiben, platzieren Sie das API-Gateway vor dem Monolithen. Anfangs fungiert das Gateway als einfacher Pass-Through-Proxy (100 % des Traffics zum Legacy-System). Dies ermöglicht:
- Die Normalisierung der Authentifizierung (z. B. Wechsel von proprietären Protokollen zu OAuth2/OIDC).
- Sofortige Observability (Beobachtbarkeit) des bestehenden Traffics.
Phase 3: Entwicklung und Shadow Traffic
Entwickeln Sie den neuen Microservice auf GKE. Anstatt ihn sofort zu aktivieren, nutzen Sie eine Strategie des Shadowing (oder Dark Launching). Die Facade dupliziert den eingehenden Traffic: Eine Anfrage geht an den Mainframe (der dem Benutzer antwortet), die andere an den Microservice (der die Anfrage verarbeitet, dessen Antwort jedoch verworfen oder zum Vergleich protokolliert wird).
Dies ermöglicht die Überprüfung der Korrektheit der Geschäftslogik des neuen Dienstes anhand realer Daten, ohne den Kunden zu beeinträchtigen.
4. Das Problem der Datenkonsistenz: Dual-Write und CDC
Die größte Herausforderung bei der Legacy-zu-Microservices-Migration im Bankwesen ist das Datenmanagement. Während des Übergangs müssen die Daten sowohl in der DB2 des Mainframes als auch in der neuen Cloud-Native-Datenbank (z. B. Cloud Spanner oder Cloud SQL) liegen und synchronisiert werden.
Warum synchrones Dual-Write vermieden werden sollte
Die Anwendung gleichzeitig in beide Datenbanken schreiben zu lassen, ist ein verteiltes Anti-Pattern. Wenn das Schreiben auf GKE erfolgreich ist, aber auf dem Mainframe fehlschlägt, entsteht eine schwerwiegende Inkonsistenz.
Die Lösung: Change Data Capture (CDC)
Der empfohlene Ansatz sieht die Verwendung einer asynchronen Event-Pipeline vor:
- Der Microservice schreibt in seine eigene Datenbank.
- Ein CDC-Konnektor (z. B. Debezium oder native GCP-Tools wie Datastream) erfasst die Änderung.
- Das Ereignis wird auf einem Message Bus veröffentlicht (Kafka oder Pub/Sub).
- Ein Worker konsumiert das Ereignis und aktualisiert den Mainframe (oder umgekehrt, je nachdem, wer in dieser Phase Owner der Daten ist).
Dies garantiert die Eventual Consistency (letztendliche Konsistenz). Für kritische Operationen, bei denen die Konsistenz sofort gegeben sein muss, kann das SAGA-Pattern evaluiert werden, was jedoch die Komplexität erheblich erhöht.
5. Automatisches Release und Rollback
Sobald der Microservice im Shadow-Modus validiert wurde, erfolgt der progressive Release (Canary Release).
Konfiguration des Traffic Splitting
Konfigurieren Sie das API-Gateway so, dass ein minimaler Prozentsatz des Traffics (z. B. 1 % oder nur interne Benutzer) an den neuen Service auf GKE geleitet wird.
Strategie für automatisiertes Rollback
In einer Bankenumgebung ist ein manuelles Rollback zu langsam. Implementieren Sie fortgeschrittene Gesundheitsprüfungen:
- Business-Metriken: Wenn die Konversionsrate (z. B. Kontoeröffnungen) beim neuen Service drastisch sinkt, muss das Rollback automatisch ausgelöst werden.
- Latenz und Fehler: Wenn die Latenz den Schwellenwert (SLA) überschreitet oder 5xx-Fehler zunehmen, muss das Gateway sofort 100 % des Traffics auf den Mainframe zurücksetzen.
6. Verwaltung von Legacy-Abhängigkeiten
Oft benötigt der neue Microservice Daten, die noch im Monolithen liegen und nicht migriert wurden. In diesem Fall muss der Monolith interne APIs bereitstellen (oder über JDBC/ODBC durch eine Abstraktionsschicht abgefragt werden), um diese Daten dem Microservice zur Verfügung zu stellen. Es ist entscheidend, die zusätzliche Last, die diese Aufrufe auf dem Mainframe erzeugen, zu überwachen, um eine Sättigung der verfügbaren MIPS zu vermeiden.
Fazit
Die Legacy-zu-Microservices-Migration mittels Strangler-Fig-Pattern ist kein „einmaliges Projekt“, sondern ein kontinuierlicher Refactoring-Prozess. Für Banken verwandelt dieser Ansatz ein existenzielles Risiko (technologische Obsoleszenz) in einen Wettbewerbsvorteil, der es ermöglicht, neue Funktionen für Onboarding oder Sofortzahlungen zu veröffentlichen, während das Backend schrittweise saniert wird. Der Schlüssel zum Erfolg liegt nicht nur in der Technologie (Kubernetes, Kafka), sondern in der operativen Disziplin, die hybride Phase mit totaler Observability und automatisierten Sicherheitsmechanismen zu verwalten.
Häufig gestellte Fragen
Das Strangler-Fig-Pattern ist eine Strategie zur architektonischen Modernisierung, die ein monolithisches Legacy-System schrittweise ersetzt. Anstatt einer sofortigen kompletten Neuschreibung wird das alte System mit einer neuen Struktur umhüllt, wobei Aufrufe über eine Facade abgefangen und progressiv an neue Microservices umgeleitet werden. Dieser Ansatz reduziert drastisch die typischen operativen Risiken im Bankensektor und garantiert die Servicekontinuität, während das alte System Stück für Stück außer Betrieb genommen wird.
Das Management der Datenkonsistenz ist kritisch und sollte sich nicht auf synchrones Dual-Write verlassen, da dies zu Diskrepanzen führen kann. Die empfohlene Lösung sieht die Nutzung von Change Data Capture (CDC) in Kombination mit einer asynchronen Event-Pipeline vor. Spezifische Tools erfassen Änderungen in der Quelldatenbank und veröffentlichen sie auf einem Message Bus, was eine Aktualisierung des Sekundärsystems nahezu in Echtzeit ermöglicht und Eventual Consistency garantiert, ohne Transaktionen zu blockieren.
Die Big-Bang-Methode, die den sofortigen Austausch des gesamten Systems vorsieht, birgt historisch gesehen hohe Fehlerraten und inakzeptable Risiken für Serviceunterbrechungen oder Datenverlust. Im Gegensatz dazu ermöglicht die schrittweise Migration, inkrementell Wert zu liefern, beginnend mit Funktionen geringen Risikos. Diese Methode erlaubt es, neue Architekturen auf Kubernetes mit begrenztem realen Traffic zu testen, was die automatische Wiederherstellung im Falle von Anomalien erleichtert.
Shadow Traffic oder Dark Launching ist eine fundamentale Technik, um die Geschäftslogik neuer Services zu validieren, ohne den Endkunden zu beeinträchtigen. Das API-Gateway dupliziert die eingehende Anfrage und sendet sie sowohl an das Legacy-System als auch an den neuen Microservice. Während die Antwort des Legacy-Systems an den Benutzer gesendet wird, wird die des Microservices verworfen oder nur zum Vergleich analysiert. Dies ermöglicht die Überprüfung der Korrektheit und Performance des neuen Codes mit realen Produktionsdaten vor dem eigentlichen Release.
Das API-Gateway oder die Facade fungiert als einziger Einstiegspunkt und spielt die entscheidende Rolle bei der Verteilung des Traffics zwischen dem alten Monolithen und den neuen Microservices. Indem es vor dem bestehenden System platziert wird, bevor neuer Code geschrieben wird, ermöglicht es die Normalisierung der Authentifizierung und bietet sofortige Sichtbarkeit des Traffics. Es ist die Komponente, die die schrittweise Umleitung von Anfragen und das Management von Release-Strategien wie dem Canary Release ermöglicht.
Quellen und Vertiefung
- Wikipedia: Definition und Funktionsweise des Strangler-Fig-Patterns (Englisch)
- BaFin: Bankaufsichtliche Anforderungen an die IT (BAIT) für Finanzinstitute
- NIST Special Publication 800-204: Sicherheitsstrategien für Microservices-Architekturen
- Wikipedia: Grundlagen und Architekturprinzipien von Microservices
Fanden Sie diesen Artikel hilfreich? Gibt es ein anderes Thema, das Sie von mir behandelt sehen möchten?
Schreiben Sie es in die Kommentare unten! Ich lasse mich direkt von Ihren Vorschlägen inspirieren.