TL;DR: kiedy warto
Jakie są podstawowe kryteria stosowalności mikroserwisów?
Warto rozważyć wejście w tę architekturę, jeżeli:
-
biznes, z którym pracujesz, jest gotowy porzucić klasyczny release’owy model pracy,
-
poszczególne jednostki biznesowe potrafią autonomicznie realizować projekty,
-
potrzebujesz dynamicznej i asymetrycznej skalowalności.
Buzzwordy i pułapki
Mikroserwisy od wielu lat zajmują wysokie miejsce w rankingu najgorętszych pojęć w IT. Stały się buzzwordem, który brzmi nowocześnie i profesjonalnie, daje poczucie, że firma idzie z duchem czasu.
Problem w tym, że jak przy większości buzzwordów, łatwo wpaść w pułapkę. Jeśli za terminem „mikroserwisy” nie stoi głębokie rozumienie tej architektury, bardzo szybko można skończyć z rozwiązaniem, które nie przynosi wartości, a wręcz spowalnia rozwój.
Dzisiaj widzimy podobny schemat przy AI. Firmy chwalą się „sztuczną inteligencją”, która oznacza po prostu ChatGPT, Gemini albo inny LLM. Jest modnym dodatkiem do prezentacji dla zarządu, a nie realną przewagą. Mikroserwisy przeszły identyczną drogę kilka lat temu: modne hasło stało się celem samym w sobie, zamiast być środkiem do rozwiązania konkretnych problemów.
Dlatego warto spojrzeć na nie bez złudzeń. Mikroserwisy to jedna z najtrudniejszych architektur, wymagająca dojrzałych zespołów, autonomii i odpowiedzialności. Bez tego zamiast elastyczności dostajesz złożoność i frustrację.
Pytanie brzmi: co trzeba zrobić, żeby dobrze wykorzystać ten rodzaj architektury? Jakie warunki musimy spełnić, aby wniósł on coś więcej w naszą pracę niż tylko zapis w CV?
Ale to już było…
Zanim mikroserwisy trafiły na konferencyjne slajdy, branża IT miała już swoją „rewolucję” w postaci SOA (Service Oriented Architecture).
W dużym skrócie polega ona na budowie dużych systemów z wielu zintegrowanych ze sobą, podzielonych logicznie usług. W założeniu miało to wyeliminować główne problemy związane z architekturą monolityczną.
Większość wdrożeń SOA opierała się (lub migrowała) w kierunku wykorzystania szyny integracyjnej Enterprise Service Bus (ESB). Szyna odpowiadała za:
-
routing komunikacji,
-
mapowanie dokumentów,
-
obsługę różnych rodzajów endpointów,
-
audytowanie i bezpieczeństwo.
Idea była szczytna, jednak wszechstronność rozwiązania okazała się bronią obosieczną. Po pewnym czasie szyna przeradzała się w kolejny monolit. Centralizacja, wąskie gardło i single point of failure przyczyniały się do rosnącej krytyki rozwiązania.
Zdarzały się przypadki, w których nad szyną pracował 60–80-osobowy zespół, a i tak część komunikacji trzeba było puszczać bokiem, by nie blokować projektów biznesowych.
Mikroserwisy jako lekcja po SOA
Architektura mikroserwisów, de facto implementacja stylu SOA, powstała na bazie doświadczeń z ESB.
Kluczowa zmiana: zamiast wszechwładnej szyny pojawiła się komunikacja point-to-point. Miało to wyeliminować wąskie gardła i pozwolić na niezależny rozwój projektów.
Mikroserwisy nie są mikro
Jak małe są mikroserwisy?
Jedną z bardziej wątpliwych metod oceny rozmiaru aplikacji jest liczba linii kodu. Na początek będzie ona jednak wystarczająca.
Najczęstsza odpowiedź na pytanie, „ile linii kodu powinien mieć statystyczny mikroserwis?”, to „1000”. Nie chciałbym stawiać się w roli wyroczni, oceniając, czy to dobrze, czy źle. Sięgnijmy jednak po wsparcie matematyki (z pierwszych klas szkoły podstawowej).
Przyjmijmy, że średnia wielkość jednej aplikacji monolitycznej (rozwijanej przez 20–30-osobowy zespół) to pół miliona linii kodu. Jeżeli podzielmy to na komponenty po tysiąc linii, w teorii otrzymamy 500 serwisów. To niewiele mniej niż mają giganci typu Netflix czy Uber. Na całą firmę. Rozwijanych przez blisko dwa tysiące inżynierów. A my mamy 30.
Czy to znaczy, że trzeba zatrudnić dodatkowo 1970 osób, żeby przejść na nową architekturę? Czy może jednak lepiej zmienić poziom granulacji?
Bardziej realistyczne podejście
Przyjmując, że nad jednym serwisem może pracować 3–5 osób, nasz monolit podzielmy przykładowo na 8 aplikacji. Każda z nich będzie miała średnio ok. 60 tysięcy linii. I to jest już bardziej realne. Jako programista bez problemu mogę ogarnąć szczegółowo aplikację tej wielkości. Można w niej także zaimplementować konkretny kawałek biznesu i skutecznie rozwijać go niewielkim, zwinnym zespołem.
W głowie może rodzić się natomiast pytanie: co właściwie jest nie tak z małymi serwisami? Czemu mam ufać innym? Po pierwsze, warto zauważyć, że ich rozwiązania działają bardzo dobrze, co może być wyznacznikiem właściwego toku rozumowania. To właśnie dostępność platformy jest głównym powodem takiej, a nie innej granulacji aplikacji. W przypadku wykorzystania synchronicznej komunikacji między usługami, ujawnia się zjawisko określane jako „temporal coupling”. Do kontynuacji procesowania transakcji biznesowej konieczne jest uzyskanie odpowiedzi od drugiej usługi. Ta druga może z kolei wołać trzecią i tak dalej. Im większa jest taka „synchroniczna głębokość systemu”, tym mniejsza jego dostępność.
Nie mam użytkowników: czy mikroserwisy mi pomogą?
Wokół mikroserwisów narosło bardzo dużo mitów. Jeżeli miałbym wierzyć we wszystko, co o nich słyszałem na konferencjach, prawdopodobnie upierałbym się, że dług publiczny i głód na świecie można rozwiązać, rozbijając monolity na mikrousługi. Nie muszę nawet komentować, jaka to bzdura. (A może jednak muszę? Nie wierz ślepo we wszystko, co Ci mówią na konferencjach!)
Autonomia jako fundament mikroserwisów
Czym mikroserwisy różnią się od klasycznego systemu rozproszonego? Słuchając kuluarowych dyskusji, można dojść do wniosku, że jest to informatyczny odpowiednik przechwalania się ceną czy wielkością samochodu. „Ile masz mikroserwisów? Bo my mamy 400”. Szczerze mówiąc, ja wolę mieć 40 porządnych, niż 400 nastrzelanych tylko po to, żeby mieć się czym pochwalić przed znajomymi. Podstawowa różnica między mikroserwisami a klasycznym systemem rozproszonym leży w autonomii. System rozproszony, mimo że realizuje proces za pomocą wielu rozdzielnych systemów, koncepcyjnie przypomina monolit. Wszystkie systemy są aktualizowane wspólnym wdrożeniem i często nawet nie obsługują niedostępności kolaboratorów (aplikacji, z którymi się komunikują). W mikroserwisach jest zupełnie inaczej. Każdy serwis ma swój cykl życia. Prace nad poszczególnymi aplikacjami prowadzone są niezależnie i wdrażane bez koordynacji. Nie jest niczym niezwykłym sytuacja, w której usługa, od której jesteśmy zależni, nie jest dostępna, bo akurat trwa wdrożenie nowej wersji.
Autonomia ta jest ogromną siłą mikroserwisów. Pozwala na prawdziwie zwinny i skalowalny rozwój systemu. Odchodzą do lamusa dyskusje typu: „nie można teraz wdrażać projektu X, bo projekt Y jeszcze nie wytestował swoich poprawek”. Niestety, ta niezależność powoduje także, że mikroserwisy są zdecydowanie najtrudniejszą architekturą, z jaką pracowałem. Konieczność stałej pracy w modelu „design for failure” i przewidywania zawczasu wszelkich problemów związanych z komunikacją, przyprawiają o ból głowy nawet najlepszych programistów i architektów. Z drugiej strony, jeżeli biznes nie jest gotowy pracować w takim modelu i naciska na pozostanie w modelu release’owym, mikroserwisy tracą jedną ze swoich największych wartości. A koszty i problemy pozostają.
Gdzie są granice?
Jednym z najtrudniejszych zadań przy wdrażaniu architektury mikrousług jest prawidłowe określenie ich granic.
Bounded Context i własność domeny
Pierwszym przybliżeniem jest tutaj znany z Domain Driven Design koncept Bounded Context’u. W każdym kontekście istnieje zazwyczaj ekspert domenowy, będący często biznesowym właścicielem realizowanych tam procesów. Co za tym idzie, ograniczenie wielkości aplikacji do obszaru zarządzanego biznesowo przez jedną osobę, gwarantuje większy ład i spójność niż w przypadku konieczności godzenia różnych grup interesów.
Własność danych i procesy
Kolejnymi istotnymi aspektami do rozważenia są także własność danych i kroki procesów biznesowych. Jeżeli dwa pozornie rozłączne konteksty wpływają na te same dane, może to oznaczać, że podział na nie jest sztuczny. Może też jednak okazać się, że niezbędne jest wyznaczenie trzeciego niezależnego kontekstu, zarządzającego danymi wykorzystywanymi w innych procesach.
Powyżej wymieniłem główne, aczkolwiek nie jedyne kryteria podziału serwisów. Jeżeli jedna z funkcji może być zdecydowanie efektywniej zrealizowana w innej technologii (np. zaimplementowana w innym języku) niż główny serwis, warto rozważyć ich rozdzielenie. Podobnie wygląda kwestia skalowalności. Wiedząc, że określone funkcje będą wykorzystywane bardzo intensywnie, warto rozważyć wyniesienie ich do osobnego komponentu.
Trzecim, często rozpatrywanym aspektem jest bezpieczeństwo. Jeżeli wymagania w tym zakresie znacząco różnią się między poszczególnymi funkcjami, wrzucanie ich do jednej aplikacji może nie być najlepszym pomysłem.
