Von allen Mustern der Modernisierung ist dieses das am besten beschriebene und das am schlechtesten erzählte. Der Vergleich mit der Würgefeige, die um einen Baum wächst, bis der Baum verschwunden ist, steht in jedem Text. Was darin selten steht, ist der Teil, an dem die Umsetzung tatsächlich hängt.
Der Teil, an dem es hängt, ist nicht die Umlenkung. Eine Weiche vor die Anwendung zu setzen, ist ein Nachmittag. Es sind die Daten. Solange zwei Systeme dieselben Datensätze für sich beanspruchen, ist nichts abgelöst, sondern verdoppelt.
Dieser Artikel beschreibt das Muster so, wie es in einem laufenden Betrieb abläuft: die Reihenfolge, den Schnitt, den Umgang mit den Daten, und die fünf Stellen, an denen es reißt.
Die Weiche zuerst, und sie ändert nichts
Der erste Schritt erzeugt keinen Nutzen, und genau das ist seine Aufgabe. Vor die Anwendung kommt eine Umlenkung, die hundert Prozent des Verkehrs an das alte System schickt.
# Schritt eins: die Weiche steht, und sie schickt alles ans Alte.
# Kein Nutzer merkt etwas. Genau das ist der Punkt.
location / {
proxy_pass http://alt;
}
# Schritt zwei, Tage spaeter: ein Pfad, und nur einer.
location /bestellungen/status {
proxy_pass http://neu;
}Der Grund für diese Trennung ist ein sehr praktischer: Wer Weiche und erste Funktion zusammen ausrollt, weiß bei einem Fehler nicht, welches von beidem schuld ist. Eine Umlenkung, die seit einer Woche unauffällig läuft, ist als Fehlerquelle ausgeschlossen.
Für diese Schicht reicht der Lastverteiler, den es schon gibt. Es braucht kein Gateway mit Produktnamen, und es braucht vor allem keine Logik darin: Sobald die Weiche entscheidet, was fachlich passiert, ist sie das dritte System, das später auch jemand ablösen muss.
Wo der erste Schnitt liegt
Die verbreitete Wahl ist der Bereich, der technisch am einfachsten aussieht: eine Randfunktion ohne Datenlast, ein Export, eine Statusseite. Das ist verständlich und kostet ein Jahr.
Denn danach ist sichtbar nichts passiert. Die Ablösung läuft, das Team ist beschäftigt, und niemand im Haus kann sagen, was besser geworden ist. Die Unterstützung bröckelt genau dann, wenn der schwere Teil anfängt.
Der Schnitt, der trägt, folgt nicht der Technik, sondern der Zuständigkeit: Ein Bereich, der seine Daten besitzt, lässt sich herauslösen. Eine Schicht quer durch alles nicht. Und unter den Bereichen, die ihre Daten besitzen, wird der genommen, der sich am häufigsten ändert. Dort zahlt sich die Ablösung jede Woche aus, und dort ist sie nach drei Monaten nachweisbar.
Welcher Bereich überhaupt der erste sein sollte, entscheidet sich vorher: Welchen Service Sie zuerst aus dem Monolithen lösen.
Der schwere Teil
Vor der ersten Zeile im neuen Dienst werden drei Fragen beantwortet, und sie sind keine Architekturfragen, sondern Besitzfragen.
Wer schreibt? Für jede Tabelle des Bereichs gibt es ab dem Umschalten genau einen Schreiber. Entsteht ein zweiter, ist das keine Ablösung, sondern ein Datenbestand mit zwei Wahrheiten, und die Abweichung fällt erst Monate später auf.
Wer liest? Das Alte liest fast immer weiter, und das ist in Ordnung, solange es bekannt ist. Die Liste der Leser ist der Teil, der bei der Inventur vergessen wird: Berichte, nächtliche Läufe, ein zweites Repository, eine Schnittstelle für einen Partner.
Wie kommt die andere Seite an die Daten? Drei Wege, in dieser Reihenfolge der Vorliebe: ein Ereignis, das der Besitzer veröffentlicht; eine Abfrage über eine Schnittstelle; und zuletzt, wenn es nicht anders geht, weiterhin ein direkter Lesezugriff auf die Tabelle, aber schriftlich befristet.
Für die Umstellung selbst gilt dieselbe Mechanik wie bei jeder Datenwanderung im laufenden Betrieb: doppelt schreiben, nachfüllen, abgleichen, umschalten.
Wie doppeltes Schreiben, Nachfüllen und Abgleich im Betrieb ablaufen, steht in Dual-Write und Backfill.
Mitrechnen, bevor jemand es sieht
Zwischen „der neue Pfad ist fertig" und „der neue Pfad bekommt Verkehr" liegt ein Schritt, der wenig kostet und die meisten Überraschungen abfängt: Der neue Pfad verarbeitet echte Anfragen, aber sein Ergebnis geht nicht an den Nutzer, sondern in einen Vergleich.
// Der alte Pfad antwortet wie immer. Der neue rechnet mit,
// und nur die Abweichung wird protokolliert.
$alt = $this->alteBerechnung->fuer($bestellung);
try {
$neu = $this->neuerDienst->fuer($bestellung);
if (!$this->gleich($alt, $neu)) {
// Nicht den ganzen Datensatz protokollieren: die
// Abweichung reicht, und personenbezogene Felder
// haben im Vergleichslog nichts verloren.
$this->logger->warning('abweichung', [
'fall' => $bestellung->id,
'felder' => $this->unterschiede($alt, $neu),
]);
}
} catch (Throwable $e) {
// Ein Fehler im neuen Pfad darf den alten nie beruehren.
$this->logger->warning('schattenlauf gescheitert', ['fehler' => $e->getMessage()]);
}
return $alt;Der Aufwand liegt bei zwei Tagen, und was dabei herauskommt, ist regelmäßig unangenehm: Rundungen, die anders laufen, ein Sonderfall aus dem Jahr 2018, eine Sortierung, auf die sich jemand verlassen hat. Alles davon wäre sonst in Produktion aufgefallen, nur später und mit Publikum.
Umschalten in Stufen
Wenn der Vergleich über eine Woche still bleibt, wird umgeschaltet, und zwar nicht auf einmal. Ein Prozent, zehn, fünfzig, hundert, und je Stufe eine Kennzahl, die vorher festgelegt wurde.
Zwei Regeln dazu, beide aus Schaden gelernt. Die Rückschaltung muss ein Schalter sein, kein Deployment. Wer für den Rückweg eine Auslieferung braucht, schaltet zu spät zurück, weil zwanzig Minuten zu lang sind. Und die Stufe wird an derselben Kennzahl gemessen wie der alte Pfad, nicht an einer neuen: Ein Vergleich ist robust gegen den Tagesgang, ein absoluter Grenzwert nicht.
Wie diese Stufen technisch aussehen, ist eine Frage des Lastverteilers und nicht der Plattform. Für den Anteil je Stufe reicht dieselbe Mechanik wie bei einem Canary.
Das Abschalten gehört dazu
Hier liegt der häufigste Fehler, und er ist nicht technisch. Nach dem Umschalten bleibt der alte Pfad stehen, weil ihn niemand wegnehmen will: Er hat schließlich funktioniert, und man weiß ja nie.
Das Ergebnis ist die schlechteste aller Lagen. Zwei Systeme werden betrieben, beide bekommen Sicherheitsaktualisierungen, beide müssen bei der nächsten Schemaänderung mitgedacht werden, und der Aufwand ist höher als vor der Ablösung. Die Modernisierung hat die Lage verschlechtert.
Das Abschalten gehört deshalb in dieselbe Aufgabe wie das Umschalten, nicht in ein Folgeticket. Ein Folgeticket ist ein Vorsatz, und Vorsätze halten bis zur nächsten knappen Woche. Was bleiben darf, ist der Code für vier Wochen in einem Zweig, den niemand betreibt.
Wie weit dieser Weg getrieben werden sollte, und wo er aufhört, steht in Vom Monolithen zu Microservices.
Die fünf Stellen, an denen es reißt
Zum Schluss die Liste, die in den Beschreibungen des Musters fehlt, weil sie erst beim dritten Mal entsteht.
Ein zweiter Schreiber. Ein nächtlicher Lauf oder ein Bericht schreibt weiter in die Tabelle, die inzwischen dem neuen Dienst gehört. Der Fall wird nicht gemeldet, er wird als Dateninkonsistenz sichtbar, und zwar Wochen später.
Die Sitzung. Nutzer wechseln zwischen altem und neuem Pfad, und beide Seiten müssen dieselbe Anmeldung verstehen. Wer das erst beim Umschalten bemerkt, baut die Anmeldung unter Zeitdruck um.
Die gemeinsame Identität. Zwei Systeme, zwei Nummernkreise, und eine Bestellnummer, die es zweimal gibt. Die Kennungen werden vor dem ersten Schnitt geklärt, nicht danach.
Der Pfad ohne Anfrage. Warteschlangen, Stapelläufe und zeitgesteuerte Aufgaben laufen an der Weiche vorbei. Sie werden bewusst einer Seite zugeordnet, sonst laufen sie doppelt oder gar nicht.
Die Reihenfolge im Haus. Der fünfte Punkt ist der einzige ohne Technik: Wenn nach sechs Monaten nichts Sichtbares entstanden ist, wird das Vorhaben gestoppt, unabhängig davon, wie gut es läuft. Deshalb steht der Bereich mit der höchsten Änderungsrate am Anfang und nicht der mit der niedrigsten Datenlast.
Wer das Muster an einem laufenden System anwenden will, findet den Begriff im Glossar und das Vorgehen als Leistung auf einer eigenen Seite.
Dieser Artikel setzt eine Reihe über Systeme fort, die es schon gibt. Der Rückblick über die ersten drei Monate ordnet ihre Artikel nach Anlass.
