Jest rok 2016. Pierwszy raz dołączam do dużego projektu w skali „enterprise” i moje oczy świecą się od liczby rozwiązań jakie organizacja dostarcza. Niezliczona liczba tabel, terabajty danych, dziesiątki jak nie setki usług, wiele zespołów wytwórczych i równie wiele (jak nie więcej) środowisk uruchomieniowych.

Dla osoby, która (chyba jak każdy programista) uwielbia rozwiązywanie trudnych układanek, to był raj na ziemi. A przynajmniej takim się wydawał.

Do momentu, gdy odkryłem skróty, które po dziś dzień powodują ciarki na plecach: SOA, SOAP, WSDL, WCF.

Miałem bowiem przyjemność uczyć się systemów rozproszonych w czasach, gdy fala SOA (Service-Oriented Architecture) już opadła, a jej miejsce (przynajmniej w Polsce) zaczynał zajmować rozpędzający się hype train na mikroserwisy.

I trudno się zresztą tej gorączce dziwić. W końcu było co poprawiać!

Zarówno organizacje, z którymi współpracowałem bezpośrednio, te, o których słyszałem choćby na konferencjach, jak i te, które miałem okazję konsultować lub szkolić – wszystkie cierpiały na te same problemy:

🗿 Model kanoniczny, 🫷niejasne granice, 🗃️ jedna wielka baza, niby oddzielne zespoły ale często splątane ze sobą 🪢 zależnościami, wspólne kontrakty wymuszane przez „integracyjny klej”, 🔮 wróżenie z logów i 🌙 nocne okna serwisowe.

Jak to często bywa w IT, będąc na piętnastej z rzędu konferencji, słysząc „nie robisz mikro, to robisz legacy” i poniekąd utożsamiając się z tymi problemami, postanowiłem nie pozwolić, by pociąg mi odjechał 🚃, i zacząłem implementować mikroserwisy.

Mija powoli dziesięć lat od początku mojej przygody z systemami rozproszonymi i niewiele mniej od wdrożenia pierwszej… mikro? nano? makro? No, jakiejś usługi.

Analizuję w głowie zarówno dawne, jak i obecne projekty, w których „poszliśmy w mikrousługi”, i o ile w większości nie zauważam problemów wymienionych wyżej, to mam wrażenie, że wcale nie jest prościej. A na pewno nie jest łatwiej.

Zaryzykuję nawet stwierdzenie, że mikroserwisy dla wielu osób będących w branży 5–6 lat (lub krócej) są tym samym koszmarem co dla mnie SOA. Czymś, co „ktoś gdzieś wymyślił”, a z czym trzeba się teraz męczyć.

Tylko DLACZEGO?

Będzie to oczywiście moja prywatna opinia, ale myślę, że jakieś 10 lat temu, próbując naprawić porażki Service-Oriented Architecture, jako branża postanowiliśmy wmówić sobie, że jesteśmy kolejnym Amazonem, Netflixem, Googlem – czy co tam kto woli.

Potem namaściliśmy w każdej firmie paru wybrańców, awansując ich do architektonicznej ivory tower, by rozrysowywali nam rzeczywistość, tym razem ubraną w nowe domki zwane „mikrousługami”. Po to tylko, by na końcu dołożyć do tego nowsze zabawki (w końcu stare były nudne i nie działały): zamiast ESB → RabbitMQ/Kafka, zamiast SOAP → REST over HTTP, zamiast prosto na IIS-a/Tomcata/Apache’a – sru na Kubernetesa itd., itd.

A wszystko to w myśl: teraz już na pewno będzie lepiej. 🧠 I chyba trochę jednak jest!

Tylko pytanie, na ile wpływ na to miało „dojrzewanie” wciąż bardzo młodej branży, jaką jest IT, a na ile pomogły nam sukcesy i porażki podejścia, jakim są mikroserwisy?

Zamiast smęcić i wspominać jakbym miał szóstkę, a nie trójkę z przodu mojego życiowego licznika, spróbuję subiektywnie spojrzeć na to, co właściwie dobrego z tych mikro „serwajsów” wyniknęło. I czego może nas jeszcze ta architektura wdrożeniowa nauczyć.
Zwłaszcza, że skoro nie jest prościej ani łatwiej, a mimo wszystko trochę lepiej, to warto odczarować to dość niejasne równanie.

Zacznijmy więc od… rozmiaru 👀

W końcu niejedna dyskusja nad mikrousługami w przeciągu ostatnich 10-12 lat zeszła niemal całkowicie na temat wielkości mikrousługi. Czy jak dołoże jeszcze jeden kontroler czy jeden handler to będzie to „jeszcze” mikroserwis?

