Altsysteme modernisieren: Strangler Fig und schrittweise Migration

Was ein System zum Altsystem macht

Ein Altsystem ist nicht einfach ein altes System. Es ist ein System, das noch etwas Wertvolles leistet, oft etwas, ohne das die Organisation nicht arbeiten könnte, das aber schwer, riskant oder teuer zu ändern geworden ist. Michael Feathers gab in Working Effectively with Legacy Code (2004) eine bewusst provokante Definition: Legacy-Code ist Code ohne Tests, weil ohne Tests jede Änderung ein Glücksspiel ist. Weitere häufige Ursachen sind knappe Fachkenntnisse (eine Sprache oder Plattform, die nur noch wenige beherrschen), nicht mehr unterstützte Technologie (ein Betriebssystem oder eine Datenbank nach dem Support-Ende des Herstellers), verlorenes Wissen (die Personen, die das Design verstanden, sind gegangen) und angesammelte technische Schulden in der Struktur selbst, die teure Art, die in Abschnitt 1.7 beschrieben ist.

Man sollte offen sagen, dass die meisten Altsysteme erfolgreiche Systeme sind. Sie haben überlebt, weil sie funktionierten und Geld verdienten. Dieser Erfolg ist auch der Grund, warum sie schwer zu ersetzen sind: Jahre realer Nutzung haben Tausende kleiner Entscheidungen, Fixes und Geschäftsregeln eingebettet, die nirgends aufgeschrieben sind, außer im Code und in den Gewohnheiten der Menschen, die ihn nutzen.

Modernisierung braucht daher einen Grund, der sich in geschäftlichen Begriffen ausdrücken lässt. Gute Gründe sind: Kosten oder Risiko von Änderungen blockieren wichtige Geschäftsziele; die Plattform verliert den Herstellersupport oder Sicherheitspatches; die Fachkenntnisse für ihre Wartung sind bald nicht mehr verfügbar; die Betriebskosten stehen in keinem Verhältnis zum Wert; oder das System kann neue Anforderungen an Skalierung, Verfügbarkeit oder Regulierung nicht erfüllen. Schwache Gründe sind Mode, Langeweile und der Glaube, neue Technologie sei automatisch besser. Abschnitt 11.8 zeigt, wie aus einem guten Grund ein Business Case wird.

Warum Neuentwicklungen scheitern

Die naheliegende Reaktion auf ein schmerzhaftes altes System ist, von vorn zu beginnen. Im April 2000 veröffentlichte Joel Spolsky den Essay „Things You Should Never Do, Part I“ und argumentierte, die Entscheidung, von Grund auf neu zu schreiben, gehöre zu den schlimmsten strategischen Fehlern, die ein Softwareunternehmen machen kann. Sein Beispiel war Netscape, dessen Browser fast drei Jahre lang ohne großes Release blieb, während der Code neu geschrieben wurde, und in dieser Zeit eroberten Wettbewerber den Markt. Sein Kernpunkt betraf Wissen: Alter Code wirkt unordentlich, auch weil er Jahre an Bugfixes für Situationen enthält, an die sich niemand erinnert, und wer ihn wegwirft, wirft auch diese Fixes weg.

Die Gründe, warum eine Big-Bang-Neuentwicklung scheitert, sind inzwischen gut verstanden. Der Wert kommt erst am Ende, sodass das Geschäft Monate oder Jahre wartet und die Geduld verliert. Das alte System ändert sich weiter, während das neue gebaut wird; das Ziel verschiebt sich also, und die Organisation friert entweder das alte System (und damit das Geschäft) ein oder bezahlt dafür, jede Änderung zweimal umzusetzen. Verborgenes Verhalten wird übersehen, weil niemand jede Regel auflisten kann, die das alte System durchsetzt. Schätzungen sind optimistisch, weil die sichtbaren Features nur einen Bruchteil der tatsächlichen Arbeit ausmachen. Die Datenmigration und die Umstellung werden bis zum Ende aufgeschoben, wenn sie am schwierigsten und riskantesten sind. Und das Team spaltet sich in eine angesehene Gruppe für das neue System und eine demoralisierte Gruppe für das alte. Fred Brooks’ Second-System-Effekt aus The Mythical Man-Month (1975) fügt ein weiteres Risiko hinzu: Wer ein bekanntes System ersetzt, neigt dazu, das neue mit jeder Idee zu überladen, die im alten keinen Platz hatte.

