Schrittweise Migration und Koexistenz

Schrittweise Migration und Koexistenz

0:00 Wir haben einen migrierten Dienst, der getestet, beobachtbar und betriebsbereit ist. Jetzt kommt die Frage, wie aus einem Piloten eine Migration wird — und wie der Bestand dabei weiterläuft. Das Bild dafür ist über zwanzig Jahre alt und immer noch das beste: die Würgefeige. Sie wächst an ihrem Wirtsbaum hoch, bezieht ihre Nährstoffe, bildet eigene Wurzeln — und erst wenn sie sich selbst trägt, verschwindet der Baum.

0:25 Sie fällt ihn nicht erst und pflanzt sich dann. Genau so sollte eine Anwendungsmodernisierung ablaufen.

Schrittweise Migration und Koexistenz

0:31 Dieses Modul ist die Klammer um alles Vorherige. Es beantwortet die Frage, in welcher Reihenfolge die restlichen siebzehn Anwendungsteile folgen, wie die Datenhoheit geklärt wird, während beide Systeme laufen, und wie der Bestand am Ende tatsächlich verschwindet. Der letzte Punkt ist der, der in Projekten am häufigsten ausfällt.

Umbau im laufenden Betrieb

0:50 Beginnen wir mit dem Muster selbst. Es ist erfreulich einfach zu erklären — und erstaunlich schwer durchzuhalten. Es ist erfreulich einfach zu erklären — und erstaunlich schwer durchzuhalten, weil sein letzter Schritt scheinbar nichts einbringt. Das Muster der Würgefeige beschreibt den schrittweisen Ersatz eines Altsystems: Neue Funktionen entstehen neben dem Bestand, Verhalten wandert Stück für Stück hinüber, und erst wenn nichts mehr auf den alten Teil zeigt, wird er abgebaut.

1:18 Martin Fowler hat es nach Feigen benannt, die an ihrem Wirtsbaum hochwachsen und ihn am Ende ersetzen. Der Reiz des Bildes liegt im Zeitverlauf: Es gibt keinen Tag der Umstellung, sondern eine Phase, in der beides existiert — und in der jederzeit angehalten werden kann. Vier Kästen, und der letzte ist der, den man streichen möchte: Zurückbauen. Anbauen ist attraktiv, Umleiten ist spannend, Übernehmen fühlt sich nach Fortschritt an.

1:42 Der Rückbau bringt scheinbar nichts — es funktioniert ja schon alles. Genau deshalb ist er der Schritt, der am häufigsten unterbleibt, und genau deshalb liegen in vielen Unternehmen alte Anwendungen herum, die niemand mehr braucht und die trotzdem gepflegt, getestet und ausgeliefert werden. Planen Sie den Rückbau als Teil jedes Schritts ein, nicht als Aufräumaktion am Projektende.

2:04 Diese vier Gründe kennen Sie aus Modul vier, hier stehen sie im Zusammenhang. Der erste ist der ökonomische: Der Ersatz braucht Jahre, in denen der Fachbereich weiter Änderungen erwartet — und irgendwann muss man die entweder in beiden Systemen bauen oder eines der beiden Versprechen brechen. Der dritte ist der psychologische: Vieles vorhandene Verhalten wird gar nicht mehr gebraucht, aber niemand traut sich, es wegzulassen.

2:26 Und Punkt vier ist der Grund, warum das schrittweise Vorgehen sich durchsetzt: Aufwand und Nutzen verteilen sich, statt sich an einem Stichtag zu ballen. Vier Voraussetzungen, und die erste ist die technisch anspruchsvollste: eine Naht im Bestand, an der sich ein Teil sauber herauslösen lässt. Genau danach haben wir in Modul sieben gesucht. Punkt drei benennt etwas, das im Projektalltag Widerstand erzeugt: die Übergangsarchitektur.

2:52 Eine Umleitung, ein Abgleich, eine doppelte Rollenpflege — all das wird später wieder abgebaut, und es fühlt sich deshalb nach Verschwendung an. Fowler weist ausdrücklich darauf hin: Es fühlt sich so an, reduziert aber Risiko und liefert früher Wert. Und Punkt vier ist Willenssache. Punkt eins ist der, über den wir gerade gesprochen haben — die eingesparte Übergangsarchitektur.

3:15 Wer sie streicht, bekommt statt einer schrittweisen Migration einen Stichtag zurück, mit allen Risiken. Punkt zwei ist der halbfertige Zustand, der besonders teuer ist: Es wird angebaut, aber nie umgeleitet, und beide Wege bleiben aktiv. Punkt drei betrifft die Zusammenarbeit mit dem Fachbereich: Der Bestand wird eingefroren, obwohl dort weiter Änderungen gebraucht werden — das hält kein Projekt lange durch.

