Jak stworzyć usługę bankowości online, która nie tylko będzie odpowiedzią na nieustannie zmieniające się potrzeby użytkowników, ale również pozwoli na zwiększenie wydajności i możliwości systemu? Odpowiedź jest prosta – należy wybrać architekturę mikroserwisową. O technologiach pozwalających na to rozwiązanie, samoorganizujących się zespołach i implementacyjnych wyzwaniach opowiadają architekt rozwiązania – Wojciech Kordeusz – oraz Project Manager i szef zespołu, Szymon Kopciuch (Przwczytaj więcej o roli i obowiązkach Product Manager w branży IT).
Czy to prawda, że współpraca Comarchu z Bankiem BNP Paribas trwa już ponad 10 lat?
[Szymon Kopciuch] Zgadza się, początki naszej współpracy sięgają roku 2006, kiedy rozpoczęliśmy realizację projektu bankowości internetowej dla klientów indywidualnych. Od roku 2006 do dzisiaj wspólnie wdrożyliśmy z sukcesem wiele projektów. Zawsze
wybieramy najnowocześniejsze dostępne technologie i nie jest inaczej dla obecnie realizowanego, największego i najważniejszego dla nas projektu nowej bankowości internetowej o kodowej nazwie GOonline Biznes. Wspomniany projekt jest realizowany w oparciu o mikroserwisy, czyli najnowszy trend w sektorze finansowym i nie tylko.
Jak wyglądały początki budowy nowej bankowości internetowej GOonline Biznes, skąd wybór zastosowanych technologii?
[SK] Pierwsze rozmowy dotyczące projektu zaczęły się w 2019 roku. Jednym z głównych celów naszej współpracy z Bankiem BNP Paribas było stworzenie platformy wyprzedzającej obecne standardy dla bankowości internetowej. Ważna dla nas była przede wszystkim otwartość platformy, aby w łatwy sposób rozszerzać system o nowe moduły funkcjonalne, realizowane wewnętrznym developmentem lub z udziałem firm trzecich, często zwanych Fintechami. Po wielogodzinnych projektowych spotkaniach podjęliśmy decyzję, że to architektura mikroserwisowa oraz technologie chmurowe będą najlepszym wyborem. Mówiąc mikroserwisy, mam na myśli nie tylko warstwę backend, ale również frontend zwaną w naszej branży mikrofrontendem. Oprócz wspomnianej otwartości platformy zmiana architektury z monolitycznej, w której była poprzednia bankowość internetowa, na mikroserwisową, pozwoliła znacząco skrócić wskaźnik Time-to-market nowej wartości biznesowej dla końcowych klientów, jak również zmniejszyć koszty developmentu np. nakładów na realizację całościowych testów regresyjnych.
Jak wygląda praca przy projekcie od strony technologicznej?
[Wojciech Kordeusz] Od strony technicznej było naprawdę interesująco. Od samego początku mogliśmy wybierać ze stosu nowoczesnych rozwiązań, co pozwala nam dobierać technologie do naszych potrzeb i kompetencji zespołów. Bardzo mocno korzystamy zarówno z frameworku Spring, jak i ze Spring Boot, natomiast nasze frontendowe aplikacje bazują na Angular Framework. Wszystkie mirkoserwisy są konteneryzowane, w tej kwestii zdecydowaliśmy się na Dockera. Kontenery te są uruchamiane na klastrze Openshift – platformy dla aplikacji kontenerowych, służącej między innymi do zarządzania kontenerami i ich orkiestracją. Niewątpliwą zaletą architektury mikroserwisowej jest to, że każda z aplikacji jest osobnym projektem, a pod każdy z projektów można dobierać najlepszy pod względem potrzeb i kompetencji stos. Nie ma ograniczenia, które występowało w ramach monolitycznych aplikacji, gdzie musieliśmy używać tych samych technologii, a co gorsze w tych samych wersjach. Teraz mamy i możemy sobie pozwolić na elastyczność, możemy stopniowo wdrażać i testować różne rozwiązania i różne wersje w ramach pojedynczych mikroserwisów. Dodatkowo podniosło to konkurencyjność projektu GOonline Biznes na rynku - zastosowanie nowoczesnych i sprawdzonych technologii to większa wydajność, większe możliwości i większe bezpieczeństwo. Wykorzystanie konteneryzacji znacząco usprawniło proces dostarczania i uruchamiania aplikacji.
Na jakie wzorce projektowe się zdecydowaliście, na jakie tak zwane dobre praktyki postawiliście podczas realizacji systemu w architekturze mikroserwisowej?
[WK] Każda z aplikacji to osobny projekt, niezależny od innych, z własnych cyklem życia. Jedyną formą komunikacji między mikroserwisami jest wywołanie usług świadczonych przez dany moduł, zdefiniowanych w jego API.
W ramach naszych projektów dokładamy wszelkich starań, aby być zgodnym z zasadami Clean Architecture, nasze działania są więc podzielone na odpowiednie warstwy. Jedną z tych warstw, o której szczególnie warto wspomnieć, są Domeny. W jej ramach stosujemy Domain-Driven Design (DDD) i zgodnie z zasadami tej warstwy modelujemy domenę, za którą odpowiedzialny jest dany mikroserwis.
Dodatkowo stosujemy wzorzec CQRS (Command Query Responsibility Segregation) – dzięki czemu mamy separację między stosami odczytu i zapisu. Unikamy także nadmiaru konfiguracji przez stosowanie się do Convention over configuration.
Wiemy, że jednym z najważniejszych aspektów systemów rozproszonych jest komunikacja. Jak zaadresowaliście ten obszar, na jakie narzędzia postawiliście?
[WK] Jak wspomniałem wcześniej, mikroserwisy komunikują się ze sobą przy użyciu usług zdefiniowanych w ramach API. Komunikacja ta może być synchroniczna i jest ona realizowana przez wywołanie usługi (REST lub http). Drugą opcją jest komunikacja asynchroniczna (np. Event), w której korzystamy z rozwiązania opartego na Apache Kafka. Stosujemy też wzorzec API Gateway, jego zadaniem jest świadczenie usług dla aplikacji klienckich (web/mobile) przez kierowanie żądań do odpowiednich mikroserwisów. Odciąża on pozostałe mikroserwisy od tzw. Cross-cutting concerns, jak np. autentykacja.
Czy podczas realizacji projektu spotkaliście się z implementacyjnymi wyzwaniami?
[WK] Oczywiście, że tak. Architektura mikroserwisowa pomaga w wielu aspektach, ale oczywiście stawia też wyzwania, które trzeba zaadresować. Takim wyzwaniem zdecydowanie było zapewnienie odpowiedniego poziomu transakcyjności systemu, aby dane w nim były spójne – mamy przecież do czynienia z systemem bankowym. Udało nam się tego dokonać przez wprowadzenie i implementację odpowiednich mechanizmów, przykładem może być szyna eventowa działająca w ramach transakcji oraz odpowiedni proces wymiany danych między mikroserwisami. Spore znaczenie w tej kwestii miało także odpowiednie wyznaczenie zakresu działań danego mikroserwisu. Nie powinien być on zbyt mały, gdyż może to wprowadzać niepotrzebne narzuty na komunikację i zapewnienie spójności danych. Należy również zadbać o to, aby zakres działań mikroserwisu nie był zbyt duży – w tym wypadku wrócilibyśmy do monolitu, a tego przecież nie chcemy.
Jakie korzyści oprócz samych nowinek technologicznych dają mikroserwisy?
[SK] Oczywiście poza korzyściami biznesowymi i technologicznymi warto zaznaczyć, w jaki sposób ta nowa architektura wpływa pozytywnie na sposób pracy osób zaangażowanych w realizację projektu. Mikroserwisy, w sposób naturalny, wspierają i wzmacniają zwinne projektowanie aplikacji i kreowanie samoorganizujących się zespołów. Zdecydowaliśmy się na realizację projektu w metodologii Scrum (sprawdź artykuł "Metodyka zwinna lekiem na całe zło, czyli o co w tym Scrumie chodzi?"), utworzyliśmy autonomiczne zespoły, które zajmują się przypisaną tylko do nich domeną biznesową jak np. płatności albo kredyty. Ten wybór, wraz z ogromnym kredytem zaufania od zleceniodawców, spowodował wiele pozytywnych efektów, między innymi wzrost motywacji wszystkich członków zespołów, co w konsekwencji przełożyło się na codzienną satysfakcję z pracy i uśmiech na twarzach. Przepis na czerpanie przyjemności z pracy przy architekturze mikroserwisowej jest bardzo prosty, wystarczy upoważnić zespoły scrumowe do podejmowania i wdrażania własnych pomysłów, dać miejsce do eksperymentowania i popełniania błędów oraz elastyczność w doborze technologii w ramach własnego mikroserwisu. Architektura mikroserwisowa pozwala zespołom skupić się na własnym obszarze bez negatywnej ingerencji w obszary innych zespołów, co było częste w systemach w architekturze monolitycznej.
Wspomniałeś o zespołach, ile osób pracuje przy projekcie? Czym kierowaliście się tworząc zespoły?
[SK] Odpowiedni dobór osób jest bardzo istotny. Jednym z głównych kryteriów, którymi się kierowaliśmy, było spełnienie jednego z głównych założeń scruma, którym są samowystarczalne zespoły. Oznacza to, że w skład zespołu wchodzą analitycy, developerzy, architekci, QA itd. W najbardziej gorącym momencie projektu, w ramach zespołów scrumowych pracowało ponad 50 osób. Bez podejścia scrumowego i mikroserwisów nie udałoby się zrealizować tylu funkcjonalności w tak krótkim czasie.
Czy z waszej pespektywy warto wybrać Comarch jako miejsce rozwoju swojej kariery?
[WK] Oczywiście, że tak. Mam nadzieję, że nasza rozmowa odzwierciedla to, jak bardzo interesujące są projekty realizowane w Comarchu. Z własnego doświadczenia wiem, że jest to naprawdę istotny aspekt w pracy. Comarch to duża firma z wieloma takimi projektami, oddziałami i klientami na całym świecie, także możliwości są spore i każdy znajdzie coś dla siebie niezależnie od tego, czy jest osobą z wieloletnim doświadczeniem, czy też kimś na początku swojej kariery.
[SK] Można wymieniać wiele czynników dlaczego warto pracować w Comarch ale ja wymienię trzy według mnie najważniejsze. Pierwszy z nich to możliwości, jakie czekają na każdego nowego pracownika, niemal od chwili przekroczenia „progu budynku” (chociaż teraz bardziej odpowiednią metaforą powinno być „uruchomienie komputera”). Na starcie otrzymuje on zadania w jednym z aktualnie realizowanych projektów, nie czeka wiele tygodni, zanim zobaczy efekty swojej pracy w produkcyjnym uruchomieniu. Oczywiście podczas pierwszych miesięcy prace realizowane są przy wsparciu i pod okiem doświadczonego mentora. Drugi czynnik to najnowocześniejsze technologie, których używamy w swoich produktach i wymiana wiedzy w zespołach. Ułatwia to rozwój i poszerzenie wiedzy pracowników. A trzeci powód, dla którego warto wybrać pracę w Comarch to przyjazna atmosfera wśród wszystkich osób zaangażowanych w projekty. Z ogromną przyjemnością pracuje się, kiedy wiesz, że będziesz spotykał osobiście, jak również, w dzisiejszych czasach, wirtualnie, przyjazne i uśmiechnięte twarze Twoich współpracowników, czego doświadczam na co dzień w naszym dziale.