Große Migrationen, die in einem Schritt umstellen, können auch sehr öffentlich scheitern. Im April 2018 verlagerte die britische Bank TSB ihre Kundendaten und Dienste auf eine neue IT-Plattform; die Plattform hatte sofort ernste Probleme, alle Filialen und ein erheblicher Teil der 5,2 Millionen Kunden waren betroffen, und die Bank kehrte erst im Dezember 2018 zum Normalbetrieb zurück. Im Dezember 2022 verhängten die Financial Conduct Authority und die Prudential Regulation Authority gegen TSB Geldbußen von insgesamt £48,65 Millionen, weil die Bank die Migration nicht angemessen geplant, organisiert und gesteuert und die Risiken ihres ausgelagerten Dienstleisters nicht beherrscht hatte.

Nicht alle Fachleute halten Neuentwicklungen für immer falsch. Eine Neuentwicklung kann die richtige Wahl sein, wenn das System klein ist, sein Verhalten gut spezifiziert und durch Tests abgedeckt ist, die Plattform wirklich in einer Sackgasse steckt oder sich das Geschäft selbst so stark verändert hat, dass das alte Verhalten nicht mehr gewünscht ist. Selbst dann werden die sichersten Neuentwicklungen schrittweise geliefert, mit altem und neuem System nebeneinander, und genau darum geht es im Rest dieses Abschnitts.

Migrationsstrategien: die Rs

Wenn eine Organisation ein ganzes Anwendungsportfolio überprüft, etwa vor dem Auszug aus einem Rechenzentrum, braucht sie ein Vokabular, um zu entscheiden, was mit jeder Anwendung geschehen soll. Gartner beschrieb Anfang der 2010er-Jahre fünf solcher Optionen. 2016 veröffentlichte Stephen Orban von AWS sechs Strategien, und AWS ergänzte später eine siebte; daraus ergeben sich die sieben Rs, die heute in den Migrationsleitfäden von AWS verwendet werden. Andere Cloud-Anbieter und Beratungen nutzen ähnliche Listen mit leicht abweichenden Namen. Die Liste ist vor allem als Erinnerung nützlich, dass Neubau nur eine von mehreren Optionen ist, und meist die teuerste.

Das Strangler-Fig-Muster

Martin Fowler benannte das am weitesten verbreitete schrittweise Muster nach den Würgefeigen (Strangler Figs), die er 2001 in den Regenwäldern von Queensland sah: Kletterpflanzen, die in den Ästen eines Wirtsbaums keimen, bis zum Boden hinunterwachsen und den Wirt allmählich umschließen, bis er abstirbt und die Feige allein steht. Er beschrieb es erstmals 2004 als Strangler Application, benannte es später in Strangler Fig Application um und überarbeitete den Artikel 2024 grundlegend. Die Softwareversion, meist einfach Strangler Fig genannt, hält das alte System am Laufen, während neue Komponenten um es herum wachsen und sein Verhalten Stück für Stück übernehmen, bis das alte System nichts mehr tut und abgeschaltet werden kann.

Der Mechanismus hat drei Teile. Erstens wird vor das Altsystem eine Abfangschicht gesetzt: ein Reverse Proxy, ein API-Gateway oder eine Routing-Fassade, durch die alle Anfragen laufen. Anfangs schickt sie alles an das alte System und ändert nichts. Zweitens wird ein Slice von Verhalten entlang einer Naht gewählt (in Feathers’ Begriffen eine Stelle, an der sich Verhalten umleiten lässt, ohne viel vom alten Code zu ändern), als neue Komponente neu gebaut und durch Ändern einer Routing-Regel aktiviert, meist zunächst für einen kleinen Teil des Verkehrs. Drittens wiederholt sich der Vorgang, bis das Altsystem nichts mehr verarbeitet; dann wird es stillgelegt. Die ganze Zeit über macht die Routing-Schicht jeden Schritt umkehrbar: Verhält sich die neue Komponente falsch, wird die Regel zurückgeschaltet.

Der Code, der Alt und Neu nebeneinander existieren lässt (die Routing-Fassade, Adapter, Jobs zur Datensynchronisation), ist Übergangsarchitektur: Software, die gebaut wird, um weggeworfen zu werden. Teams sträuben sich oft dagegen, sie zu schreiben, weil es sich nach Verschwendung anfühlt. Fowlers Argument und die Erfahrung dahinter lauten, dass dieser Aufwand ein geringeres Risiko und viel früheren Nutzen erkauft, was fast immer ein guter Tausch ist. Die eigentliche Gefahr ist das Gegenteil: eine Migration, die auf halbem Weg steckenbleibt und beide Systeme samt dem gesamten Übergangscode auf unbestimmte Zeit in der Produktion zurücklässt. Jeder Slice sollte daher etwas aus dem alten System entfernen, und der Fortschritt sollte daran gemessen werden, was abgeschaltet wurde, nicht nur daran, was gebaut wurde.