Okazuje się, że – ponownie, moim zdaniem – nie ma to kompletnie znaczenia.

Znajdziemy w Internecie wiele opinii o metrykach typu 100 czy 1000 linii kodu to max na mikroserwis. Że powinno się go dać w sprint czy dwa przepisać. A z drugiej strony mamy zderzenie z rzeczywistością – w tym tempie w ciągu roku czy dwóch zamiast jednego monolitu mam 200 usług (i licznik wciąż rośnie!).

Czy to dobrze? Źle? Czy taka „nanousługa” jest gorsza od klasycznej usługi z paroma tysiącami linii? Albo czy jest lepsza od „makrousługi” która ma 10k LOC (albo i więcej)?

Jak to każdy szanujący się konsultant by powiedział: TO ZALEŻY.

Czasami lepiej jeden wrażliwy wrapper na 3rd party zamknąć w ramach nanousługi i ograniczyć blast radius 💣
A czasami lepiej połączyć pare usług w jedną, tak by ograniczyć koszt utrzymania, narzut komunikacyjny i konieczność orkiestrowania procesu biznesowego, który przy dobrych wiatrach opędzą dwa handlery w modularnym monolicie.

Jak więc widać już po dwóch prostych przykładach – dylemat mikroserwisy vs monolit nie jest tak prosty do rozstrzygnięcia. 😉

Żeby jednak wiedzieć, co wydzielić, a co łączyć (i jak nie oglądać się tak bardzo na metryki LOC), warto oddać „modzie na mikrousługi” jedno – zaczęliśmy dużo inaczej patrzeć na granice odpowiedzialności, a co za tym idzie – granice usług. Pytanie „jak podzielić system na mikroserwisy?” w końcu zaczęło padać przed wdrożeniem, nie po (najwyższa pora 🧠).

Skoro tak bardzo bolał model kanoniczny i splątanie ze sobą usług na poziomie komunikacji czy technologii, to niemożliwe było dyskutowanie o złotym Graalu 🏆 managerów, czyli autonomii zespołów, która ma (zazwyczaj) przełożenie na szybszy time-to-market pojedynczych feature’ów.

No i mikrousługi całkiem nieźle to adresują między innymi dwoma ściśle powiazanymi ze sobą flagowymi postulatami: osobna baza per serwis oraz podejście API-first.

I nie mam absolutnie żadnego „ale” do tych zasad. Używam ich od samego początku, sprawdzają się świetnie i ograniczają „swędzące rączki” pobierające czy zmieniające dane poza właściwym procesem biznesowym.
A przy okazji przez jasną definicję kontraktu ze światem w postaci API mam konkret: co mogę, a czego nie w danej usłudze.

Jest tylko jedno „ale”. To wymaga pewnego manewru wyprzedzającego. 🪖 Bo do osobnej bazy potrzebny jest osobny serwis. A do osobnego serwisu – jasno określone jego granice. A z tym bywa różnie…

Podczas szkoleń z tematów distributed bardzo lubię prowadzić dyskusje wokół poniższego obrazka:

Zaczynam od pokazania powyższego obrazka bez kontekstu firm. Bardzo szybko padają głosy, że to „ulep” albo przynajmniej marna architektura. I że na pewno tak się nie robi mikrousług.

… dopóki nie odsłaniam logo firm, które za nimi stoją 😅

Skąd ten dysonans? „Nie no przy ich skali i procesach to pewnie ma sens„ – mówi wielu uczestników. I pełna zgoda. Zapewne (mam nadzieję 😄) ta architektura odzwierciedla odpowiednio ich potrzeby oraz rozwiązania problemów, ktore napotkali.

I tak samo powinno być w przypadku Twojego czy mojego systemu. Ale czy tak jest?

Mamy 2026 rok a ja śmiało mogę powiedzieć – może i umiemy implementować dobrze odizolowane usługi. Ale wydzielać je? A potem weryfikować, czy w ogóle łączą się w spójną (procesowo) całość? I aplikować do tego odpowiednie wzorce komunikacji?

No nie za bardzo.

A jeśli myślisz, że na brak jasnych granic usług można machnąć ręką i powiedzieć: „A tam, zrobimy na oko, a potem jakoś to pójdzie lub się wyprostuje”, to zastanów się, jak wygląda to z punktu widzenia nowej osoby w zespole.

To doskonały test jakości Twojego rozwiązania i prawdziwy sprawdzian onboardingu w projekcie opartym na mikroserwisach. Jeśli sprowadza się on do „wszystko jest w kodzie, a reszta w Wiki/Confluence„, to mamy problem.

