Oszacowanie kosztów wymiany API dostawcy zewnętrznego
Jak oszacować koszty wymiany API dostawcy zewnętrznego: luki semantyczne, równoległe działanie systemów 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 dwuletnią historię takich sytuacji jak: „to jest ciąg znaków, ale w rzeczywistości jest to data w ich formacie”, „to zwraca wartość null, gdy oznacza zero” czy „to ogranicza przepustowość bez ostrzeżenia”. Płynna zmiana dostawcy oznacza odtworzenie każdego z tych specyficznych zachowań zgodnie z działaniem 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: starego i nowego dostawcy działających równolegle wraz z porównaniem wyników, aż do momentu, gdy zespół nabierze pewności, że nowy dostawca zapewnia zgodność wyników. Faza ta często trwa dłużej niż samo wdrożenie. W przypadku projektów, w których nie uwzględniono tego okresu w kosztorysie, po wdrożeniu nowego dostawcy 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ż dokonujemy przełączenia?”
Backend: „Format ich 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 głosowaniem
- 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ż konieczne jest ich przekształcenie?
- 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 nowego dostawcy: takie same czy inne?
- Cofnięcie zmian: czy możemy powrócić do poprzedniego stanu, 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 przenoszenie danych są rzeczywiste, to jest to temat na więcej niż jeden artykuł: należy je rozdzielić i ocenić poprawność oddzielnie od implementacji.
Należy przeznaczyć środki na uruchomienie podwójne oraz weryfikację równoważności. Przejrzysty interfejs API to najtańszy element.
Podobnie jak w przypadku szacowania migracji bazy danych, kod jest gotowy szybko, a prawdziwym wyzwaniem jest wdrożenie. Proszę zapoznać się z innymi przykładami udanych szacunków lub rozpocząć bezpłatną sesję planowania pokerowego, gdy plan podwójnego przebiegu zostanie już zarysowany.