Mikrousługi i dostarczanie: minimalizacja potrzeby synchronizacji prawie 70 zespołów wytwórczych
Autor
Ekspert Grupy PZU
Dlaczego to robimy?
Do tej pory mogło się wydawać, że wielkość naszej firmy, skala w której działamy rodzi tylko określony rodzaj wyzwań niedostępnych w mniejszych organizacjach. Wspomniane wyzwania dotyczą nie tylko ilości przetwarzanych danych, ale także wielkości samego IT - synchronizacja pracy 70 zespołów wytwórczych, to niezwykle trudne wyzwanie, mogące bardzo negatywnie wpływać na ich efektywność, która jest niezaprzeczalnym elementem naszej współpracy. Jak więc zorganizować proces wytwórczy i architekturę systemów aby zminimalizować potrzebę synchronizacji? Świat znalazł już na to odpowiedź - jest nią luźna architektura oparta o mikrousługi. Wyzwanie leży jednak nie tylko w podejściu do architektury systemowej - jak zapewnić, aby koszty synchronizacji i narzut na pracę z wielkimi monolitami nie zmienił się w koszt zainicjowania i konfiguracji nowego systemu? I już w tym momencie możemy Wam zdradzić: nam się udało.
Jak do tego podeszliśmy?
Tworzenie systemu od podstaw, to często wyzwanie. Wróć. Tworzenie systemu od podstaw to zawsze wyzwanie i do tego, często przyprawione o różne zwroty akcji.
Frameworki typu springboot mają wiele stopni swobody, aby dało się je zastosować do wielu różnych przypadków użycia i organizacji.
Dlatego w PZU utworzyliśmy szablon, z którego powołujemy nowe mikrousługi. Szablon jest zbiorem najlepszych praktyk wypracowanych do tej pory przez developerów, zawiera także implementację standardowych dla organizacji integracji, takich jak serwer autoryzacji, standardowy silnik bazy danych, kafka, testy automatyczne, czy mechanizmy, za pomocą których definiujemy zewnętrzne API w podejściu „contract first”.
Deweloperzy, którzy korzystają z takiego szablonu, dostają działającą mikrousługę, napisaną w najnowszej wersji LTS Java, budowaną za pomocą Gradle i kompatybilną z wewnątrzfirmowym procesem CI/CD. Całość, od momentu wygenerowania, jest gotowa do wdrożenia na wszystkie środowiska - od testowego po produkcje. Konieczne jest tylko wypełnienie konkretnych wymagań biznesowym kodem je realizującym.
Jakie technologie za tym stoją?
W PZU mocno wierzymy w automatyzacje procesu testów. Najtańsza w wytworzeniu i utrzymaniu warstwa testów jednostkowych wymaga odpowiedniej architektury. Zastosowanie architektury heksagonalnej i restrykcyjne wydzielenie klas odpowiedzialnych za kluczową logikę biznesową znakomicie sprzyja pisaniu testów najniższej warstwy (i nie tylko), które są potem uruchamiane w każdym buildzie uruchamianym w procesie CI. Konteneryzacja aplikacji sprawia, że problem zarzadzania infrastrukturą, nie dotyczy developerów. Każdy dostarczony obraz instalowany jest na naszych wewnętrznie zarządzanych klastrach Kubernetes.
Liczby tego projektu 
- 26 paczek usprawnień (mniejszych i większych), które znalazły się w naszym szablonie dla mikrousług
- 50 usług powołanych oparciu o różne wersje szablonu