17 września 2024

API w modelu SELF-SERVICE

W branży ubezpieczeniowej, z pozoru klasycznym biznesie, coraz częściej mamy do czynienia z produktami, które posiadają coraz więcej podobieństw do usług i produktów cyfrowych. Bez technologii, w szczególności algorytmów i dużych zbiorów danych, działalność ubezpieczeniowa byłaby w zasadzie niemożliwa.

Autor

Krzysztof Radzimowski

Dlaczego to robimy?  

  1. Różnorodny, cyfrowy świat rzuca nam wyzwanie. Z roku na rok widzimy rozwój technologii, nawet w tak klasycznych (mogło by się wydawać) branżach, jak ubezpieczeniowa. Możemy zaobserwować zwiększenie ilości produktów posiadających coraz więcej podobieństw do usług i produktów cyfrowych. Bez technologii, w szczególności algorytmów i dużych zbiorów danych, działalność ubezpieczeniowa byłaby w zasadzie niemożliwa. Wyzwaniem jest  więc zbudowanie platformy cyfrowej, która pozwala na efektywną integrację tych elementów oparciu o wspólny „język”, ułatwiający wzajemną komunikację - API (Application Programming Interface). 
  2. Dzięki API, usługa cyfrowa może być dostępna dla innego systemu w sposób ustandaryzowany, co umożliwia integrację procesów biznesowych, niezależnie od lokalizacji, strefy czasowej czy języka. Firmy bez kompetencji cyfrowych i bez API szybko stają się niewidoczne, a współpraca z nimi staje się kosztowna. 
  3. Realizując integracje w PZU, rozwijamy i utrzymujemy platformę technologiczną, nadążającą za potrzebami biznesu. Projektując hybrydową platformę integracyjną (HIP – Hybrid Integration Platform) zidentyfikowaliśmy szereg potrzeb wymagających zaadresowania. Powstało hybrydowe połączenie komponentów własnych i chmury publicznej, opisywane szeroko jako iPaaS (integration Platform as a Service), wspierające różne technologie i sposoby interakcji (synchroniczne, asynchroniczne, zdarzeniowe etc.). Platforma potrafi łączyć nowoczesne aplikacje mikrousługowe, systemy monolityczne, a nawet systemy dużo starsze tzw. legacy, które często nie są już rozwijane i nie udostępniają API. Żeby ułatwić integrację w takim ekosystemie zdecydowaliśmy się na zbudowanie bramy prowadzącej do świata API. Dzięki niej każdy developer może opublikować wytworzone API na wspólnej platformie w modelu self-service. To niezwykle istotne z perspektywy wdrażania kultury API-First oraz czasu dostarczania produktów (TTM – Time To Market). 

Jak do tego podeszliśmy? 

Badając rynek rozwiązań klasy API Management wybraliśmy technologię, która umożliwia publikowanie API oraz obsługę przepływu danych zarówno w chmurze obliczeniowej, hybrydowo, jak i w całkowitej izolacji on-premise, co jest szczególnie ważne w przypadku niektórych danych wrażliwych.

Dzięki możliwości definiowania własnych polityk zintegrowaliśmy platformę API z rozwiązaniami observability i wdrożyliśmy ochronę dostawców API przed nadmiernym ich obciążeniem. Ważnym aspektem w kontekście migracji usług opartych o SOAP jest możliwość klonowania zapytań na potrzeby testów A/B bezpośrednio z polityki API. 

Ten wszechstronny mechanizm jest istotną wartością dodaną dla developerów, dostępną z pudełka. Wszystkie te mechanizmy bardzo dokładnie opisuje szczegółowa dokumentacja usługi aktualizowana na bieżąco wraz z ciągłym jej rozwojem. Dzięki temu podejściu osiągnęliśmy możliwość publikowania w modelu samoobsługowym własnych API przez tzw. IT citizens, którzy na co dzień nie pracują w obszarze integracji. 

 

Jakie technologie za tym stoją?  

Kluczową technologią wykorzystywaną w tym rozwiązaniu jest usługa chmurowa Azure API Management. Jest ona uruchomiona po stronie PZU w środowisku skonteneryzowanym, co pozwala na jej pełne skalowanie. Ponadto – gateway uruchomiony on-premise uniezależnia PZU od potencjalnej chwilowej niedostępności platformy Azure. Zdarzenia, które powstają w przepływach integracyjnych trafiają do logu Kafka, a obserwujemy je w rozwiązaniach Jaeger, AKHQ czy stosie Elasticsearch-Logstash-Kibana. Obszar operacji dysponuje jeszcze Grafaną, Prometheus czy Victoria Metrics. Taki stos technologiczny pozwala na całkowitą swobodę konfiguracji observability i upraszcza tworzenie dedykowanych dashboard’ów.  

Liczby tego projektu 

  • ponad 30 API udostępnionych produkcyjnie dla 25 systemów wewnętrznych i zewnętrznych 
  • ponad 50 operacji biznesowych w największym API  
  • ok. 300 000 codziennie przetwarzanych żądań API, gromadzących > 1 000 000 wpisów logów z ich przetwarzania 
  • 2-3 nowe projekty, które chcące skorzystać z API każdego tygodnia 
Zamknij