Monolit nie stał się technologicznym przeżytkiem. Przestaje jednak działać tam, gdzie różne części biznesu rozwijają się w odmiennym tempie. Cennik może zmieniać się co tydzień, księga główna raz na kwartał. Silnik rekomendacji potrzebuje gwałtownie rosnącej mocy obliczeniowej, system kadrowy przede wszystkim stabilności. Zamknięcie tych funkcji w jednym cyklu wdrożeniowym ogranicza firmę. Rozbicie każdej z nich na kilka usług może ograniczyć ją jeszcze bardziej.

Composable enterprise nie jest synonimem mikroserwisów. To sposób organizowania technologii wokół samodzielnych zdolności biznesowych: płatności, wyceny, katalogu produktów, tożsamości klienta czy analityki. Każdy taki obszar powinien mieć jasno określone granice, właściciela, interfejsy oraz koszt utrzymania.

Technologia potrzebna do budowania takich środowisk jest już dojrzała. Według badania CNCF opublikowanego w styczniu 2026 roku 82 proc. użytkowników kontenerów wykorzystuje Kubernetes produkcyjnie. W 59 proc. organizacji duża część lub niemal całość rozwoju i wdrożeń odbywa się już w modelu cloud native. Sama dostępność infrastruktury nie jest więc problemem. Problemem pozostaje jej złożoność.

Koszt architektury rozproszonej

Każdy wydzielony komponent wymaga osobnego wdrażania, monitorowania, zabezpieczania i diagnozowania. Dochodzą alerty, wersjonowanie API, zarządzanie sekretami, testy integracyjne, transmisja danych oraz dyżury operacyjne. Mikroserwis może mieć niewielki kod, a jednocześnie generować duży koszt organizacyjny.

W badaniu State of FinOps 2025 uczestniczyły firmy odpowiadające łącznie za 69 mld dolarów wydatków na chmurę publiczną. Optymalizacja obciążeń i ograniczanie marnotrawstwa pozostały ich najważniejszym priorytetem. Już 63 proc. badanych zespołów zarządzało również kosztami AI, wobec 31 proc. rok wcześniej. Rozproszenie architektury nie jest zatem wyłącznie kwestią techniczną. Coraz częściej podlega takiej samej kontroli ekonomicznej jak zatrudnienie, logistyka czy zakup energii.

Granicą powinien być biznes, nie kod

Wydzielenia wymaga przede wszystkim funkcja, która ma własny rytm rozwoju, profil obciążenia lub poziom ryzyka. Dobrymi kandydatami są systemy płatności, logowania, wyceny w czasie rzeczywistym albo obsługi modeli AI. Mogą być wdrażane niezależnie, skalowane według innych zasad i izolowane w razie awarii.

Granicy usługi nie powinny wyznaczać tabela w bazie, warstwa techniczna ani struktura istniejącego kodu. Punktem odniesienia jest spójny obszar działalności, nazywany w projektowaniu domenowym bounded context. W jego ramach pojęcia, reguły i odpowiedzialność pozostają jednoznaczne. AWS i Microsoft zalecają rozdzielanie systemów według zdolności biznesowych oraz subdomen, a nie arbitralnej liczby funkcji czy modułów.

Autonomia musi być rzeczywista. Usługa współdzieląca bazę danych z kilkoma innymi usługami nie jest niezależna. Podobnie jak komponent, którego wdrożenie wymaga jednoczesnych zmian w trzech zespołach. W takich przypadkach sprzężenie nie znika. Zostaje jedynie przeniesione z kodu do sieci, procesów i struktury organizacyjnej.

Kiedy monolit jest lepszy

Stabilne systemy zaplecza, obsługiwane przez jeden zespół i rzadko modyfikowane, zwykle nie potrzebują rozproszonej architektury. Jeżeli ich funkcje korzystają z tego samego modelu danych, uczestniczą w tych samych transakcjach i są zawsze wdrażane razem, modularny monolit będzie prostszy oraz tańszy.

Microsoft zwraca uwagę, że mikroserwisy upraszczają pojedyncze elementy, lecz komplikują system jako całość. Pojawiają się problemy ze spójnością danych, komunikacją sieciową, testowaniem zależności i obsługą transakcji. Nadmiernie drobne usługi zwiększają złożoność i mogą pogarszać wydajność.

Praktycznym testem jest liczba połączeń przecinających planowaną granicę. Jeżeli nowy komponent musi przy większości operacji pobierać dane z kilku innych usług, granica została wyznaczona błędnie. Zamiast autonomii powstaje system intensywnej komunikacji, podatny na opóźnienia i awarie kaskadowe.

Modernizacja bez wielkiego przepisywania

Wydzielenie komponentu powinno przynosić mierzalny efekt: krótszy czas wdrażania, niezależne skalowanie, mniejszy zasięg awarii, niższy koszt jednostkowy albo skuteczniejszą ochronę danych. Bez takiego uzasadnienia modernizacja pozostaje kosztownym projektem infrastrukturalnym.

Dużych systemów nie należy przepisywać jednorazowo. Wzorzec strangler fig pozwala stopniowo wyprowadzać wybrane funkcje, przekierowywać do nich ruch i przez pewien czas utrzymywać starą oraz nową wersję równolegle. Ogranicza to ryzyko migracji i pozwala wycofać zmianę bez zatrzymywania całej organizacji.

Rosną też wymagania dotyczące odporności. DORA obowiązuje sektor finansowy od 17 stycznia 2025 roku, obejmując zarządzanie ryzykiem ICT, incydentami i dostawcami zewnętrznymi. W pierwszym unijnym zestawieniu opublikowanym w czerwcu 2026 roku odnotowano 3383 poważne incydenty ICT. Około jedna trzecia miała charakter transgraniczny, a głównymi przyczynami były awarie systemów i zdarzenia zewnętrzne. Każda dodatkowa zależność architektoniczna staje się więc również zależnością operacyjną i regulacyjną.

Architektura powinna odzwierciedlać zmienność biznesu. Funkcje o odmiennym rytmie, ryzyku i ekonomice należy izolować. To, co stabilne, transakcyjne i silnie współzależne, należy konsolidować. Jeżeli dwa moduły nie mogą być wdrażane, skalowane i rozliczane niezależnie, nazwanie ich mikroserwisami nie zmienia faktu, że tworzą monolit rozproszony.