My Geocode

Migration

Eine Checkliste für den Parallelbetrieb zweier Anbieter

· 3 Min. Lesezeit · My Geocode · #migrations-checkliste#geokodierung#zwei-anbieter#architektur#testen

Zwei Anbieter gleichzeitig zu betreiben ist während einer Migration meist ein bewusster, vorübergehender Zustand und keine dauerhafte Architektur, braucht aber genug Struktur, damit daraus kein verwirrendes Durcheinander aus bedingter Logik wird, die über die ganze Codebasis verstreut ist. Eine Checkliste hilft, diese Phase kurz und ihren Zweck klar zu halten.

Bevor Sie echten Traffic an einen zweiten Anbieter senden:

  • Stellen Sie sicher, dass die Antwortstrukturen beider Anbieter auf eine gemeinsame interne Datenstruktur abgebildet wurden, sodass Ihr Anwendungscode aus einem einheitlichen, normalisierten Format liest, unabhängig davon, welcher Anbieter eine bestimmte Anfrage tatsächlich beantwortet hat
  • Legen Sie die Aufteilungslogik vorab fest: Anteil des Traffics, bestimmte Endpunkte, bestimmte Kundensegmente oder ein Schattenmodus, in dem der zweite Anbieter aufgerufen, sein Ergebnis aber nur protokolliert und nicht verwendet wird
  • Richten Sie getrennte Protokollierung oder Kennzeichnung ein, damit Sie im Nachhinein erkennen können, welcher Anbieter eine bestimmte Anfrage bedient hat. Das ist enorm wichtig, wenn etwas schiefgeht und Sie wissen müssen, wo Sie zuerst suchen sollen

Solange beide Anbieter live sind:

  • Vergleichen Sie Fehlerraten und Antwortzeiten der beiden regelmäßig, nicht nur einmal zu Beginn, denn das Verhalten kann sich über Tage oder Wochen auf eine Weise verschieben, die ein einzelner erster Test übersehen würde
  • Achten Sie auf Abweichungen in den tatsächlichen Ergebnissen beider Anbieter bei derselben Eingabe, und legen Sie klar fest, wie entschieden wird, wenn sie sich widersprechen, statt einfach anzunehmen, dass einer von beiden recht hat
  • Führen Sie fortlaufend Notizen zu jedem Anfragemuster, das sich bei den beiden merklich unterschiedlich verhält, denn genau diese Fälle sollten gründlicher getestet werden, bevor der alte Anbieter abgeschaltet wird

Bevor Sie den ursprünglichen Anbieter abschalten:

  • Stellen Sie sicher, dass jeder Codepfad, der den alten Anbieter aufrufen könnte, tatsächlich gegen den neuen durchlaufen wurde, nicht nur die häufigen Fälle
  • Suchen Sie nach fest codierter Fallback-Logik, die davon ausgeht, dass der alte Anbieter immer verfügbar ist, denn Phasen mit zwei Anbietern hinterlassen manchmal Fallback-Code, an dessen Entfernung niemand denkt
  • Legen Sie ein konkretes Datum für die Abschaltung des alten Anbieters fest, statt die Phase mit zwei Anbietern unbegrenzt weiterlaufen zu lassen, denn ein Übergang ohne Enddatum wird in der Regel nie wirklich abgeschlossen

Die Kompatibilitäts-Hosts von My Geocode sind gezielt dafür gebaut, die erste Hälfte dieses Prozesses, die Normalisierung der Antwortstruktur, weitgehend überflüssig zu machen, wenn es für den Anbieter, von dem Sie wechseln, bereits einen passenden Host gibt, denn die Struktur bleibt mit dem Original identisch und Ihr vorhandener Normalisierungscode (falls Sie schon welchen hatten) funktioniert unverändert weiter. Die vollständige Liste der 17 Kompatibilitäts-Hosts finden Sie unter /compatibility/. Jede Anfrage enthält außerdem Kontingent-Header, X-Quota-Limit, X-Quota-Used, X-Quota-Free-Remaining und weitere, dokumentiert unter /docs/rate-limits/, die für den oben beschriebenen Schritt der vergleichenden Protokollierung nützlich sind, unabhängig davon, welcher Anbieter als zweiter bewertet wird.

Eine gut durchgeführte Phase mit zwei Anbietern ist kurz, gut instrumentiert und endet zu einem geplanten Datum. Schlecht durchgeführt wird sie zu einer dauerhaften und verwirrenden Einrichtung. Der Unterschied liegt fast ausschließlich darin, ob eine Checkliste wie diese befolgt oder unter Zeitdruck übersprungen wird.

Mehr zu Migration