Mikroserwisy czy monolit — wybór architektury dla średniej firmy

Dla zdecydowanej większości systemów budowanych na potrzeby jednej firmy właściwym wyborem jest dobrze zorganizowany monolit. Mikroserwisy rozwiązują problemy skali organizacyjnej — wielu zespołów pracujących równolegle nad jednym produktem — i wprowadzają w zamian złożoność operacyjną, na którą mniejsza firma zwykle nie ma zasobów ani potrzeby.

Autor: zespół Convert Studio — software house z Kielc i Krakowa, projektujemy aplikacje webowe, sklepy i wdrożenia AI dla firm.

Na czym polega różnica

W monolicie cały kod żyje w jednym projekcie, korzysta ze wspólnej bazy danych i wdrażany jest jednym ruchem. Wywołanie funkcji z innego modułu to zwykłe wywołanie w kodzie — natychmiastowe i niezawodne.

W architekturze usługowej każdy obszar to osobna aplikacja z własną bazą. Wywołanie funkcji z innego obszaru to żądanie sieciowe, które może się nie powieść, opóźnić albo wykonać dwa razy. Ta jedna różnica generuje większość dodatkowej złożoności.

Realne koszty podziału

Materiały o mikroserwisach skupiają się na korzyściach. Poniższe pozycje pojawiają się dopiero w eksploatacji i to one przesądzają o tym, czy architektura jest utrzymywalna.

Spójność danych przestaje być darmowa

W monolicie zapis zamówienia i zdjęcie towaru z magazynu mieszczą się w jednej transakcji — albo oba się udają, albo żadne. Po podziale są to dwie osobne usługi i trzeba obsłużyć sytuację, w której pierwsza operacja się powiodła, a druga nie. Rozwiązania istnieją, ale każde z nich to dodatkowy kod, który trzeba napisać i przetestować.

Diagnoza błędu wymaga narzędzi

Gdy coś przestaje działać, trzeba ustalić, w której usłudze i na którym etapie. Bez śledzenia rozproszonego i wspólnego zbierania dzienników jest to praca detektywistyczna. To narzędzia, które trzeba wdrożyć i utrzymywać.

Środowisko lokalne przestaje być proste

Programista musi uruchomić kilka usług naraz razem z ich bazami i kolejkami. Nowa osoba w zespole traci na to pierwszy dzień zamiast pierwszej godziny.

Wersjonowanie interfejsów

Zmiana w jednej usłudze potrafi zepsuć inną. Potrzebne są wersjonowane interfejsy i okres, w którym działają obie wersje — czyli dyscyplina, której w monolicie nie trzeba egzekwować, bo kompilator albo testy wyłapią niezgodność od razu.

Kiedy podział ma sens

• Kilka niezależnych zespołów pracuje nad jednym produktem i blokuje się nawzajem przy wdrożeniach.
• Jeden fragment wymaga zupełnie innego skalowania — na przykład przetwarzanie plików obciąża system stukrotnie bardziej niż reszta.
• Fragment ma inne wymagania dostępności. Płatności muszą działać zawsze, panel raportowy może mieć przerwę.
• Część systemu wymaga innej technologii, której nie da się sensownie osadzić w głównej aplikacji.
• Obszar podlega odrębnym wymogom zgodności i musi być odseparowany także infrastrukturalnie.
• Fragment jest rozwijany przez zewnętrznego dostawcę i potrzebuje jasnej granicy odpowiedzialności.

Jeśli żaden z tych warunków nie zachodzi, podział nie rozwiąże problemu, który faktycznie masz — a doda kilka nowych.

Wariant pośredni — monolit modularny

Między jedną wielką aplikacją a kilkunastoma usługami istnieje rozwiązanie, które w praktyce sprawdza się najczęściej: monolit modularny.

Kod jest podzielony na wyraźne moduły z jasno określonymi granicami. Moduł nie sięga bezpośrednio do tabel innego modułu — korzysta z jego interfejsu. Wdrożenie pozostaje jednak jedno, baza wspólna, a transakcje działają normalnie.

Zaletą jest to, że dyscyplina granic powstaje od początku, a koszt operacyjny pozostaje niski. Gdy któryś moduł faktycznie wymaga wydzielenia, jest do tego przygotowany — granice już istnieją, trzeba tylko zamienić wywołania wewnętrzne na sieciowe.

• Moduł ma własny katalog i wyraźnie oddzielony interfejs publiczny.
• Dostęp do danych innego modułu wyłącznie przez ten interfejs, nigdy zapytaniem do jego tabel.
• Testy na poziomie modułu, nie tylko całej aplikacji.
• Zasada egzekwowana automatycznie — narzędzie sprawdzające zależności zapobiega obchodzeniu granic pod presją terminu.

Sygnały, że monolit przestaje wystarczać