Ian Cartwright, Rob Horn und James Lewis von Thoughtworks haben eine Familie verwandter Techniken als Patterns of Legacy Displacement auf martinfowler.com dokumentiert (ab 2021). Sie beschreiben die Arbeit als vier Tätigkeiten, die keine feste Reihenfolge haben: die gewünschten Ergebnisse verstehen, das Problem in Teile zerlegen, diese Teile schrittweise liefern und die Organisation so verändern, dass das neue System nicht so verfällt wie das alte. Sie hinterfragen auch den Reflex, jedes Feature nachzubauen: Ein Großteil des Verhaltens eines Altsystems wird vielleicht nicht mehr gebraucht, und das herauszufinden ist günstiger, als es neu zu bauen.

Branch by Abstraction

Das Strangler-Fig-Muster wirkt am Rand eines Systems, wo sich Anfragen routen lassen. Manche Ersetzungen müssen tief in einer einzigen Codebasis stattfinden: der Austausch eines Persistenz-Frameworks, einer Preis-Engine oder einer selbst gebauten Messaging-Schicht, die Hunderte von Aufrufstellen nutzen. Branch by Abstraction, ein Name, den Paul Hammant prägte, als er für Trunk-Based Development warb, und den Martin Fowler 2014 beschrieb, leistet das ohne langlebigen Branch in der Versionsverwaltung. Das System bleibt in jedem Schritt releasefähig, sodass sich die Änderung über Wochen oder Monate verteilen lässt, während auf derselben Hauptlinie andere Arbeit weitergeht.

Gleichwertigkeit nachweisen: Parallelbetrieb und Dark Launching

Die schwierigste Frage jeder Migration ist, ob sich die neue Implementierung wirklich wie die alte verhält. Ein Parallelbetrieb beantwortet sie mit Belegen aus der Produktion: Beide Implementierungen erhalten dieselben Eingaben, die alte bleibt maßgeblich, und ihre Antwort wird an den Nutzer zurückgegeben, während die beiden Ergebnisse verglichen und alle Abweichungen festgehalten werden. GitHub veröffentlichte 2016 genau dafür seine Bibliothek Scientist, die einen Control- und einen Candidate-Pfad nebeneinander ausführt und Abweichungen meldet; ähnliche Werkzeuge gibt es für viele Sprachen, und die Technik lässt sich leicht von Hand schreiben, wie die Skizze unten zeigt.

Dark Launching, das Fowler als Aufruf neuen Backend-Verhaltens in der Produktion beschreibt, ohne dass Nutzer seine Auswirkungen sehen, ist eng verwandt. Es dient vor allem dazu, Performance und Stabilität des neuen Pfads unter echter Last zu testen, bevor ein Nutzer davon abhängt, während sich ein Parallelbetrieb auf die Korrektheit konzentriert. Beide unterscheiden sich von einem Canary Release, bei dem ein kleiner Teil der Nutzer das neue Verhalten tatsächlich erhält.

Beide Techniken haben Tücken. Der Candidate darf keine nach außen sichtbaren Nebenwirkungen haben: Er darf keine zweite E-Mail senden, keine Karte doppelt belasten und nicht in die gemeinsame Datenbank schreiben; Parallelbetrieb ist daher bei Lesezugriffen und Berechnungen am einfachsten, und Schreibzugriffe brauchen eine Sandbox oder einen separaten Speicher. Vergleiche müssen legitime Unterschiede wie Zeitstempel, Reihenfolge und Gleitkommaformatierung ignorieren, sonst geht der Abweichungsbericht im Rauschen unter. Und beide Pfade auszuführen kostet Kapazität, weshalb der Anteil des stichprobenartig geprüften Verkehrs oft begrenzt wird.

def quote_delivery_fee(order):
    old = legacy_pricing.quote(order)          # still authoritative
    try:
        new = new_pricing.quote(order)         # must have no side effects
        if new.amount_pence != old.amount_pence:
            metrics.increment("pricing.mismatch")
            log.info("pricing mismatch", order_id=order.id,
                     old=old.amount_pence, new=new.amount_pence)
        else:
            metrics.increment("pricing.match")
    except Exception:
        metrics.increment("pricing.candidate_error")   # never hurts the user
    return old

Daten: der schwierigste Teil

