Dwie postacie z karteczek samoprzylepnych podłączają kable do skrzynek oznaczonych jako „Źródło” i „Cel”, podczas gdy trzecia sprawdza gniazdko ścienne znajdujące się za nimi.

Oszacowanie kosztów wymiany interfejsu API dostawcy zewnętrznego

Jak oszacować koszty wymiany API innego dostawcy: luki semantyczne, równoległe działanie oraz założenia wynikające ze specyfiki dotychczasowego dostawcy. Nowe API wydaje się jedynie identyczne.

Interfejs 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 specyficzne cechy starego API pełnią funkcję nośną. Kod źródłowy zawiera dwa lata takich przypadków, 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 żadnego powiadomienia”. Płynna zmiana dostawcy oznacza odtworzenie każdego z tych specyficznych zachowań w kontekście działania 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 projektów, 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ą sytuację graniczną.

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 uwierzytelnianie”.

Pytanie dotyczące kontroli jakości: „W jaki sposób możemy zweryfikować zgodność — poprzez porównanie 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 co uznaje się za „wystarczająco dobre” warunki do przejścia na nowy system?
  • Limity przepustowości i model cenowy u nowego dostawcy: takie same czy inne?
  • Cofnięcie decyzji: czy możemy cofnąć się, 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 operacja przenoszenia danych są rzeczywiste, to jest to więcej niż jeden wątek: proszę je rozdzielić i określić zakres weryfikacji niezależnie od implementacji.

Proszę 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 oszacowania migracji bazy danych, sam kod powstaje szybko, a prawdziwym wyzwaniem jest wdrożenie. Proszę zapoznać się z innymi przykładami oszacowań lub zorganizować bezpłatną sesję „planning poker”, gdy plan podwójnego uruchomienia zostanie już zarysowany.