Kostenschätzung für den Wechsel zu einer API eines Drittanbieters

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. Der Code enthält seit zwei Jahren Anomalien wie „das ist zwar eine Zeichenkette, aber eigentlich ein Datum in deren Format“, „das gibt null zurück, obwohl es Null bedeutet“ oder „das führt stillschweigend eine Ratenbegrenzung durch“. Ein sauberer Wechsel bedeutet, jede dieser Besonderheiten im Verhalten des neuen Anbieters nachzubilden – und dieses unterscheidet sich in Punkten, 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 den Anforderungen entspricht. Diese Phase dauert oft länger als die Implementierung. Bei Projekten, bei denen dies nicht berücksichtigt wird, wird der neue Anbieter eingeführt, und die Lücken werden erst entdeckt, wenn die Kundendaten das nächste Mal einen Grenzfall erreichen.

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 unterscheidet sich. 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 übernehmen 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?
• Parallelbetriebszeitraum: Wie lange dauert er, und ab wann ist die Umstellung „gut genug“?
• Ratenbegrenzungen und Preismodell beim neuen Anbieter: identisch oder unterschiedlich?
• Rücknahme: Können wir den Schritt 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 nur eine Aufgabe: Trennen Sie diese und führen Sie die Verifizierung getrennt von der Implementierung durch.

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 Schätzungen aus der Praxis an oder starten Sie eine kostenlose Planning-Poker-Sitzung, sobald der Plan für den Parallelbetrieb skizziert ist.