3:39 Und Punkt vier ist die Wiederholung aus Modul vier: technischer statt fachlicher Schnitt.

Daten und Verträge

3:45 Jetzt zum schwierigsten Teil der Koexistenz. Nicht der Code ist das Problem — die Daten sind es. Nicht der Code ist hier das Problem, sondern die Daten. Solange beide Systeme laufen, muss geklärt sein, wem welche Tabelle gehört. Solange beide Systeme laufen, muss klar sein, wer welche Daten besitzt. Es gibt zwei zulässige Antworten: eine gemeinsame Datenbank mit klar getrennter Schreibhoheit, oder ein eigener Bestand für den neuen Dienst, der über Ereignisse abgeglichen wird.

4:15 Beides funktioniert. Was nicht funktioniert, ist Unklarheit — also der Zustand, in dem beide Seiten dieselbe Tabelle schreiben, weil es am Anfang praktisch war. Dieser Zustand erzeugt Fehler, die niemand reproduzieren kann, weil sie vom Zufall der Reihenfolge abhängen. Diese Gegenüberstellung ist eine Abwägung zwischen schnellem Start und sauberem Ende.

4:36 Links, die gemeinsame Datenbank: kein Abgleich nötig, sofort einsatzfähig — aber das Schema bindet beide Seiten aneinander, und jede Änderung muss zu beiden passen. Rechts, getrennte Hoheit: mehr Aufwand am Anfang, dafür können sich beide Schemata unabhängig entwickeln. Für eine kurze Koexistenzphase ist links oft richtig; wenn die Phase Jahre dauern wird, zahlt sich rechts aus.

4:58 Entscheiden Sie das bewusst — und schreiben Sie auf, wie lange die Phase dauern soll. Vier Bestandteile eines Vertrags, der beide Seiten unabhängig macht. Punkt zwei knüpft an Modul zwölf an: Der Sicherheitskontext muss über die Naht hinweg übertragbar sein — sonst weiß der neue Dienst nicht, wer da eigentlich fragt. Punkt drei ist eine Bedingung, die viele Bestandsanwendungen nicht erfüllen: Sitzungszustand darf nicht an einem der beiden Systeme hängen.

5:25 Und Punkt vier ist eine Entwurfsregel für den Ereignisfall: Das Format muss so beschaffen sein, dass beide Seiten es unabhängig voneinander ändern können — sonst haben Sie eine neue, versteckte Kopplung geschaffen. Der rote Faden: festlegen, befristen, vereinbaren, abnehmen, überwachen. Schritt zwei enthält ein wichtiges Wort — lesende Zugriffe der anderen Seite auflisten und befristen.

5:48 Denn ein lesender Zugriff über die Grenze ist verzeihlich, aber er sollte nicht dauerhaft werden. Schritt vier holt den Fachbereich ins Boot: Eine Abgleichsverzögerung von fünf Minuten ist eine fachliche Entscheidung, keine technische. Und wie die Fußzeile sagt, fehlt Schritt fünf fast immer: eine Prüfung, die Abweichungen zwischen beiden Ständen meldet.

6:09 Ohne sie merken Sie stille Divergenz erst, wenn jemand sich beschwert. Punkt eins ist der Zustand, vor dem dieses ganze Kapitel warnt, und er entsteht immer aus demselben Grund: Es war anfangs praktisch. Punkt zwei ist die Wirkung nach außen: Der Fachbereich sieht widersprüchliche Zahlen, und damit verlieren Sie Vertrauen, das schwer zurückzugewinnen ist.

6:29 Punkt drei ist der Sicherheitsbruch an der Naht. Und Punkt vier ist die klassische Endstufe einer schlecht geschnittenen Zerlegung: Aus dem Monolithen entsteht ein verteilter Monolith — dieselben Kopplungen wie vorher, nur jetzt über das Netz und damit langsamer und störanfälliger.

Reihenfolge und Rückbau

6:45 Bleibt die Choreografie. Jeder Schritt braucht einen Weg zurück — und einen Rückbau, der tatsächlich stattfindet. Jeder Schritt braucht einen Weg zurück — und einen Rückbau, der tatsächlich stattfindet und nicht nur im Protokoll steht. Die Reihenfolge der Schritte richtet sich nach Risiko und Abhängigkeit, nicht nach Begeisterung.

7:05 Jeder Schritt hat einen definierten Rückweg, und nach jedem Schritt wird beobachtet, bevor der nächste beginnt — das ist der Takt aus Modul fünfzehn. Am Ende steht der Rückbau, der Teil, der am häufigsten ausfällt. Es ist ein bisschen wie beim Renovieren: Das Gerüst abzubauen ist keine schöne Arbeit und bringt sichtbar nichts.

