Legacy-Systeme modernisieren: Schrittweise und risikoarm mit Apache Kafka und Debezium

Inhalt

1. Was Stillstand kostet
2. Warum Big-Bang-Projekte scheitern
3. Das Strangler-Fig-Muster
4. Die Werkzeuge: Apache Kafka und Debezium
5. Die Migration in sechs Schritten
6. Praxisbeispiele
7. Herausforderungen und Risiken
8. Fazit

Was Stillstand kostet

Legacy-Systeme sind nicht nur ein technisches Ärgernis, sondern ein wachsendes Geschäftsrisiko. Die Kosten entstehen in vier Bereichen.

Steigender Wartungsaufwand

Veraltete Systeme binden einen großen Teil des IT-Budgets. Hinzu kommen Ausgaben für knappe Ersatzteile, auslaufende Lizenzen und spezialisierte Fachkräfte. Dieses Budget fehlt für Innovation.

Starre Strukturen und Datensilos

Legacy-Systeme lassen sich nur mit großem Aufwand an neue Anforderungen anpassen. Wichtige Daten bleiben in isolierten Systemen gefangen und stehen anderen Bereichen, Analysen oder KI-Anwendungen nicht zur Verfügung.

Sicherheitsrisiken

Systeme ohne Herstellersupport erhalten keine Sicherheitsupdates mehr. Jede bekannte Schwachstelle bleibt offen und erhöht das Risiko von Datenverlust, Betriebsunterbrechungen und Verstößen gegen regulatorische Anforderungen.

Abhängigkeit von wenigen Fachkräften

Das Wissen über alte Technologien und schlecht dokumentierte Systeme liegt oft bei wenigen Personen. Verlassen sie das Unternehmen oder gehen in den Ruhestand, steigt das operative Risiko deutlich.

Diese Faktoren verstärken sich gegenseitig: Hohe Wartungskosten verdrängen Investitionen, fehlende Investitionen schwächen die Wettbewerbsfähigkeit, und knappe Fachkräfte verteuern den Betrieb weiter. Je länger ein Unternehmen wartet, desto aufwendiger wird die Modernisierung.

Warum Big-Bang-Projekte scheitern

Der naheliegende Ausweg ist oft eine vollständige Neuentwicklung, die das Altsystem zu einem Stichtag ablöst. Genau dieser Ansatz ist besonders riskant. Eine Erklärung liefert der Systemtheoretiker John Gall, über dessen Werk wir in unserem Beitrag zu Systemantics ausführlicher schreiben.

Gall’s Law

Ein funktionierendes komplexes System ist ausnahmslos aus einem funktionierenden einfachen System hervorgegangen. Ein von Grund auf neu entworfenes komplexes System funktioniert nie und lässt sich auch nicht nachträglich zum Laufen bringen.

Komplexe Systeme enthalten zahlreiche unbekannte Abhängigkeiten, die sich bei einem Neuentwurf nicht vollständig vorhersehen lassen. Ein System, das erst am Ende eines langen Projekts auf die Realität trifft, versagt daher häufig auf unerwartete Weise. Ein bekanntes Beispiel ist die Digital Media Initiative der BBC, die 2013 nach Jahren der Entwicklung eingestellt wurde.

Konsequenz für Investitionsentscheidungen

Gall’s Law ist nicht nur eine Regel für Entwicklungsteams, sondern auch ein Prinzip für das Risikomanagement:

• Big Bang: Eine hohe Vorabinvestition beruht auf Annahmen über einen zukünftigen Zielzustand, die sich später oft als unvollständig erweisen.
• Evolutionärer Ansatz: Die erste Investition fließt in einen kleinen, funktionierenden Baustein. Jede weitere Stufe baut auf nachgewiesenen Ergebnissen auf.

Die entscheidende Frage lautet damit nicht mehr „Was kostet das neue System insgesamt?“, sondern „Was kostet der nächste Schritt, der nachweisbar Nutzen stiftet?“.

Das Strangler-Fig-Muster

Das Strangler-Fig-Muster, bekannt gemacht von Martin Fowler, ist die praktische Umsetzung dieses Gedankens für die Modernisierung von Legacy-Systemen.

Das Prinzip

Der Name leitet sich von der Würgefeige ab, die um einen Wirtsbaum herumwächst und ihn mit der Zeit ersetzt. Übertragen auf Software bedeutet das:

1. Neue Funktionen entstehen als eigenständige Dienste neben dem Altsystem.
2. Eine vorgeschaltete Routing-Schicht leitet Anfragen schrittweise an die neuen Dienste weiter.
3. Sobald alle Funktionen übernommen sind, wird das Altsystem abgeschaltet.

Big Bang und Strangler Fig im Vergleich

Kriterium	Big-Bang-Neuentwicklung	Strangler-Fig-Muster
Projektrisiko	Hoch: Erfolg oder Misserfolg entscheiden sich zum Umstellungszeitpunkt.	Begrenzt: Jede Änderung ist klein und lässt sich einzeln zurücknehmen.
Vorabinvestition	Hoch: Das Gesamtprojekt muss finanziert werden, bevor Nutzen entsteht.	Gering: Investitionen erfolgen schrittweise und orientieren sich am Ergebnis.
Erster Nutzen	Nach Abschluss des Gesamtprojekts, oft erst nach Jahren.	Mit dem ersten produktiven Dienst, meist nach Wochen oder wenigen Monaten.
Betriebsunterbrechung	Harte Umstellung mit dem Risiko längerer Ausfälle.	Gering: Das Altsystem bleibt in Betrieb, Nutzer werden schrittweise umgestellt.
Feedback	Spät, wenn Kurskorrekturen teuer sind.	Laufend, mit jedem neuen Dienst.

Die Werkzeuge: Apache Kafka und Debezium

Apache Kafka: Entkopplung von Alt und Neu

Apache Kafka ist eine verteilte Plattform für Event-Streaming. Systeme veröffentlichen Ereignisse wie „Bestellung angelegt“, ohne zu wissen, wer sie verarbeitet. Andere Systeme abonnieren diese Ereignisse unabhängig voneinander.

Für die Modernisierung hat das drei Vorteile:

• Entkopplung: Alte und neue Systeme müssen nicht direkt miteinander verbunden sein. Wartungsfenster im Altsystem legen die neuen Dienste nicht still.
• Erweiterbarkeit: Weitere Dienste können dieselben Daten nutzen, ohne das Altsystem erneut anzupassen.
• Verlässlichkeit: Kafka speichert Ereignisse für einen konfigurierbaren Zeitraum. Fällt ein Dienst aus, kann er die verpassten Ereignisse anschließend nachverarbeiten.

Debezium: Datenänderungen ohne Eingriff in die Anwendung erfassen

Debezium setzt Change Data Capture um, also die Erfassung von Datenänderungen direkt an der Quelle. Es liest das Transaktionsprotokoll der Datenbank, das die Datenbank ohnehin führt. Anwendungscode und Datenbankschema des Altsystems bleiben unverändert. Je nach Datenbank ist lediglich eine Anpassung der Protokollkonfiguration erforderlich.

So werden Einfügungen, Änderungen und Löschungen nahezu in Echtzeit an Kafka übertragen, bei geringer Zusatzlast und ohne das Altsystem zu destabilisieren.

Die Architektur im Überblick

Komponente	Aufgabe
Altsystem und Datenbank	Betreibt weiterhin das Kerngeschäft und ist bis zur Ablösung die führende Datenquelle.
Debezium	Erfasst jede Datenänderung aus dem Transaktionsprotokoll, ohne die Anwendung zu verändern.
Apache Kafka	Nimmt die Änderungen auf und stellt sie allen berechtigten Diensten bereit. Entkoppelt Alt und Neu.
Neue Dienste	Übernehmen einzelne Geschäftsfunktionen auf Basis der Daten aus Kafka und ersetzen das Altsystem schrittweise.

Die Migration in sechs Schritten

1. Den ersten Baustein auswählen

Wählen Sie eine klar abgegrenzte Geschäftsfunktion mit wenigen Abhängigkeiten. Methoden aus dem Domain-Driven Design helfen, geeignete Grenzen zu finden. Der erste Baustein sollte spürbaren Nutzen bringen, aber nicht der kritischste Prozess sein.

2. Datenänderungen mit Debezium erfassen

Ein Debezium-Connector überwacht die Tabellen, die zum gewählten Baustein gehören. Er erstellt zunächst einen konsistenten Ausgangsstand der Daten und überträgt danach laufend alle Änderungen.

3. Kafka als zentrale Datenschicht einrichten

