W ramach jednego z projektów w Onwelo wzięliśmy udział w budowie platformy Bank as a Service firmy Vodeno. W trakcie trwania developmentu wielokrotnie przyszło nam integrować się z usługami zewnętrznych dostawców. Na jakie trudności natrafiliśmy? Jakie wnioski wyciągnęliśmy i na co warto zwrócić uwagę przed wyborem usługi? Tego wszystkiego możecie dowiedzieć się z artykułu. 🙂

Vodeno

Moje początki w projekcie sięgają 2018 roku. Od początku było wiadomo, że będzie to spore wyzwanie. W końcu nie na co dzień buduje się bankowego Netflixa. Nowoczesne technologie, rozbudowana architektura, cloud, mikroserwisy, ciekawe zadania – totalny greenfield.

Podczas udziału w projekcie miałem okazję pracować w kilku obszarach. Największym oraz najbardziej wymagającym z tych, w których uczestniczyłem, był obszar kredytowy. Miałem możliwość poznania go zarówno od strony kredytów detalicznych, jak i SME. Zdarzały się również aplikacje, które wykraczały poza ścisłą domenę bankową. Jedną z nich była aplikacja w obszarze bezpieczeństwa danych do monitoringu wycieków danych klienta w sieci.

Zewnętrzna usługa – na co warto zwrócić uwagę

W ramach projektu kilkukrotnie przyszło nam integrować się z usługami różnych dostawców. Czasami integracja szła bardzo szybko, a czasami stawialiśmy czoła szeregowi różnych wyzwań. Były to problemy z niepełną dokumentacją, zdarzało się też, że usługa działała w nieoczekiwany sposób ze względu na błędną konfigurację po stronie dostawcy. Jeszcze innym razem środowisko testowe różniło się od produkcyjnego. Te wszystkie doświadczenia pokazały mi, na co warto zwrócić uwagę, wybierając usługę, z którą chcemy się zintegrować.

Dokumentacja

Bez dobrej dokumentacji ciężko cokolwiek zrobić. Działanie w ciemno, metodą prób i błędów to nie najlepsze wyjście. Warto zwrócić uwagę na to, czy usługa, z którą zamierzamy się integrować, posiada kompleksową dokumentację. Najlepiej, jeżeli oprócz dokumentacji w formie tekstowej dostaniemy kolekcję w Postmanie lub playground, gdzie możemy testować API. Co jednak w przypadku, gdy dostawca nie dostarcza żadnej kolekcji lub miejsca do testowania? Mieliśmy do czynienia z takim przypadkiem. Co zrobiliśmy w takiej sytuacji? Nasz analityk napisał bardzo fajny mały prototyp w Pythonie, który pomógł nam lepiej zrozumieć API dostawcy. Dzięki niemu w łatwiejszy sposób mogliśmy zaplanować integrację w naszym systemie. Do tego zapewnił nam szybki feedback, jak działają poszczególne funkcjonalności. To umożliwiło nam np. szybkie znalezienie błędów, które zgłosiliśmy dostawcy. Czasami jednak taki prototyp może być strzałem z armaty do wróbla. Jako alternatywę możemy stworzyć swoją kolekcję w Postmanie ze skryptami, bazując na tym, co otrzymamy od dostawcy.

Bezpieczeństwo

Ważny punkt, szczególnie jeśli pracujemy w projekcie dla branży, w której nacisk jest położony na bezpieczeństwo tworzonych rozwiązań. Aplikacje bankowe wymagają szczególnej uwagi pod tym względem. Tutaj nie ma miejsca na błędy. Warto dokładnie przedyskutować to z potencjalnym dostawcą. Możemy np. poprosić o raporty z testów bezpieczeństwa rozważanej przez nas usługi. Podczas integracji staraliśmy się zwracać uwagę na potencjalne luki. Równolegle zespół bezpieczeństwa analizował, czy dostarczone elementy nie niosą potencjalnego zagrożenia. Odpowiedzialność za zabezpieczenie usługi najczęściej spoczywa na dostawcy, jednak warto zwrócić uwagę na to, że to my jako konsument możemy ponieść straty wizerunkowe, jeżeli na skutek takiej integracji nasz klient stanie się ofiarą ataku, straci pieniądze lub będzie w jakikolwiek inny sposób poszkodowany. Nikogo nie będzie tutaj interesować, że zawiniła firma XYZ, która nam dostarczała usługę. Warto również dopytać, czy dostawca spełnia normy, posiada certyfikaty i tym podobne znaki jakości potrzebne do przetwarzania odpowiedniego typu danych np. numerów kart bankowych klientów.