Problem, który widuję na co dzień (i sam biję się w pierś!): brak uzasadnienia wydzielenia danej usługi (to tak wynika z procesu? czy tak nam się wydaje?). Niejasność powiązań z innymi obszarami (czemu po HTTP, a nie AMQP?). Trudność w identyfikacji, gdzie leży problem (to u mnie ta 500-tka czy w usłudze downstream?). A do tego: czy ktoś już zaimplementował dane capability? A może każdy śle maile po swojemu?

Mogę tak wymieniać i wymieniać.

Tym bardziej to dziwi, gdyż przynajmniej połowa wymienionych bolączek ma swoje rozwiązania w formie „pudełka”. Oczywiście wymagające integracji, ale jednak. W końcu observability, service catalog czy OpenAPI + AsyncAPI nie są jakimś „rocket science”. Z drugiej strony nie da się ukryć, że patrząc na wiele systemów, ich adopcja (nie mylić z implementacją!) nawet w 2026 roku często kuleje.

Z czego to wynika? Nie wiem do końca, ale wygląda na to, że nowa, wzbierająca fala w IT w jakimś stopniu to zmieni.

Patrząc na ten „obraz po bitwie„, który zarysowuję, dotykając jedynie wierzchołka góry lodowej problemów wokół mikrousług, nie da się oprzeć pokusie: „A może AI by to ogarnęło?„.

I będę tu absolutnie szczery i pragmatyczny – TAK, do pewnego stopnia AI jest w stanie pomóc nam odnaleźć się w ogromnym systemie składającym się z dziesiątek, jeśli nie setek usług. W jakimś stopniu będzie w stanie opisać nam, co robi kod (choć nie dopowie, co autor „miał na myśli”). I pewnie nie raz wesprze nas przy podejmowaniu jakiejś decyzji, zwłaszcza w aspektach technicznych. I na pewno szybciej niż my przejrzy stos logów z ostatniego tygodnia (tylko jakim kosztem… 💸).

Pytanie brzmi tylko: gdzie jest tu miejsce dla nas? Jak w sposób aktywny jesteśmy w stanie świadomie uczestniczyć w tym procesie decyzyjnym?

Moja opinia jest następująca. 👇

Oczywistym jest, że pisanie kodu nie jest celem samym w sobie i jego produkcja narzędziami jak Claude Code czy inne agentowe rozwiązania będzie tylko przyspieszać. AI w programowaniu w 2026 roku to już nie eksperyment a codzienność.

Więc jeśli weźmiemy pod uwagę, tempo przyrastania rozwiązań i zderzymy to z trudami utrzymania setek usług pisanych (jeszcze) rękoma ludzi to… zatoniemy. Brak jasnych ram, narzędzi i świadomości co, gdzie i kiedy działa spowoduje wyłącznie jedno – jeszcze większy software’owy śmietnik. 🗑️

Ale jest druga strona tego medalu!

Przy dobrze wyznaczonych granicach, jasnym blast radius, zdefiniowanych zależnościach, przemyślanym kierunku couplingu – AI może wzmocnić zalety mikroserwisów, nie je pogrzebać.
W takim przypadku izolacja jako deployment unit nabiera nowego sensu: je*nie to je*nie. Ale w kontrolowany sposób. Możemy pozwolić AI na więcej eksperymentów, bo wiemy, gdzie ewentualny wybuch sięga. 😉

Tylko że to działa wyłącznie wtedy, gdy te granice są świadomie postawione. AI w źle zaprojektowanym systemie rozproszonym zrobi tyle samo szkód co w źle zaprojektowanym monolicie. Narzędzie wzmacnia istniejące wzorce, nie naprawia ich.

I tu dochodzimy do sedna. Bo jest jedna rzecz, za którą przede wszystkim nam się płaci, a o której często zapominamy w pogoni za nową technologią:

Za wzięcie odpowiedzialności za dostarczone rozwiązania.

Cóż mogę powiedzieć… 10 lat temu taki mądry nie byłem. Ba! 6 lat temu, gdy powstawał pierwszy kurs (Mikroserwisy.NET), zarówno moje, jak i Darka spojrzenie na systemy rozproszone było inne niż dzisiaj.

Dlatego też zamiast odpowiadać na częste pytania czy stary kurs jest jeszcze aktualny odpowiadamy wspólnie: po części tak.

Ale esencje naszych sukcesów i porażek oraz obecne zdanie znajdziecie w nowym wydaniu pt. Mikroserwisy: Revisited. Wierzymy, że jest to najlepszy kurs o mikroserwisach jaki będzie można kupić w 2026 roku.