Trzy powody, dla których warto przejść z architektury monolitycznej na mikroserwisową

Mikroserwisy cieszą się coraz większą popularnością. Korzystają z nich duże platformy digitalowe jak Netflix, eBay, Blablacar. W Polsce używają ich także Allegro, Znanylekarz czy Trans.eu - jedna z dwóch największych platform transportowych w Europie, na której codziennie zawierane są setki tysięcy transakcji pomiędzy dziesiątkami tysięcy użytkowników.

Jak zdefiniować mikroserwis? To niewielka rozmiarem usługa, taka, której przygotowanie trwa nie więcej niż kilka tygodni, realizująca funkcje z pojedynczego obszaru biznesu. Przykładowo, mikroserwisem w tym rozumieniu nie będzie cały system CRM, ale może być nim funkcja resetowania hasła użytkownika.

“Decyzję o przejściu na architekturę mikrousługową podjęliśmy cztery lata temu. Dzięki tej zmianie możemy szybciej wdrażać kolejne funkcjonalności, zredukowaliśmy także dług techniczny. Nie traktujemy przy tym mikroserwisów jako panaceum - świadomie wybraliśmy obszary, w których ich używamy.” - mówi Bogdan Kosturek, CTO w Trans.eu Group S.A.

Zobacz również:

Jest wiele powodów, dla których warto pójść tą samą drogą, co duże platformy cyfrowe, i postawić na mikroserwisy. Przyjrzyjmy się bliżej kilku z nim.

Lepsze uporządkowanie kodu

Jak mówi prawo Conwaya, pracując nad systemem (w szczególności — informatycznym) organizacja odwzorowuje w nim swoją strukturę.

Jeśli nad monolitem będzie pracować organizacja złożona z wielu wykonawców, zlokalizowanych w różnych oddziałach i specjalizujących się w różnych technologiach

znajdzie to wyraz w jego kodzie.

Kod zespołów mających ze sobą dobry kontakt (np. pracujących w sąsiednich pokojach) może się ze sobą przeplatać. Z kolei zespoły z różnych firm będą oddzielone wyraźną techniczną barierą. Śledząc te różnice można dojść do wniosku że monolit wcale nie jest tak jednolity, jak by się wydawało.

Pracując w architekturze mikroserwisowej, takie różnice nazywa się wprost i porządkuje, stosując ustalone formy komunikacji.

Skrócenie czasu potrzebnego na dostarczanie nowych funkcji użytkownikom

Wdrażanie nowej wersji monolitu jest czasochłonne i podatne na błędy. Z pozoru zupełnie niezwiązane ze sobą zmiany mogą sprawić, że cały system stanie się niedostępny dla użytkowników. By temu zapobiec, we wdrożenia angażuje się zespoły odpowiedzialne za różne fragmenty monolitu. Ich zadaniem jest upewnienie się, czy wdrożenie nie przyniosło trudnych do przewidzenia skutków.

Tymczasem w przypadku architektury mikroserwisowej, wdrożenie zmian sprowadza się często do wdrożenia jednej, góra dwóch niewielkich mikrousług. Wykrycie przyczyn ewentualnych problemów jest wtedy dużo łatwiejsze.

W odróżnieniu od kłopotliwego monolitu, mikroserwisy można wdrażać nawet wiele razy na dzień. To powoduje, że konfrontowanie nowych pomysłów z rynkiem staje się o wiele łatwiejsze.

Ułatwienie sterowania poziomem długu technicznego

Unowocześnianie monolitu jest trudne, ponieważ wiele zmian (np. umieszczenie systemu w kontenerze) trzeba wykonywać od razu dla całego monolitu. Wysoka bariera wprowadzania zmian często zniechęca do spłaty długu technicznego.

Z kolei architektura oparta o mikroserwisy w naturalny sposób umożliwia tworzenie serwisów zgodnie z najnowszymi trendami. Dzięki ustaleniu formy komunikacji i wydzieleniu danego fragmentu z monolitu, można go wykonać w zupełnie inny sposób niż dotychczas, np. korzystając z bardziej adekwatnej technologii.

Uruchomienie systemu w chmurze czy podniesienie zakresu pokrycia testami różnych poziomów — gdy korzystamy z mikroserwisów, to wszystko staje się łatwiejsze.

Co ważne, taka migracja nie wymusza rozbicia całości monolitu na mikroserwisy. Można wydzielić z niego tylko wybrane fragmenty, a te, w które inwestować nie warto, mogą w nim pozostać. Daje to możliwość świadomego sterowania poziomem długu technicznego.

Łukasz Wróbel

Development Teams Leader w RST Software Masters

Autor ebooka “Od monolitu do mikroserwisów, czyli jak wyjść z architektury hamującej rozwój”