Sidecar-Architektur: Smarte Legacy-Moderne mit CDC & API – drei Experten erklären die Ansätze
AI-generated
Während für die Echtzeit-Synchronisation Change Data Capture (CDC) bevorzugt wird, ergänzen minimale Core-Erweiterungen und Middleware wie Kafka das Vorgehen. Eine Kombination aus CDC, Events, APIs und Batch-Verfahren minimiert laut den Experten das operative Risiko. Dieser Ansatz dient als Basis für das Strangler-Fig-Pattern, um Funktionalitäten sukzessive auf moderne Cloud-Strukturen zu übertragen.
Björn Lehnhardt ist Managing Director bei Zühlke Deutschland (Webseite) und leitet das Geschäftsfeld Banken und Versicherungen. Zuvor war er unter anderem bei GFT Technologies mit Verantwortung für die Branchen Financial Services und Industry.Architektur statt Trends: Wie Daten-Ownership die Migration bestimmt
von Björn Lehnhardt, Zühle
Die Wahl des richtigen Synchronisierungsmusters hängt weniger von technologischen Trends ab als von grundlegenden architektonischen Fragen: Wem gehören welche Daten? Ist die Synchronisierung uni- oder bidirektional? Wie aktuell müssen die Daten sein – und wie viel operatives Risiko kann das Altsystem verkraften?
CDC: Stark bei Echtzeit-Entkopplung
Change Data Capture (CDC) ist oft der überzeugendste Ansatz, wenn Änderungen nahezu in Echtzeit weitergegeben werden müssen und das Legacy-System möglichst wenig belastet werden soll. CDC hält das neue System vom alten Kern unabhängig und passt gut zu einer Strangler-Fig-Strategie, bei der das neue System schrittweise Verantwortung übernimmt. Besonders stark ist CDC dort, wo das Sidecar neue Produkte oder Services ermöglicht, die das Altsystem nur schwer unterstützen kann.
Allerdings ist CDC kein Allheilmittel: Was CDC aus dem Datenbanklog ausliest, sind oft kleinteilige Zeilenänderungen – keine inhaltlich verwertbaren Ereignisse. Außerdem braucht CDC eine saubere Erstbefüllung. Das ist keineswegs trivial: Monitoring, der Umgang mit von Fehlern und Eventual Consistency müssen von Beginn an eingeplant werden.
APIs und Batch als ergänzende Muster
APIs sind das bessere Mittel, wenn es um eine fachliche Koordination geht, etwa dort, wo Prozesse explizit gesteuert oder Eingaben geprüft werden müssen. Wenn stündlich oder täglich aktualisierte Daten ausreichen, kann auch eine Batch-Synchronisierung eine valide Lösung sein, die deutlich kostengünstiger in Umsetzung und Betrieb ist.
Fazit: Bewusste Kombination statt Einheitslösung
Wovon wir dringend abraten, ist eine bidirektionale Synchronisierung: Klare Ownership-Grenzen nach Domäne oder Migrationswelle machen die Architektur wesentlich beherrschbarer. In der Praxis empfehlen wir oft eine bewusste Kombination – CDC für eine latenzarme Entkopplung, APIs für die fachliche Koordination und Batch dort, wo die Latenz unkritisch ist. Die richtige Architektur bringt Daten-Ownership, Aktualitätsanforderungen und Migrationsstrategie sauber zusammen – und hält dabei das Legacy-Risiko unter Kontrolle.
Armin Warda hilft als Chief Technologist bei Red Hat (Webseite) Unternehmen aus der Finanzbranche, Open-Source-Technologien effizient, sicher und regelkonform einzusetzen. Ein Themenschwerpunkt seiner Arbeit sind Richtlinien wie der Digital Operational Resilience Act (EU-DORA) und der Artificial Intelligence Act (EU-AIA) sowie die Transformation des Zahlungsverkehrs durch neue Instrumente der Geldpolitik, allen voran den digitalen Euro.Synchronisierungsmuster für Legacy-Systeme: Architektonische Leitplanken für CDC, API und Batch
von Armin Warda, Red Hat
Eine Sidecar-Architektur wird in vielen Fällen nicht zu einer nachhaltigen Core-Modernisierung führen, kann aber kurzfristig helfen, neue Banking-Funktionalitäten bereitzustellen, ohne massive Eingriffe in das Legacy-Core-Banking-System vornehmen zu müssen. Ich würde sie daher nicht als Strategie, sondern eher als taktischen Ansatz bezeichnen.
Kurzfristig können Banken durch die Realisierung neuer Funktionen außerhalb der Anwendung – und auch durch die Auslagerung existierender Funktionen – ein Ansteigen der Arbeitslasten auf dem Legacy-System vermeiden. Die Komplexität des Gesamtsystems nimmt jedoch zu, insbesondere wenn im Laufe der Zeit mehrere Sidecars an den Legacy-Core angedockt werden.
Bei selbst entwickelten Legacy-Core-Banking-Systemen hat sich als Architekturmuster zum Andocken von Sidecars, die mit moderner Cloud-nativer Technologien realisiert sind, ein ereignisgesteuerter Ansatz bewährt, vor allem für die Aktualisierung der Datenhaltung des Sidecars:
Im Quelltext des Legacy-Core-Systems werden minimale Erweiterungen vorgenommen, um Events an das Sidecar-System zu übertragen. Dazu müssen im Core genau die Stellen identifiziert werden, an denen Ereignisse auftreten oder verarbeitet werden oder Datenänderungen stattfinden, die für das Sidecar relevant sind.
Der Event-Stream wird über eine Cloud-native Middleware geleitet und persistiert, was auch die Nachvollziehbarkeit in Fehlersituationen und die Wiederanlauf-Fähigkeit nach Ausfällen sicherstellt. Hier hat sich der Einsatz von Apache Kafka bewährt, das sich hochverfügbar und hochskalierbar auf Kubernetes-basierten Enterprise-Anwendungsplattformen wie Red Hat OpenShift einsetzen lässt.
Das Sidecar-System verarbeitet die relevanten Events, triggert entsprechende Verarbeitungen und aktualisiert seine eigene Datenhaltung.
Im umgekehrten Fall, wenn eine Verarbeitung im Sidecar beginnt und das Legacy-Core-Banking-System eingebunden werden muss, das immer noch als primäres System of Record dient, können meist dessen bestehende Schnittstellen genutzt werden. Ebenfalls kann hier ein API-Gateway hilfreich sein, um beispielsweise Schnittstellenformate zu übersetzen.
Ein großer Vorteil eines solchen ereignisgesteuerten Ansatzes ist, dass die Verarbeitungslogik des Legacy-Systems durch die vorgenommenen Ergänzungen zum Weiterleiten der Events nicht verändert wird und die lose Kopplung des Legacy-Core-Systems an das Sidecar-System bei Störungen die Verfügbarkeit und Performance des Core-Systems weniger beeinträchtigt.
Zusätzlich zur beschriebenen Integration des Sidecars über Events und vorhandene Schnittstellen sollten Unternehmen aber auch Batch-Jobs für den Abgleich der Datenhaltung im Legacy Core und im Sidecar einsetzen. Regelmäßig ausgeführt, etwa einmal pro Nacht oder vor und nach der bankentypischen Tagesendverarbeitung, sorgen sie dafür, dass Datenschiefstände nicht lange unentdeckt bleiben. Unternehmen können sie dann umgehend korrigieren und die Ursachen analysieren.
Sven Oldenburg ist Direktor Core Banking bei der adesso (Webseite) und seit über 30 Jahren im Finanz- und Bankenumfeld tätig. Der diplomierte Wirtschaftsinformatiker (FH) begleitet Banken im In- und Ausland bei der Migration und Modernisierung ihrer Kernbanksysteme – von der Strategie über die Implementierung bis zum stabilen Betrieb. Legacy-Synchronisierung: Strategische Muster für eine moderne Banken-Architektur
von Sven Oldenburg, adesso
Aus unserer Sicht ist die Sidecar-Architektur heute der bevorzugte Ansatz zur Modernisierung alter Legacy-Systeme. Sie erlaubt es, Innovationen schnell neben dem Legacy-Kern aufzubauen, ohne sofort eine risikoreiche Vollablösung zu erzwingen.
Die entscheidende Frage ist dann: Wie werden Daten zwischen altem Kern und neuem Sidecar synchron gehalten, ohne sich neue technische Schulden durch inkonsistente Daten einzufangen? Es gibt kein universelles „Richtig“, aber in der Praxis eine klare Tendenz zu einer Sidecar-Architektur, in der das Legacy-System zunächst System of Record bleibt und das Sidecar Schritt für Schritt mehr Verantwortung übernimmt (Strangler-Fig-Pattern). Für die Kopplung sehe ich drei Muster:
Event-Driven Architecture via Change Data Capture (CDC)
CDC ist für mich in etwa 80 Prozent der Fälle der Standard. Tools wie z.B. Debezium leiten Datenänderungen aus der Legacy-Datenbank ab und publizieren sie als Events, typischerweise in Kafka. Das hat klare Vorteile. Es geschieht Near-Realtime, verursacht minimale Zusatzlast auf dem Altsystem und gelingt meist ohne Code-Änderungen. Die Herausforderung ist dabei, dass die Daten zunächst „nackt“ sind. Das fachliche Domänenmodell entsteht erst im Sidecar. Aus meiner Sicht ist das aber eher ein Feature statt Problem.
API-basierte Koexistenz
Über REST oder SOAP bleibt die Business-Logik des Legacy-Systems inklusive Validierungen erhalten. Der Preis ist eine harte Laufzeitkopplung: Ist der Kern langsam oder nicht verfügbar, leidet das Sidecar mit.
Batch / Database-Mirroring
Für Reporting und Migrationen ist dieses Muster in Ordnung, für interaktive Sidecars wegen Daten-Staleness und Konfliktgefahr, etwa bei Prozessabhängigkeiten, jedoch ungeeignet.
Ich rate, Sidecar plus CDC als Default zu nutzen und APIs nur dort, wo Fachlogik im Kern bleiben muss. Entscheidend sind Stateful Events – sonst wird das Sidecar am Ende doch wieder zum dünnen Proxy vor den Legacy-APIs.dk
Sie finden diesen Artikel im Internet auf der Website:
https://itfm.link/242572
Schreiben Sie einen Kommentar