Oszacowanie kosztów wymiany interfejsu API dostawcy zewnętrznego

API nowego dostawcy wygląda identycznie, dopóki nie rozpocznie się migracja danych.

Argumenty przemawiające za zmianą dostawcy są zawsze takie same: nowe API jest bardziej przejrzyste, szybsze i tańsze. Pułapka polega na tym, że osobliwości starego API pełnią funkcję nośną. Kod zawiera dwa lata takich rozwiązań jak „to jest ciąg znaków, ale w rzeczywistości jest to data w ich formacie”, „to zwraca wartość null, gdy oznacza zero”, „to ogranicza przepustowość bez ostrzeżenia” — a płynna zmiana oznacza odtworzenie każdej z tych osobliwości zgodnie z zachowaniem nowego dostawcy, które różni się w sposób, którego nikt nie udokumentował.

W kosztorysie należy uwzględnić okres równoległej eksploatacji: stary i nowy dostawca działają równolegle, a wyniki są porównywane, dopóki zespół nie nabierze pewności, że nowy dostawca działa prawidłowo. Faza ta często trwa dłużej niż samo wdrożenie. W przypadku zadań, w których nie uwzględniono tego okresu, wdraża się nowego dostawcę, a niedociągnięcia ujawniają się dopiero wtedy, gdy dane klienta napotkają przypadek skrajny.

O czym się mówi w tym pomieszczeniu

Backend: „Nowy zestaw SDK jest lepszy. Wykonanie podstawowych wywołań zajmuje po jednym dniu”.

Wstęp: „A co z danymi historycznymi, które przechowują dla nas?”

SRE: „Czy korzystamy z usług obu dostawców jednocześnie, czy też planujemy przejście na jednego z nich?”

Backend: „Ich format webhooków jest inny. Podobnie jak proces uwierzytelniania.”

Pytanie dotyczące kontroli jakości: „W jaki sposób możemy zweryfikować zgodność — porównując odpowiedzi z całego tygodnia?”

Pytania, które warto zadać przed oddaniem głosu

• Czy u poprzedniego dostawcy znajdują się dane historyczne, które należy przenieść do naszej firmy?
• Różnice w uwierzytelnianiu — klucze API, OAuth, podpisane żądania?
• Webhooki: czy zdarzenia są jednoznacznie przyporządkowane, czy też wymagają przekształcenia?
• Okres równoległej eksploatacji: jak długo powinien trwać i kiedy można uznać, że sytuacja jest „wystarczająco dobra”, by przejść na nowy system?
• Limity przepustowości i model cenowy u nowego dostawcy — czy będą takie same, czy inne?
• Cofnięcie zmiany: czy możemy powrócić do poprzedniego rozwiązania, jeśli nowy dostawca okaże się gorszy?

Podstawowe wywołania są proste; prawdziwą pracą jest dowód równoważności. Jeśli zarówno przebieg dualny, jak i przeniesienie danych są rzeczywiste, to jest to temat na więcej niż jeden artykuł — należy je rozdzielić i ocenić weryfikację niezależnie od implementacji.

Należy uwzględnić w budżecie koszty podwójnego uruchomienia oraz sprawdzenia równoważności. Przejrzysty interfejs API to ta tańsza część.

Podobnie jak w przypadku szacowania migracji bazy danych, kod działa szybko, a prawdziwym wyzwaniem jest wdrożenie. Proszę zapoznać się z innymi przykładami udanych szacunków lub rozpocząć bezpłatną sesję Planning Pokera, gdy plan podwójnego przebiegu zostanie już zarysowany.