Podczas cotygodniowego przeglądania branżowej “prasówki” natknąłem się na artykuł (https://it-consulting.pl/2025/10/15/wzorzec-mikro-serwisy-i-api-gateway/), w którym autor przytacza argumenty przemawiające za szkodliwością “drobienia” usług w architekturze systemów. Doszukuje się w tym (uważam, że słusznie) konsekwencji powstawania tzw. “Gwiazd Śmierci”, nie wyjaśniając przy tym co przez to określenie rozumie. Jako preludium wyjaśnienia, zamieszczę swój komentarz do powyższego artykułu, a następnie rozwinę myśl.

Osobiście popularności mikrousług jako stylu architektonicznego doszukuję się w tym, że jest on bardzo na rękę wszelkiej maści dostawcom chmury obliczeniowej i platform programistycznych, które zarabiają ogromne pieniądze na kolejnych firmach pchających się w ten pomysł, zwłaszcza wdrażających swoje rozwiązania w PaaS. Zauważmy co się tutaj zadziało. Zamiast skalować infrastrukturę pod SUMARYCZNE zapotrzebowanie na moc obliczeniową naszego rozwiązania płacimy za każdą LOGICZNĄ jednostkę naszej architektury lub (za ArchiMate) za każdy element behawioralny warstwy aplikacji. Drobnienie usług do granic absurdu (słyszałem już nawet o nanousługach) jest im niesłychanie na rękę. Złożoność wynika z dziedziny problemu, a od projektanta i wykonawcy rozwiązania zależy jak będzie się to przekładało na koszty i czy powstanie owa Gwiazda Śmierci. Marcin Karczewski

Kontynuując moją myśl z powyższego komentarza: złożoność systemu jest zależna od jego dziedziny. Jeśli zamodelujemy strukturę referencyjnego rozwiązania realizowanego w różnych stylach architektonicznych (od monolitu po mikrousługi) powinniśmy otrzymać grafy o zbliżonej wielkości i gęstości. Jeśli tak nie jest, oznacza to, że wprowadziliśmy przypadkową, nadmiarową złożoność.

Różnica między Gwiazdą Śmierci a Gwiazdą Nie-Śmierci wynikać musi nie z samej struktury grafu, tylko kosztu generowanego przez jego poszczególne węzły (struktury, klasy, usługi, komponenty, moduły) oraz krawędzie (wywołania metod, RPC, SOAP, REST itd.).

W przypadku mikrousług wdrażanych w chmurze w formie PaaS koszt utrzymania pojedynczej mikrousługi wynosi często setki, a nawet tysiące PLN miesięcznie, a wywołania REST pomiędzy usługami są nieporównywalnie bardziej kosztowne obliczeniowo (latencja komunikacji pozaprocesowej, enkapsulacja protokołu HTTP itd.) oraz utrzymaniowo (wersjonowanie kontraktów, dokumentowanie, brak wsparcia IDE do nawigacji pomiędzy komponentami, ich wzajemnymi wywołaniami, wykrywania błędów w czasie kompilacji itp.).

Osobiście największych korzyści dopatruję się w dwóch przypadkach zastosowania mikrousług:

• Osiągnięcie ekstremalnej skalowalności zespołu (zespołu - nie samego systemu) zorganizowanego wokół danej usługi biznesowej / produktu core’owego (przykład - Allegro),

• Konieczności połączenia w jednym systemie bardzo skrajnych, czasem sprzecznych cech architektonicznych - wszelkiego rodzaju big-data, wygórowane wymagania wydajnościowe, niskiej latencji, przetwarzania strumieniowego itp. (Uber, Netflix, Amazon, inne "big techy").

Z drugiej strony, uważam, że wszelkiego rodzaju systemy LoB, wspierające procesy biznesowe i procesy w przedsiębiorstwie realizowane w stylu mikrousługowym mogą okazać się bardzo złożonymi przedsięwzięciami, chociażby z uwagi na utrudnienia w utrzymaniu spójności danych, niezawodności, transakcyjności itp.

A za szczególną formę masochizmu i samobiczowania uważam projekty, w których liczba mikrousług przewyższa liczbę programistów - prawo Conwaya działa bezlitośnie na rzecz powstania Gwiazdy Śmierci.