Debezium schreibt die Änderungen in eigene Kafka-Topics, etwa Änderungen der Kundentabelle in ein Topic für Kundendaten. Diese Topics stehen allen berechtigten Diensten zur Verfügung.

4. Den ersten neuen Dienst entwickeln

Ein neuer, schlanker Dienst übernimmt die gewählte Geschäftsfunktion. Er greift nicht auf die Datenbank des Altsystems zu, sondern bezieht seine Daten ausschließlich aus Kafka. So ist die Entkopplung von Beginn an sichergestellt, ganz im Sinne von Gall’s Law: ein einfaches System, das funktioniert.

5. Parallel betreiben und validieren

Die Routing-Schicht leitet zunächst nur lesende Anfragen an den neuen Dienst weiter, während das Altsystem weiterhin alle Schreibvorgänge verarbeitet. So lassen sich Ergebnisse und Leistung mit echtem Produktionsverkehr vergleichen. Nach erfolgreicher Validierung übernimmt der neue Dienst auch die Schreibvorgänge. Ist vorübergehend eine Synchronisation in beide Richtungen nötig, veröffentlicht der neue Dienst seine Änderungen ebenfalls als Ereignisse.

6. Ablösen und wiederholen

Hat sich der neue Dienst bewährt, wird die entsprechende Funktion im Altsystem stillgelegt und die Weiterleitung dauerhaft umgestellt. Der Ablauf beginnt dann mit dem nächsten Baustein und nutzt die bereits aufgebaute Infrastruktur und Erfahrung.

Praxisbeispiele

Netflix: schrittweise zu Microservices

Netflix begann um 2009 damit, seine monolithische Architektur schrittweise in Microservices in der Cloud zu überführen. Die Migration erstreckte sich über mehrere Jahre und erfolgte Dienst für Dienst. So konnte das Unternehmen Skalierungsprobleme lösen, ohne den laufenden Betrieb zu gefährden.

Event-Streaming als Rückgrat großer Plattformen

Apache Kafka wurde ursprünglich bei LinkedIn entwickelt und ist heute bei vielen Unternehmen mit hohen Datenvolumen das zentrale Rückgrat für den Datenaustausch zwischen Systemen. Debezium ist als Open-Source-Projekt breit im Einsatz, um bestehende Datenbanken an solche Plattformen anzubinden.

Herausforderungen und Risiken

Verlagerte Komplexität

Die Komplexität verschwindet nicht, sie verlagert sich: vom Monolithen in ein verteiltes System mit Clustern, Connectoren, Schemaänderungen und Netzwerklatenz. Diese Komplexität ist jedoch beherrschbar. Verwaltete Kafka-Dienste oder Kubernetes-Operatoren wie Strimzi reduzieren den Betriebsaufwand deutlich.

Datenkonsistenz

Während der Übergangsphase müssen Alt- und Neusystem konsistente Daten haben. Gleichzeitige Schreibvorgänge in zwei Systeme sind fehleranfällig. Debezium und Kafka garantieren, dass Ereignisse mindestens einmal und innerhalb einer Partition in der richtigen Reihenfolge zugestellt werden. Für strengere Anforderungen eignet sich das Outbox-Muster: Ein Dienst schreibt seine Daten und das zugehörige Ereignis in einer gemeinsamen Transaktion, und Debezium überträgt das Ereignis zuverlässig weiter.

Organisation und Kompetenzen

Neue Technologien und Arbeitsweisen erfordern Wissen, das im Team oft erst aufgebaut werden muss. Der schrittweise Ansatz hilft auch hier: Ein kleines Pilotteam sammelt Erfahrung, dokumentiert Ergebnisse und gibt das Wissen an weitere Teams weiter.

Fazit

Eine Neuentwicklung in einem Schritt widerspricht grundlegenden Erfahrungen mit komplexen Systemen. Der evolutionäre Weg mit dem Strangler-Fig-Muster, Apache Kafka und Debezium senkt das Risiko, liefert früher Nutzen und lässt sich an jedem Punkt steuern.

Das Ergebnis ist mehr als ein abgelöstes Altsystem. Die Daten und Geschäftslogik, die bisher in einem schwer veränderbaren System gebunden waren, stehen einer modernen, ereignisbasierten Plattform zur Verfügung. Diese Plattform ist die Grundlage für neue Produkte, Datenanalysen und KI-Anwendungen.