Anfragen zu routen ist relativ einfach; Daten zu verlagern und konsistent zu halten, während zwei Systeme gemeinsam für sie zuständig sind, ist der Punkt, an dem die meisten Migrationen kämpfen. Die erste Regel ist die aus Kapitel 7 zur Datenhoheit: Für jede Art von Daten muss das Team in jeder Phase der Migration sagen können, welches System das System of Record ist, welche Kopien existieren und wie veraltet jede sein darf. Das Diagramm unten zeigt den typischen Wechsel: Zuerst besitzt das Altsystem die Daten, und die neue Komponente liest eine Kopie; später besitzt die neue Komponente sie, und das Altsystem erhält eine Kopie für die Module, die sie noch brauchen.

Change Data Capture ist der übliche Weg, Daten aus einer Legacy-Datenbank zu kopieren, ohne den Legacy-Code zu ändern: Ein Werkzeug wie Debezium liest das Transaktionslog der Datenbank und veröffentlicht jede Änderung als Event, derselbe Mechanismus, den Abschnitt 6.7 zum Weiterleiten einer Outbox verwendet hat. Event Interception, eines der Muster zur Ablösung von Altsystemen, setzt am anderen Ende an: Es fängt zustandsändernde Anfragen oder Nachrichten auf dem Weg in das Altsystem ab und leitet Kopien (oder später die Originale) an die neue Komponente weiter. In beiden Fällen gilt: Lassen Sie niemals beide Systeme unabhängig voneinander Schreibzugriffe auf dieselben Daten mit Zwei-Wege-Synchronisation annehmen, es sei denn, Sie haben keine Alternative; Konflikte sind dann nahezu garantiert.

Legacy-Daten passen selten zum neuen Modell. Statuscodes sind Ganzzahlen mit undokumentierter Bedeutung, eine Tabelle dient drei Zwecken, und Datumsangaben sind in Ortszeit gespeichert. Ein Anti-Corruption Layer, das Muster aus dem Domain-Driven Design, das ein Modell vor dem eines Nachbarn schützt, übersetzt zwischen beiden, damit die Eigenheiten des Altsystems nicht in den neuen Code durchsickern. Er gehört zur Übergangsarchitektur und sollte mit dem Altsystem verschwinden.

Die abschließende Datenmigration, also die Übernahme der Historie und die Umstellung, verdient einen eigenen Plan. Profilieren Sie zuerst die Legacy-Daten, um Duplikate, verwaiste Datensätze und ungültige Werte zu finden. Schreiben Sie die Abbildung explizit auf und testen Sie sie an einer vollständigen Kopie in Produktionsgröße. Gleichen Sie nach jedem Lauf mit Zeilenzahlen, Summen der Geldspalten und Prüfsummen ab, nicht mit Stichproben. Proben Sie die Umstellung, messen Sie ihre Dauer und schreiben Sie das Rollback auf. Migrieren Sie nach Möglichkeit in Kohorten (eine Region, ein Kundensegment, eine Produktlinie) statt alles auf einmal, damit ein Problem nur einen Bruchteil der Kunden trifft und Sie vor der nächsten Kohorte etwas daraus lernen.

Lehren aus Kill It with Fire

Marianne Bellottis Kill It with Fire: Manage Aging Computer Systems (and Future Proof Modern Ones) (No Starch Press, 2021) schöpft aus ihrer Erfahrung mit der Modernisierung von Behörden- und Unternehmenssystemen, darunter Mainframe-Landschaften. Mehrere seiner Themen lohnt es, in jede Modernisierung mitzunehmen.

Modernisierung sollte durch den Wert, den sie liefert, und das Risiko, das sie beseitigt, begründet werden, nicht durch das Alter der Technologie; alte Technologie, die gut verstanden ist und funktioniert, kann der risikoärmste Teil der Landschaft sein. Technologieentscheidungen verlaufen in Zyklen; ein Team, das ein System nur ersetzt, weil sein Design aus der Mode ist, baut daher wahrscheinlich das Altsystem der nächsten Generation. Die schrittweise Verbesserung des bestehenden Systems ist meist sicherer als ein Ersatz, und eine vollständige Neuentwicklung braucht eine ungewöhnlich starke Begründung. Schließlich ist Modernisierung ebenso ein organisatorisches wie ein technisches Problem: Sie braucht sichtbare frühe Erfolge, um Schwung und Moral zu erhalten, klare Kriterien dafür, wann sie abgeschlossen ist, und Aufmerksamkeit für die Anreize, die das alte System verfallen ließen, sonst folgt ihm das neue.