Wydajność

Przed integracją warto przemyśleć, jaki potencjalny ruch przewidujemy. Dobrze jest przedyskutować ten fakt z dostawcą, żeby potem uniknąć przykrych niespodzianek, np. limitów, problemów wydajnościowych lub zwiększenia kosztów.

Koszty

Skoro już o kosztach mowa, to wskazane jest sprawdzenie, jak wygląda rozliczenie usługi – czy mamy model abonamentowy, per request, czy są do wyboru jakieś pakiety rozliczeniowe. Dobrze jest też dopytać o kwestie ewentualnego wsparcia, czy jest ono w cenie, czy może musimy wyłożyć na nie dodatkowe środki.

Support

Czasami mieliśmy wątpliwości co do działania usługi – dokumentacja była niejasna lub podczas strzałów do API dostawaliśmy tajemniczo brzmiące komunikaty błędów. W takich sytuacjach dobry support jest niezbędny. Warto sprawdzić, jak wygląda model wsparcia u danego dostawcy. Niektórzy dostawcy udostępniają dodatkowo płatne wsparcie premium. Dobrze jest rozważyć tę opcję, szczególnie na początku integracji, kiedy liczba niewiadomych jest największa lub gdy usługa, z którą się integrujemy, jest krytyczna dla działania naszej aplikacji.

Środowiska

Rozważając wybór dostawcy, dobrze jest sprawdzić, jakie środowiska nam on zapewnia. Warto ustalić, czy np. to, które dostaniemy do testów, jest jak najbardziej zbliżone do środowiska produkcyjnego i zapewnia możliwość przetestowania wszystkich elementów. Jeżeli nie będziemy w stanie tego zrobić, to  w środowisku wystawionym dla klienta mogą czekać nas niespodzianki. Usługa niekoniecznie może zadziałać w sposób, jaki był przewidziany. Myślę, że raczej nikt nie chciałby być uczestnikiem słynnych testów na produkcji. Nam zdarzył się przypadek, gdzie w środowisku testowym nie działała kluczowa dla nas funkcjonalność. Całe szczęście po zgłoszeniu problemu zostało to szybko naprawione.

Nowe wersje

Często nie mamy wpływu na to, co dzieje się po stronie dostawcy. Warto poczytać warunki lub przedyskutować, jak wygląda proces wdrażania nowych wersji, czy my jako użytkownicy zostaniemy o tym odpowiednio poinformowani. Pół biedy, jeżeli na nieoczekiwane zmiany lub – co gorsza – błędy w działaniu natrafiamy my sami. Gorzej, jeżeli takie niezapowiedziane zmiany zauważą nasi użytkownicy.

Komunikacja

Po przeczytaniu punktów powyżej możemy zauważyć, że dobra komunikacja z dostawcą jest nieoceniona. Warto przedyskutować nasze plany i oczekiwania. Być może dostaniemy coś w 100% dostosowane do naszych wymagań. Niejednokrotnie, gdy w trakcie integracji natrafiliśmy na problemy, których dokumentacja nie opisywała lub nie wyczerpywała tematu, to umawialiśmy spotkania z dostawcą. Jeżeli jego responsywność jest wysoka, jesteśmy w stanie szybko rozwiązać problem, co czasami może być krytyczne.

SLA

