Abschätzung des Aufwands für den Wechsel zu einer API eines Drittanbieters
Wie man den Wechsel zu einer API eines Drittanbieters einschätzt: semantische Lücken, Parallelbetrieb und die Annahmen, die in den Eigenheiten des bisherigen Anbieters verankert sind. Die neue API sieht lediglich identisch aus.
Die API des neuen Anbieters sieht zunächst identisch aus, bis Sie mit der Datenmigration beginnen.
Das Verkaufsargument für einen Anbieterwechsel ist immer dasselbe: Die neue API ist übersichtlicher, schneller und kostengünstiger. Die Falle besteht darin, dass die Eigenheiten der alten API tragende Elemente des Systems sind. Die Codebasis enthält zwei Jahre lang Ansammlungen von „das ist zwar eine Zeichenkette, aber eigentlich ein Datum in deren Format“, „das gibt null zurück, wenn es Null bedeutet“, „hier wird die Ratenbegrenzung stillschweigend angewendet“ – und ein sauberer Wechsel bedeutet, jede einzelne dieser Eigenheiten entsprechend dem Verhalten des neuen Anbieters nachzubilden, das sich in einer Weise unterscheidet, die niemand dokumentiert hat.
In der Kostenkalkulation muss der Parallelbetrieb berücksichtigt werden: Der alte und der neue Anbieter laufen nebeneinander, wobei die Ergebnisse verglichen werden, bis das Team davon überzeugt ist, dass der neue Anbieter die Anforderungen erfüllt. Diese Phase dauert oft länger als die Implementierung. Bei Projekten, bei denen dies nicht einkalkuliert wurde, wird der neue Anbieter eingeführt, und die Lücken werden erst entdeckt, wenn die Kundendaten das nächste Mal auf einen Grenzfall stoßen.
Was in dem Raum gesagt wird
Backend: „Das neue SDK ist besser. Die grundlegenden Aufrufe dauern jeweils einen Tag.“
Einleitung: „Was ist mit den historischen Daten, die sie für uns aufbewahren?“
SRE: „Betreiben wir beide Anbieter gleichzeitig oder führen wir eine Umstellung durch?“
Backend: „Das Webhook-Format ist anders. Das gilt auch für die Authentifizierung.“
Frage: „Wie überprüfen wir die Gleichwertigkeit – indem wir die Antworten eine Woche lang vergleichen?“
Fragen, die man sich vor der Stimmabgabe stellen sollte
- Gibt es beim bisherigen Anbieter historische Daten, die wir mitnehmen müssen?
- Unterschiede bei der Authentifizierung – API-Schlüssel, OAuth, signierte Anfragen?
- Webhooks: Lassen sich die Ereignisse direkt zuordnen, oder müssen wir sie übersetzen?
- Zeitraum des Parallelbetriebs: Wie lange dauert er, und ab wann ist die Umstellung „gut genug“?
- Ratenbegrenzungen und Preismodell beim neuen Anbieter – gleich oder unterschiedlich?
- Rücknahme: Können wir den Vorgang rückgängig machen, falls sich der neue Anbieter als schlechter erweisen sollte?
Die grundlegenden Aufrufe sind einfach; der Gleichwertigkeitsnachweis ist die eigentliche Arbeit. Wenn sowohl der Dual-Lauf als auch die Datenverschiebung real sind, handelt es sich um mehr als eine Geschichte – teilen Sie diese auf und dimensionieren Sie die Verifizierung getrennt von der Implementierung.
Planen Sie die Kosten für die doppelte Ausführung und die Äquivalenzprüfung ein. Die übersichtliche API ist der kostengünstige Teil.
Ähnlich wie bei der Schätzung einer Datenbankmigration ist der Code schnell erstellt, und der eigentliche Aufwand liegt in der Umsetzung. Sehen Sie sich die anderen Beispiele für durchgeführte Schätzungen an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Plan für den dualen Ablauf skizziert ist.