7:24 Aber solange es steht, kann man das Ergebnis nicht als fertig bezeichnen — und niemand kann sagen, ob noch jemand darauf steht. Die Logik dieser Tabelle: Vier Bestandteile, und jeder braucht einen Beleg. Bemerkenswert ist die letzte Zeile und ihr Beleg — Code entfernt, nicht auskommentiert. Auskommentierter Code ist kein Rückbau; er ist eine Notiz, die niemand liest und die beim nächsten Refactoring stört.

7:48 Der eigentliche Rückweg heißt Versionsverwaltung, dort ist alles aufgehoben. Und wie die Fußzeile sagt: Ohne die letzte Zeile wächst die Anwendung, statt sich zu wandeln. Nach zehn Schritten haben Sie dann zehn neue Dienste und einen unveränderten Monolithen daneben. Vier Gründe, und der erste ist der wirtschaftliche: Ungenutzter Code wird weiter gepflegt, getestet und ausgeliefert — er kostet also dauerhaft, ohne etwas beizutragen.

8:14 Punkt zwei ist der schleichende: Zwei Wege für denselben Vorgang laufen mit der Zeit auseinander, weil eine Korrektur nur an einer Stelle landet. Punkt drei ist ein guter Nebeneffekt: Der Rückbau beweist, dass die Umleitung vollständig war — wenn nach dem Entfernen nichts fehlt, war wirklich alles umgeleitet. Und Punkt vier ist die Zeitfrage: Was heute leicht zu entfernen ist, ist in einem Jahr wieder Bestand.

8:38 Punkt eins ist der häufigste und klingt immer vernünftig: Der alte Weg bleibt für den Notfall erhalten. Nur wird er nie wieder benutzt, nie wieder getestet — und wenn der Notfall käme, würde er vermutlich nicht funktionieren. Ein Rückweg über die Versionsverwaltung ist verlässlicher. Punkt zwei ist der ungeübte Rückweg aus Modul fünf. Punkt drei ist der Analysefehler: Mehrere Schritte gleichzeitig, und Ursachen lassen sich nicht mehr zuordnen.

9:05 Und Punkt vier ist der Taktfehler: Nach dem Umschalten wird sofort weitergearbeitet, ohne zu beobachten.

Übung

9:11 In der Übung bauen Sie die Umleitung für Zählwerk — und Sie üben den Weg zurück. Und Sie üben den Weg zurück. Ein Rückweg, der nur beschrieben ist, hilft im Ernstfall nicht. Sie stellen dem Monolithen ein Routing voran, das die Ableseaufträge auf den neuen Dienst lenkt und alles Übrige beim Altsystem belässt. Das Lernziel ist der Entwurf eines schrittweisen Übergangs mit Umleitung, geklärter Datenhoheit und geübtem Rückweg — also das vollständige Paket, nicht nur die Umleitung.

9:40 Erfolgreich sind Sie, wenn die Zuordnung stimmt, die Schreibhoheit je Tabelle festgelegt ist und der Rückfall einmal durchgespielt wurde. Und beachten Sie den Hinweis: Die Umleitung entscheidet je Pfad, nicht je Benutzer — sonst wird der Rückweg unübersichtlich. Fünf Schritte, und Schritt eins ist der unterschätzte: die Umleitung zunächst alles durchreichen lassen.

10:01 Das klingt sinnlos, ist aber der sicherste Anfang — Sie bringen die neue Komponente in den Weg, ohne das Verhalten zu ändern, und können sie in Ruhe beobachten. Erst dann leiten Sie um. Schritt vier misst die Dauer des Rückfalls, und Schritt fünf markiert den abgelösten Code. Wie die Fußzeile sagt: Der markierte Rückbau bekommt ein Datum, sonst geschieht er nicht. Ein Datum ohne Zuständigen übrigens auch nicht.

10:25 Punkt eins ist ein Entwurfsfehler mit unangenehmen Folgen für die Fehlersuche: Die Umleitung unterscheidet nach Benutzern. Dann verhält sich das System für verschiedene Leute verschieden, und ein Fehlerbericht lässt sich nicht nachstellen, weil der Meldende auf einem anderen Weg lief. Punkt zwei ist das Datenhoheitsproblem. Punkt drei ist der beschriebene, aber nie ausgeführte Rückfall.

10:46 Und Punkt vier ist die Botschaft dieses Moduls, negativ formuliert: Der alte Code bleibt ohne Datum stehen und ist in einem Jahr wieder Bestand — dann fängt die Modernisierung von vorn an.