Jeżeli o rozwiązywaniu problemów mowa, to nie można nie wspomnieć o SLA, czyli Service Level Agreement. Jest to umowa dotycząca poziomu świadczonych usług. Jest ona szczególnie istotna, jeżeli elementy, z którymi mamy zamiar się integrować, są krytyczne dla działania naszych serwisów. To, co warto zawrzeć w takiej umowie, to na pewno poziom dostępności usług, czas na naprawę błędów, ewentualne środki zaradcze oraz potencjalne kary umowne dla dostawcy. Nawet krótka awaria może spowodować poważne straty finansowe i wizerunkowe. Warto zabezpieczyć się na tę okazję i zadbać o dobre SLA.

Plusy i minusy korzystania z zewnętrznej usługi

Czasami w trakcie dyskusji wewnątrz zespołu zastanawialiśmy się, czy niektóre z usług, z którymi się zintegrowaliśmy, nie lepiej napisać i trzymać po swojej stronie. Tutaj odpowiedź nigdy nie była jednoznaczna, niektórzy uważali, że warto, inni byli przeciwni.

Za integracją przemawiają na pewno:

– efektywność – z pewnością na początku dużych projektów warto stawiać na integrację z innymi dostawcami. Często są to firmy specjalizujące się w danym rodzaju usług, mają większą wiedzę domenową w danym zakresie, znają rynek. Przeszły już pewną “ścieżkę zdrowia” i na przykład znają przypadki brzegowe, o których my moglibyśmy nie pomyśleć

– bezpieczeństwo – odpowiedzialność za bezpieczeństwo rozwiązania najczęściej jest po stronie dostawcy

– utrzymanie – nie musimy dbać o utrzymanie danej usługi, usuwać błędów i dbać o niezbędną infrastrukturę

Każdy kij ma jednak dwa końce, dlatego do minusów integracji możemy zaliczyć:

– brak elastyczności – czasami usługa nie pokrywa w 100% naszych przypadków użycia i wymagany jest dodatkowy development po stronie dostawcy. Wiąże się to z czasem oczekiwania oraz dodatkowymi kosztami. Nie zawsze jest to też możliwe

– koszty – wraz z rozwojem naszego projektu mogą wzrosnąć koszty używania usługi, jeżeli np. będziemy z czasem mieć większą liczbę użytkowników. Rozwiązanie, z którym się zintegrowaliśmy, może być wtedy ciężkie do zmiany lub koszty takiej zmiany mogą nas przerosnąć i będzie to nieopłacalne

– bezpieczeństwo – ten punkt można też wrzucić w minusy. Jak wspomniałem w poprzedniej sekcji, błąd bezpieczeństwa po stronie dostawcy może kosztować naszą firmę straty wizerunkowe

– nieoczekiwane zmiany – jeżeli dostawca nas nie powiadomił o nowej wersji, którą wdrożył, niektóre z elementów usługi mogą przestać nagle działać lub zacząć zachowywać się w nieoczekiwany sposób.

Słowo na koniec

Integracja z zewnętrznymi usługami to nie zawsze bułka z masłem. Z punktu widzenia inżyniera mogę powiedzieć, że jest to na pewno bardzo ciekawe doświadczenie, z którego można dużo wynieść i poznać trochę know-how z innego podwórka.

Czy takie integracje zawsze są niezbędne? Czy może lepiej czasami postawić na swoje rozwiązania? To zależy od sytuacji, a czasem od regulacji, które takie integracje wymuszają (przykładem może być PSD2, BIK itp). W początkowej fazie projektu możemy nie mieć wystarczającej liczby osób do pokrycia wszystkich tematów i tworzenia usług, które dostarczają nam zewnętrzne firmy. Wraz z rozwojem projektu, można niektóre elementy próbować przenosić na swoje podwórko, bazując na dotychczasowych doświadczeniach. Warto jednak przekalkulować koszty i sprawdzić, czy się nam to opłaca.

Paweł Kaleciński  – Full Stack Developer / Team Leader w Onwelo. Zainteresowany nowinkami technicznymi, bezpieczeństwem aplikacji internetowych i muzyką rockową.