• Wdrożenie stało się wydarzeniem. Jeśli wypuszczenie zmiany wymaga koordynacji kilku osób i okna serwisowego, coś jest nie tak — ale przyczyną bywa brak automatyzacji, nie architektura.
• Zespoły czekają na siebie. Jeden nie może wdrożyć, bo drugi ma niedokończoną zmianę w tej samej gałęzi.
• Jeden fragment przewraca całość. Ciężkie raportowanie spowalnia obsługę zamówień, bo dzielą zasoby.
• Skalowanie jest marnotrawne. Zwielokrotniasz całą aplikację, choć obciążony jest jeden jej fragment.
• Czas uruchomienia i testów urósł na tyle, że hamuje pracę.

Warto sprawdzić, czy każdego z tych objawów nie da się usunąć taniej — automatyzacją wdrożeń, wydzieleniem ciężkich zadań do kolejki albo optymalizacją zapytań. Podział na usługi jest najdroższą z możliwych odpowiedzi i warto po niego sięgać jako po ostatnią.

Jeśli decydujesz się na podział

• Wydzielaj po jednym. Zacznij od fragmentu o najwyraźniejszej granicy i najmniejszej liczbie powiązań.
• Granice według obszarów biznesowych, nie warstw technicznych. Usługa „zamówienia" ma sens, usługa „baza danych" nie.
• Najpierw narzędzia, potem podział. Zbieranie dzienników, śledzenie rozproszone i monitoring muszą działać, zanim ruch rozejdzie się na usługi.
• Zaplanuj obsługę awarii — co się dzieje, gdy usługa nie odpowiada. Limity czasu, ponowienia, tryb ograniczonej funkcjonalności.
• Nie dziel bazy na siłę. Wspólna baza przy dwóch usługach jest kompromisem, ale bywa mniejszym złem niż przedwczesny podział danych.
• Mierz efekt. Jeśli po wydzieleniu pierwszej usługi nie widać poprawy, zatrzymaj się i sprawdź założenia.

Praktyczne kryterium wyboru

Zamiast porównywać architektury, odpowiedz na trzy pytania. Ile niezależnych zespołów pracuje nad systemem. Czy któryś fragment ma radykalnie inne wymagania obciążeniowe lub dostępnościowe. Czy macie kompetencje i czas na utrzymanie infrastruktury rozproszonej.

Trzy razy „nie" oznacza monolit — najlepiej modularny. Choć jedno „tak" uzasadnia rozważenie wydzielenia konkretnego fragmentu, ale nadal nie całego systemu. Pełna architektura usługowa to odpowiedź na problem, który mniejsze firmy rzadko mają. O tym, jak w ogóle podchodzić do budowy systemu, pisaliśmy w materiale o MVP krok po kroku, a szerszy obraz naszego podejścia znajdziesz na stronie aplikacje webowe.

Wpływ na pracę zespołu

Architektura przekłada się na codzienną pracę mocniej, niż wynikałoby z samych rozważań technicznych. To wymiar, który przy podejmowaniu decyzji bywa pomijany, a odczuwany codziennie.

Wdrożenie nowej osoby

W monolicie nowy programista uruchamia projekt i po godzinie widzi działającą aplikację. Przy kilkunastu usługach ten sam etap zajmuje dzień lub dwa, a zrozumienie, gdzie kończy się jedna odpowiedzialność, a zaczyna druga, jeszcze dłużej.

Diagnoza zgłoszenia od użytkownika

„Nie mogę złożyć zamówienia" w monolicie prowadzi do jednego dziennika i jednego śladu wykonania. W systemie rozproszonym trzeba prześledzić żądanie przez kilka usług, co bez odpowiednich narzędzi bywa godzinami pracy zamiast minutami.

Odpowiedzialność za fragment

To jedyny obszar, w którym podział wygrywa zdecydowanie. Gdy usługa ma właściciela, wiadomo, kto odpowiada za jej działanie, wydajność i rozwój. W dużym monolicie odpowiedzialność bywa rozmyta, a fragmenty kodu, których nikt nie uznaje za swoje, degradują się najszybciej.

Na koniec warto zauważyć, że wybór architektury rzadko bywa nieodwracalny. Monolit modularny da się rozłożyć na usługi, gdy zajdzie taka potrzeba, a przedwcześnie podzielony system można z powrotem scalić — choć to operacja rzadsza i trudniejsza, bo wymaga uzgodnienia danych rozproszonych po kilku bazach. Dlatego przy wątpliwościach bezpieczniej zacząć od rozwiązania prostszego i podzielić je później, niż zacząć od podziału i cofać się z niego pod presją kosztów utrzymania.

Podsumowanie

Mikroserwisy są rozwiązaniem problemu organizacyjnego, nie technicznego. Jeśli nad systemem pracuje jeden zespół, podział przynosi koszty operacyjne bez korzyści, dla których go się stosuje. Domyślnym wyborem powinien być monolit z wyraźnym podziałem na moduły — daje dyscyplinę granic przy niskim koszcie utrzymania i pozostawia otwartą drogę do wydzielenia fragmentu, gdy stanie się to potrzebne.

Zanim podejmiesz decyzję, wypisz konkretny problem, który podział ma rozwiązać, i sprawdź, czy nie da się go usunąć taniej. W większości przypadków, z którymi się spotykamy, odpowiedzią okazuje się automatyzacja wdrożeń albo wydzielenie ciężkich zadań do kolejki — a nie przebudowa architektury.