Od mainframe do mikroserwisów: ewolucja architektury systemów informatycznych

Scenka otwarcia: od dziwnego „okienka” na terminalu do chmury

Młody programista wchodzi do serwerowni dużego banku. Na jednym z monitorów widzi zielony ekran terminala, który wygląda jak z muzeum techniki, a starszy administrator mówi półżartem: „Tego mainframe’a boi się ruszyć cała firma, bo na nim stoi połowa kraju”. Kilka pięter wyżej ten sam bank rozwija już aplikacje w chmurze, w Kubernetesie, wdrażane kilkanaście razy dziennie.

Te dwa światy – hermetyczny, niemal nietykalny mainframe i dynamiczne środowisko mikroserwisów w chmurze – współistnieją w wielu organizacjach. Konflikt nie dotyczy tylko technologii, ale przede wszystkim oczekiwań biznesu: kiedyś liczyła się stabilność i przewidywalność, dziś liczy się szybkość zmian i elastyczność. Ewolucja architektury systemów informatycznych od mainframe do mikroserwisów jest odpowiedzią na rosnącą złożoność, presję rynku i konieczność szybkiej adaptacji.

Historia tej ewolucji pokazuje, że nie chodzi o „modne buzzwordy”, ale o bardzo konkretne kompromisy: między centralizacją a rozproszeniem, między kontrolą a autonomią zespołów, między jedną wielką aplikacją a setkami małych usług. Zrozumienie tej drogi ułatwia dzisiaj podejmowanie świadomych decyzji architektonicznych, zamiast ślepego kopiowania popularnych wzorców.

Skąd to się wzięło: narodziny mainframe’ów i centralizacji

Mainframe jako „mózg” organizacji

Architektura mainframe’ów powstała w czasach, gdy komputery były dobrem luksusowym, a dostęp do mocy obliczeniowej – ściśle reglamentowany. Symbolem tej epoki był m.in. IBM System/360: wielkie szafy w specjalnym pomieszczeniu, klimatyzacja, redundantne zasilanie i zespół administratorów w białych kitlach. Wokół jednego „mózgu” organizacji skupiały się kluczowe procesy: księgowość, rozliczenia, listy płac, rozrachunki międzybankowe.

Dostęp do mainframe’a odbywał się przez proste terminale znakowe. Terminal nie wykonywał żadnych obliczeń – był tylko okienkiem na zdalny system, który przetwarzał wszystkie dane centralnie. Użytkownik wpisywał komendę, mainframe przydzielał jej fragment swojego czasu procesora (model timesharing), wykonywał zadanie i odsyłał wynik. Jeden komputer, wielu użytkowników, ściśle kontrolowany harmonogram.

Kluczowe cechy architektury mainframe’owej to:

• centralizacja mocy obliczeniowej – wszystkie ważne procesy wykonywały się w jednym, kontrolowanym środowisku;
• wysoka niezawodność – sprzęt i systemy były projektowane tak, by działały latami bez poważnych awarii; redundancja była standardem;
• silne bezpieczeństwo – dostęp do systemu, danych i operacji był ściśle kontrolowany, a fizyczna separacja sprzętu zwiększała ochronę;
• bardzo wysokie koszty – zarówno sprzętu, jak i licencji oraz specjalistycznego personelu.

Dla dużych instytucji – banków, ubezpieczycieli, administracji – architektura mainframe była idealnym dopasowaniem do ówczesnych potrzeb: masowego, przewidywalnego przetwarzania danych. Zmieniało się niewiele, ale musiało działać absolutnie niezawodnie.

Jak wyglądało programowanie i utrzymanie mainframe’ów

Programowanie systemów mainframe’owych miało swój specyficzny charakter. Dominowały języki takie jak COBOL (do systemów biznesowych, operacji na rekordach, przetwarzania wsadowego) czy PL/I. Wiele operacji wykonywano jako batch processing – zadania uruchamiane cyklicznie, np. nocne przetwarzanie transakcji, naliczanie odsetek, generowanie raportów.

Cykl wytwarzania oprogramowania był długi i sformalizowany. Zespoły były podzielone na role: analitycy, programiści, operatorzy, administratorzy systemu, testerzy, osoby odpowiedzialne za wdrożenia. Zmiany przechodziły przez wielostopniowe procedury: specyfikacja, implementacja, testy na środowisku testowym, okna wdrożeniowe, częste restrykcje co do godzin wprowadzania zmian. Najmniejsza poprawka mogła oczekiwać tygodniami.

Ten model miał swoje plusy:

• ścisła kontrola jakości i bezpieczeństwa – nic nie trafiało na produkcję bez formalnej akceptacji;
• stabilność środowiska – zmiany były rzadkie, więc system można było dobrze poznać i przewidzieć jego zachowanie;
• łatwa centralna administracja – jedno środowisko, jeden zestaw narzędzi, jeden zespół odpowiedzialny za całość.

Miało to jednak też konsekwencje negatywne z perspektywy dzisiejszych wymagań:

• mała elastyczność – dodanie nowej funkcji było procesem żmudnym i kosztownym;
• uzależnienie od jednego punktu – jeśli mainframe miał poważny problem, cała organizacja odczuwała skutki;
• trudna adaptacja do zmian biznesowych – szybko zmieniające się wymagania rynku były trudne do realizacji w takim modelu.

Mainframe a zwinność biznesu – pierwszy konflikt

W czasach, gdy regulacje zmieniały się rzadko, a konkurencja była ograniczona, taki model wystarczał. Biznes projektował procesy na lata, a systemy informatyczne miały je wiernie odzwierciedlać i wykonywać bezbłędnie. Moment przełomu przyszedł, gdy otworzył się rynek, pojawiły się nowe produkty, wymagania klientów zaczęły szybciej ewoluować, a czas reakcji stał się krytyczny.

Architektura mainframe z natury utrudniała szybkie eksperymentowanie: centralizacja, wysokie ryzyko zmian, brak izolacji poszczególnych funkcji, długi cykl wdrożeniowy. To, co było zaletą – ścisła kontrola i stabilność – zaczęło przeszkadzać w budowaniu przewagi konkurencyjnej.

Wniosek z tej epoki jest prosty: mainframe rozwiązywał problemy swojego czasu kosztem zwinności. Tam, gdzie priorytetem była masowa, przewidywalna obsługa transakcji i najwyższa niezawodność, centralizacja wygrywała. Gdy priorytetem stała się szybkość zmian, pojawiła się potrzeba innej architektury.

Lata 70., 80. i 90.: od terminali do klient–serwer

Personal computers zmieniają układ sił

Pojawienie się tanich komputerów osobistych w latach 70. i 80. całkowicie zmieniło krajobraz IT. Komputer przestał być wyłącznie „wielką maszyną” w piwnicy – trafił na biurka użytkowników. Działy zaczęły instalować oprogramowanie lokalnie, tworzyć własne arkusze kalkulacyjne, małe bazy danych, a nawet dedykowane aplikacje pisane na PC.

Dla biznesu była to rewolucja: nagle można było zbudować mały system dla konkretnego działu bez angażowania zespołu mainframe. Sprzedaż, marketing, logistyka – każdy chciał mieć narzędzie dopasowane do swoich potrzeb. To przyniosło korzyści:

• większą niezależność działów – brak konieczności czekania na kolejkę zmian na centralnym systemie;
• krótszy czas wdrożenia – mniejsze aplikacje mogły powstać szybko na lokalnym sprzęcie;
• niższy koszt jednostkowy – PC były tańsze niż zasoby mainframe’a.

Wraz z tym pojawiły się oczywiste problemy: integracja danych, różne wersje prawdy o kliencie, brak spójnych standardów, ryzyko utraty danych przechowywanych „w szafce” danego działu. Organizacje zaczęły szukać kompromisu między pełną centralizacją a totalnym rozproszeniem.

Architektura klient–serwer jako most między światem starego i nowego

Odpowiedzią stała się architektura klient–serwer. Zamiast jednego mainframe’a i „głupich” terminali pojawił się model, w którym część funkcji wykonywano po stronie użytkownika (klient), a część po stronie centralnego serwera. Najbardziej klasyczną konfiguracją były:

• serwer bazy danych – centralne repozytorium danych firmowych (Oracle, SQL Server, DB2, Sybase);
• gruby klient – aplikacja desktopowa instalowana na komputerze użytkownika, zawierająca logikę biznesową, interfejs użytkownika i komunikację z bazą.

Taki model zapewniał centralizację danych (co ważne z perspektywy spójności i bezpieczeństwa), a jednocześnie wykorzystywał moc obliczeniową stacji roboczych. Logika biznesowa mogła częściej zmieniać się niezależnie od bazy danych, a aplikacje klienta można było dostosowywać do potrzeb konkretnych grup użytkowników.

Architektura klient–serwer wprowadziła jednak nowe wyzwania:

• aktualizacje oprogramowania – każda nowa wersja aplikacji musiała być zainstalowana na wielu stacjach użytkowników;
• skalowalność serwera – rosnąca liczba klientów obciążała serwer bazy danych; wymagało to skalowania pionowego (mocniejszy sprzęt);
• utrzymanie spójności logiki biznesowej – jeśli logika znajdowała się po stronie klienta, różne wersje aplikacji mogły zachowywać się inaczej.

Klient–serwer jako etap przejściowy

Z perspektywy historii klient–serwer był wyraźnym krokiem w stronę rozproszenia architektury, ale nie był rozwiązaniem idealnym. Z jednej strony zdejmował część obciążenia z centralnego systemu i pozwalał budować nowoczesne interfejsy użytkownika. Z drugiej – wprowadzał sporo chaosu w zarządzaniu wersjami, utrzymaniu, bezpieczeństwie i skalowalności.

Ten model dobrze pasował do okresu, w którym sieci lokalne (LAN) i infrastruktura serwerowa dopiero się rozwijały, a Internet nie był jeszcze powszechnym środkiem dostępu. Gdy pojawiła się możliwość budowania aplikacji dostępnych z poziomu przeglądarki WWW, naturalną konsekwencją było poszukiwanie architektury, która uprości dystrybucję oprogramowania i ujednolici interfejs.

Można powiedzieć, że klient–serwer dał organizacjom smak decentralizacji i autonomii, ale też pokazał, jak trudne jest zarządzanie rozproszonymi klientami i skalowanie serwerów, jeśli logika rozbita jest między wiele warstw bez wyraźnych granic odpowiedzialności.

Rewolucja WWW i pierwsze systemy rozproszone

Web jako cienki klient

Pojawienie się przeglądarek WWW i serwerów HTTP otworzyło nowy rozdział. Zamiast instalować aplikacje na każdym komputerze, wystarczyło udostępnić je jako aplikacje webowe. Użytkownik potrzebował tylko przeglądarki i dostępu do sieci. Z perspektywy architektury systemów był to powrót do idei „cienkiego klienta”: logika i dane mieszkają na serwerze, klient głównie wyświetla i przesyła dane.

Naturalnym wzorcem stała się trójwarstwowa architektura:

• warstwa prezentacji (frontend) – HTML, CSS, JavaScript w przeglądarce użytkownika;
• warstwa logiki biznesowej – serwer aplikacji (np. Java EE, .NET, PHP, Python);
• warstwa danych – relacyjna baza danych lub inne repozytorium.

Taki układ dawał kilka silnych korzyści:

• łatwa dystrybucja – aktualizacje po stronie serwera, użytkownik zawsze widzi najnowszą wersję;
• centralne bezpieczeństwo – główne mechanizmy kontroli dostępu i walidacji po stronie serwera;
• możliwość skalowania poziomego – dokładanie kolejnych serwerów aplikacyjnych za load balancerem.

Monolit webowy – wygoda i ograniczenia

Najprostszym sposobem budowania systemów webowych była jedna, duża aplikacja serwerowa obsługująca wszystkie funkcje biznesowe – monolit webowy. Cała logika biznesowa, API, moduły wewnętrzne i interfejsy administracyjne znajdowały się w jednym projekcie kodu, wdrażanym jako jeden artefakt (np. plik WAR, EAR, duża aplikacja .NET, framework PHP).

Z perspektywy startu projektu monolit ma wiele zalet:

• prosty deployment – jedna aplikacja, jedno środowisko, jeden proces wdrożenia;
• łatwiejsza komunikacja wewnętrzna – wywołania funkcji i metod, brak złożonych protokołów między modułami;
• niższa bariera wejścia – zespół nie musi od razu projektować skomplikowanej architektury rozproszonej.

Problemy pojawiały się wraz ze wzrostem skali:

• sprzężenie modułów – zmiana w jednym obszarze mogła nieoczekiwanie zepsuć inny; trudne testowanie całości;
• długi cykl wdrożeniowy – nawet mała zmiana wymagała pełnego wdrożenia dużego artefaktu;
• ograniczenia skalowalności – trzeba skalować całą aplikację, nawet jeśli tylko jeden moduł jest obciążony (np. raportowanie);
• wyzwania organizacyjne – wiele zespołów dotyka tego samego repozytorium, rosną konflikty, złożoność integracji gałęzi.

W praktyce wiele monolitów webowych stawało się „nowymi mainframe’ami”: centralnymi systemami, od których zależały kluczowe procesy, trudno modyfikowalnymi, bo każda zmiana wiązała się z ryzykiem nieprzewidzianych skutków ubocznych.

Od pierwszych API do integracyjnego spaghetti

W pewnym momencie każdy większy monolit stawał przed tym samym problemem: jak udostępnić dane i funkcje innym systemom, nie otwierając wszystkich wewnętrznych bebechów. Zespoły integrowały się „tymczasowo”: jedno dodatkowe API, jedno połączenie z bazą, jedna kolejka. Po kilku latach „tymczasowe” stawało się nową stałą – siecią nieoczywistych zależności.

Na początku integracja była prosta: inny system wywoływał procedury składowane w bazie, czytał dane z widoków, ewentualnie odpalał skrypt batchowy. To działało, ale miało ciemną stronę:

• logika biznesowa przeciekała do zapytań SQL i integracji, co utrudniało zmiany struktury danych;
• każdy nowy konsument danych „przyklejał się” bezpośrednio do bazy, zwiększając sprzężenie;
• brakowało jasnych kontraktów – zmiana schematu potrafiła złamać kilka nieudokumentowanych integracji naraz.

W kolejnej fazie pojawiły się pierwsze API oparte o HTTP i SOAP. Zamiast bezpośredniego dostępu do bazy, inne systemy miały wołać zdefiniowane operacje. Teoretycznie to krok w kierunku usług: mamy kontrakty, opisy WSDL, zewnętrzni klienci otrzymują stabilny interfejs. W praktyce wiele takich API było tylko „zdalnym frontem” do monolitu – bez jasnych granic domenowych, z dużą ilością logiki osadzonej głęboko w wewnętrznej warstwie aplikacji.

W efekcie organizacje miały więcej protokołów i technologii integracyjnych niż jasnych zasad ich użycia. Pojawiło się integracyjne spaghetti: mieszanka bezpośrednich połączeń do baz, API SOAP, kolejek MQ i plików wymienianych po FTP. Tam, gdzie każdy projekt integrował się „jak wygodnie”, po kilku latach powstawał system tak mocno splątany, że szersza zmiana architektoniczna wymagała niemal chirurgicznej precyzji.

Enterprise Application Integration – próba ujarzmienia chaosu

Gdy integracje wymknęły się spod kontroli, w wielu firmach pojawił się ten sam dylemat: „czy jest sposób, żeby to wszystko poukładać w jednym miejscu?”. Odpowiedzią stał się nurt Enterprise Application Integration (EAI) i dedykowane platformy integracyjne (ESB, brokery komunikatów, szyny danych).

Idea była kusząca: zamiast każdy z każdym, systemy miały mówić z jednym centralnym „mózgiem integracyjnym”. Ten mózg:

• tłumaczył formaty danych (np. z własnych XML na wspólny model kanoniczny);
• zarządzał trasowaniem wiadomości między systemami;
• pozwalał w jednym miejscu monitorować przepływy i błędy;
• narzucał standardy integracji dla całej organizacji.

Na papierze brzmiało to jak idealny środek na integracyjny bałagan. W wielu miejscach EAI rzeczywiście pomogło – szczególnie tam, gdzie dziesiątki aplikacji musiały wymieniać dane w powtarzalny sposób (np. integracje ERP, CRM, systemów magazynowych). Jednocześnie pojawił się nowy typ centralizacji: szyna integracyjna stawała się kolejnym „super-systemem”, do którego wszyscy byli podłączeni.

Konsekwencje tej centralizacji były odczuwalne w codziennej pracy zespołów:

• zespół integracyjny stawał się wąskim gardłem – każda zmiana przepływu wymagała ich zaangażowania;
• logika biznesowa zaczynała migrować do warstwy integracji (mapowania, reguły routingu), zamiast pozostać w systemach źródłowych;
• testowanie całości przypominało testowanie monolitu – zmiana w jednym przepływie mogła wpłynąć na kilka innych.

Model EAI był ważnym etapem: pokazał, jak krytyczna jest standaryzacja integracji i jak brak jasnych granic prowadzi do chaosu. Jednocześnie uświadomił, że kolejna centralna „szyna” nie rozwiąże problemu samą technologią – potrzebna jest zmiana w sposobie myślenia o samej strukturze systemu.

SOA – pierwszy poważny krok w stronę usług

Scenka z sali konferencyjnej

Na spotkaniu architektonicznym ktoś rysuje na tablicy prostokąty: „Usługa Klienta”, „Usługa Płatności”, „Usługa Zamówień”. Ktoś inny dopisuje: „re-używalne”, „niezależne”, „udostępniane na zewnątrz”. Po kilku minutach cała ściana pokryta jest „usługami”, a hasło Service-Oriented Architecture staje się nowym kierunkiem strategii IT.

Service-Oriented Architecture (SOA) miała być odpowiedzią na rosnący ciężar monolitów i integracyjnego spaghetti. Zamiast jednego wielkiego systemu i dziesiątek przypadkowych integracji, wizją była kolekcja usług biznesowych, które:

• mają dobrze zdefiniowane kontrakty (najczęściej oparte na SOAP/WSDL);
• są zorganizowane wokół procesów i pojęć biznesowych (np. klient, zamówienie, płatność);
• są możliwie niezależne, tak aby różne aplikacje mogły je wywoływać bez znajomości wewnętrznej implementacji.

Kluczowy przesunięcie polegało na tym, że usługa miała być jednostką biznesową, a nie tylko techniczną. To nie był kolejny moduł techniczny, ale „kawałek biznesu” opakowany w interfejs sieciowy. Za usługą miały stać konkretne reguły, odpowiedzialny zespół i cykl życia.

Usługa vs. moduł – zmiana w sposobie myślenia

W wielu organizacjach istniały już wcześniej moduły i komponenty. SOA poszła krok dalej, kładąc nacisk na to, że:

• usługa ma kontrakt (co robi) odseparowany od implementacji (jak to robi);
• usługa jest komponowalna – procesy biznesowe składają się z wywołań usług, a nie z bezpośredniego kodu pomiędzy modułami;
• usługa ma jasno określone granice odpowiedzialności, zwykle powiązane z obszarem biznesowym.

To otwierało drogę do budowania bardziej elastycznych procesów biznesowych. Zamiast kodować cały proces w jednym systemie, można było użyć orchestratora procesów (np. BPEL), który łączył usługi w sekwencje kroków. Przykładowa ścieżka „złóż zamówienie” stawała się przepływem korzystającym z usług: walidacji klienta, rezerwacji towaru, naliczenia rabatu, uruchomienia płatności.

Mini-wniosek z tego etapu: SOA wprowadziła myślenie procesem i usługą jako podstawowym klockiem, ale sama idea nie gwarantowała jeszcze elastyczności. Kluczowe było to, jak drobno dzielono te usługi i gdzie faktycznie lądowała logika biznesowa.

SOA na papierze vs. SOA w praktyce

W materiałach marketingowych SOA wyglądała idealnie: katalog usług, rejestry, orkiestracja, standaryzacja. W rzeczywistych projektach często okazywało się, że „usługa” to wciąż ten sam monolit, tylko wystawiony przez kilka interfejsów SOAP. Spotykały się dwa skrajne podejścia:

• zbyt grube usługi – pojedyncza usługa odpowiadała za bardzo szeroki zakres logiki („Usługa Systemu Zamówień”), stając się w praktyce bramą do monolitu;
• zbyt drobne usługi – hiper-techniczne operacje („Dodaj linię zamówienia”, „Usuń linię zamówienia”), które trudno było utrzymać w sensownym katalogu, a ich składanie w procesy stawało się koszmarem.

Do tego dochodziły aspekty infrastrukturalne. Aby „prawdziwe” SOA działało, wprowadzano:

• rejestry usług (UDDI), które rzadko były utrzymywane na bieżąco;
• centralne szyny usług (ESB), przez które miało przechodzić całe ruch sieciowy;
• rozbudowane polityki bezpieczeństwa, wersjonowania i zarządzania cyklem życia usług.

Często kończyło się tym, że SOA stawała się ciężkim, centralnie zarządzanym programem transformacji. Zespoły miały mniejszą swobodę, bo każda nowa usługa musiała zostać zarejestrowana, opisana, zaakceptowana. Dla organizacji przyzwyczajonych do szybkiej partyzanckiej budowy rozwiązań był to gwałtowny zwrot w stronę formalizmu.

Rola ESB – pomocnik czy nowy monolit?

Wiele wdrożeń SOA opierało się na koncepcji Enterprise Service Bus (ESB). Była to platforma, która miała:

• pośredniczyć w komunikacji między usługami;
• realizować transformacje danych, routing, bezpieczeństwo, logowanie;
• ułatwiać podłączanie nowych systemów bez konieczności znania wszystkich innych uczestników.

Gdy ESB trzymał się roli „inteligentnego routera”, przynosił dużo korzyści – szczególnie przy integracji starszych systemów, które nie mówiły „nowoczesnymi protokołami”. Problem pojawiał się, gdy na szynę przenoszono realną logikę biznesową. Mapowania, reguły decyzyjne, walidacje – wszystko to trafiało do przepływów na ESB. Z czasem trudno było odpowiedzieć na proste pytanie: gdzie właściwie jest ten proces?

W praktyce wiele ESB stało się nową wersją mainframe’a: centralnym punktem, którego awaria paraliżowała całą organizację. Zmiana drobnej reguły wymagała przejścia przez złożony proces release’owy, a zespół ESB stawał się strażnikiem ruchu sieciowego całej firmy. Zamiast luźno powiązanych usług powstał jeden wielki „lejek” integracyjny.

Ten etap był jednak bardzo pouczający. Pokazał, że:

• nie wystarczy wydzielić kontrakty – trzeba też dobrze określić granice domenowe i miejsce logiki biznesowej;
• centralizacja integracji pomaga, dopóki nie zamienia się w centralizację decyzyjną i implementacyjną;
• sam standard (SOAP, WSDL, BPEL) nie rozwiązuje problemów organizacyjnych.

SOA a organizacja pracy zespołów

SOA nie dotyczyła tylko techniki – wymuszała też korektę organizacji. Pojawiały się dedykowane centra kompetencji SOA, katalogi usług, rady architektoniczne. Celem było spójne podejście do projektowania usług i unikanie duplikatów. Równolegle zespoły produktowe chciały szybko dowozić funkcjonalności, często wchodząc w konflikt z procedurami SOA.

Typowy scenariusz wyglądał tak: zespół produktu potrzebuje nowej operacji („sprawdź dostępność towaru w magazynie z uwzględnieniem rezerwacji”), ale w katalogu istnieje już usługa „Sprawdź dostępność towaru”. Architekci SOA proponują rozbudowę istniejącej usługi, aby uniknąć duplikacji. Zespół produktowy potrzebuje rozwiązania „na wczoraj” i proponuje własną usługę, prostszą, ale specyficzną dla ich kontekstu. Konflikt interesów jest nieunikniony.

Z perspektywy czasu widać, że SOA była ważnym, ale często zbyt ciężkim krokiem. Dawała język i koncepcje usług, procesów, szyn, ale w wielu organizacjach zabrakło połączenia tego modelu z codzienną praktyką zwinnego wytwarzania oprogramowania. Gdy w kolejnych latach pojawiły się podejścia inspirowane DevOps i „you build it, you run it”, naturalnym pytaniem stało się: czy da się połączyć ideę usług z większą autonomią zespołów i lżejszą infrastrukturą?

Od SOA do myślenia domenowego

Jednym z najbardziej wartościowych elementów, które SOA pozostawiła, było zwrócenie uwagi na granice domenowe. Tam, gdzie usługi były projektowane wokół realnych obszarów biznesu (np. rozliczenia, logistyka, sprzedaż), łatwiej było rozmawiać zarówno z IT, jak i z biznesem. Gdzie usługi odpowiadały bardziej modułom technicznym („Warstwa integracji SAP”, „Adapter CRM”), zyski były znacznie mniejsze.

To doświadczenie zaczęło łączyć się z rosnącą popularnością Domain-Driven Design (DDD). Koncepcje takie jak bounded context pasowały do intuicji, że usługi powinny odpowiadać wydzielonym obszarom odpowiedzialności. Zamiast „jednego modelu danych dla całej firmy” pojawiła się akceptacja, że różne obszary mogą mieć własne modele, a integracja powinna odbywać się po jasno zdefiniowanych granicach.

Wiele projektów, które oficjalnie nazywały się „SOA”, w praktyce zaczęło przesuwać się w stronę drobniejszych, bardziej niezależnych komponentów. Początkowo różniły się one głównie słownictwem i technologiami (mniej SOAP, więcej REST, JSON), ale główny kierunek był podobny: mniejsze, wydzielone jednostki, z własnym cyklem życia i odpowiedzialnym zespołem. Dopiero połączenie tych idei z postępem w wirtualizacji, konteneryzacji i chmurze obliczeniowej otworzyło drogę do kolejnego etapu ewolucji architektury.

Mikroserwisy: usługi, które „odkleiły się” od centralnego systemu

W pewnym momencie w wielu firmach pojawił się podobny dialog. Architekt mówi: „Musimy wystawić nową usługę”, a zespół devopsowy odpowiada: „Łatwiej będzie nam postawić osobną aplikację w kontenerze i puścić ją bokiem, niż przepychać się przez katalog SOA i ESB”. Technologia dojrzała na tyle, że takie „boczne ścieżki” przestały być eksperymentem, a zaczęły tworzyć nowy standard.

Mikroserwisy były naturalnym krokiem po doświadczeniach z SOA i DDD. Nie chodziło już tylko o usługi jako koncepcję architektoniczną, lecz o realną samodzielność komponentów: własne wdrożenie, własne dane, własny zespół odpowiedzialny od kodu po produkcję.

Co faktycznie odróżnia mikroserwis od „małej usługi SOA”

Na prezentacjach często wygląda to podobnie: prostokąty połączone strzałkami. Różnica wychodzi przy konkretnych decyzjach: kto może zmienić usługę, jak jest wdrażana, czy dzieli bazę danych z innymi, jak radzi sobie z awarią sąsiada.

W dojrzałym podejściu mikroserwisowym typowy serwis:

• jest w pełni autonomiczną aplikacją – ma własny cykl release’owy i nie czeka na globalne okna wdrożeniowe;
• posiada własne dane (oddzielną bazę albo przynajmniej osobne schematy), a z innymi komunikuje się przez API lub zdarzenia, a nie przez wspólne tabele;
• jest projektowany wokół konkretnego kontekstu biznesowego, często jednego bounded context z DDD;
• ma zespół „you build it, you run it”, który odpowiada i za funkcjonalność, i za utrzymanie.

Mini-wniosek: mikroserwisy nie są tylko drobnymi usługami – są sposobem organizacji odpowiedzialności i niezależności, zarówno w kodzie, jak i w strukturze zespołów.

Chmura, kontenery i ciągłe wdrożenia – brakujące klocki

W jednym z projektów migracyjnych dopiero wprowadzenie kontenerów sprawiło, że rozmowa „wydzielmy to do osobnej aplikacji” przestała kończyć się pytaniem: „a kto będzie administrował tym nowym serwerem?”. Mikroserwis bez lekkiej infrastruktury jest po prostu dodatkową maszyną do utrzymania.

Zmianę umożliwiło kilka równoległych trendów:

• wirtualizacja i chmura – odchodzenie od „serwerów na lata” na rzecz infrastruktury jako kodu i środowisk, które można szybko tworzyć i niszczyć;
• kontenery (Docker i orkiestratory typu Kubernetes) – spójne pakowanie aplikacji z zależnościami, bez konieczności ręcznego dogadywania się z administratorami o wersje bibliotek i JDK;
• CI/CD – automatyzacja procesu od commita do wdrożenia, co uczyniło częste releasy realną praktyką, a nie wyłącznie sloganem na slajdach;
• obserwowalność – logowanie skorelowane ze śledzeniem żądań, metrykami i alertami, dzięki którym rozproszony system jest diagnozowalny.

Dopiero połączenie tych elementów sprawiło, że dziesiątki czy setki niezależnych, małych serwisów dało się utrzymać bez ręcznego „gaszenia pożarów” przy każdym wdrożeniu.

Granice mikroserwisu: od „jedna funkcja” do „jedna domena”

W niejednej firmie pierwsza fala mikroserwisów wyglądała jak przesadna reakcja na monolit. Monolit był „za duży”? To zbudujmy setki maleńkich usług, z których każda robi jedną małą operację. Bardzo szybko okazywało się, że komunikacja między nimi generuje więcej problemów niż sam monolit.

Praktyka pokazała, że sensowna granica mikroserwisu powstaje tam, gdzie:

• istnieje wyraźny model pojęciowy (np. rozliczenia, katalog produktów, dostępność magazynowa);
• potrzebna jest odrębna ewolucja – inny rytm zmian, inne wymagania niefunkcjonalne;
• można jasno przypisać odpowiedzialny zespół, który nie musi sięgać do cudzej bazy danych, żeby zrealizować swoje zadanie;
• interfejs da się opisać stabilnym kontraktem, a częste są zmiany wewnątrz, nie na granicy.

Granica mikroserwisu jest więc kompromisem: za mała – rozmnaża integrację, za duża – wracamy do monolitu w przebraniu.

Monolit, mikroserwisy i coś pomiędzy

Ciekawy obrazek: firma ma duży, starzejący się monolit i kilka mikroserwisów, które powstały „na boku” dla nowych inicjatyw. Po dwóch latach to „coś pomiędzy” jest bardziej skomplikowane niż pierwotny monolit. Historia powtarza się dość często.

Naturalną odpowiedzią stały się pojęcia modułowego monolitu i makroserwisów:

• modułowy monolit – jedna aplikacja, ale mocno rozbita wewnętrznie na moduły z jasno pilnowanymi granicami (np. osobne pakiety, osobne warstwy persystencji, brak dostępu „na skróty” między modułami);
• makroserwisy – serwisy większe niż typowe „mikro”, reprezentujące cały obszar biznesowy (np. „zamówienia”), ale nadal niezależnie wdrażane i utrzymywane.

Te podejścia pokazują, że celem jest odpowiednia separacja odpowiedzialności, a nie magiczna liczba serwisów. Mikroserwisy są narzędziem; bez myślenia domenowego i dyscypliny projektowej łatwo zamienić je w rozproszony chaos.

Komunikacja synchroniczna i asynchroniczna – cichy zwrot ku zdarzeniom

Podczas jednego z przestojów w systemie sprzedaży śledzenie logów ujawniło „łańcuszek wywołań” długości kilkunastu skoków sieciowych. Awaria małego serwisu pomocniczego zatrzymała sprzedaż w całym kraju. Formalnie system był „rozproszony”, ale z punktu widzenia niezawodności przypominał monolit – tylko z większą liczbą punktów awarii.

To doświadczenie popchnęło wiele zespołów w stronę komunikacji asynchronicznej i architektur opartych na zdarzeniach. Zamiast kaskady wywołań REST typu „A woła B, B woła C, C woła D”, coraz częściej stosuje się:

• publikację zdarzeń domenowych (np. „ZamówienieZłożone”, „PłatnośćZaksięgowana”) na wspólnym brokerze komunikatów;
• subskrypcję interesujących zdarzeń przez inne serwisy, które reagują we własnym tempie;
• wzorce kompensacji zamiast globalnych transakcji – jeśli któryś krok zawiedzie, wysyłane są zdarzenia odwracające efekt poprzednich działań.

Takie podejście redukuje twarde zależności czasowe między serwisami. Ceną jest większa trudność w śledzeniu całości procesu i w zrozumieniu „kto na co reaguje”, ale w zamian system lepiej znosi przeciążenia i częściowe awarie.

Nowy problem: spójność danych i model „single source of truth”

Monolit miał jedną bazę danych i jedną prawdę o świecie. Mikroserwisy wprowadzają wiele lokalnych prawd, które muszą być w miarę spójne, ale niekoniecznie natychmiast. W praktyce oznacza to decyzję: w których miejscach akceptujemy spójność ostateczną, a gdzie wymagana jest silna spójność kosztem zwinności.

W realnych systemach stosuje się kilka typowych rozwiązań:

• wydzielone źródła prawdy – np. serwis płatności jest jedynym miejscem, które wie, czy płatność jest „na pewno zaksięgowana”, inni serwis korzystają z jego zdarzeń i API jako referencji;
• lokalne cache i projekcje danych – czytelne kopie danych w innych serwisach, aktualizowane zdarzeniami, wykorzystywane do szybkich odczytów;
• odroczona walidacja – najpierw przyjmujemy zdarzenie, że coś zaszło (np. rezerwacja), a dopiero w kolejnym kroku weryfikujemy szczegóły i ewentualnie publikujemy zdarzenie kompensujące.

Każda z tych technik wymaga świadomego projektowania modelu danych i procesów, inaczej system szybko staje się zbiorem sprzecznych informacji, które trudno pogodzić.

Microservices meets DevOps: odpowiedzialność nie tylko za kod

Na jednym z retro zespół stwierdził: „Od kiedy przeszliśmy na mikroserwisy, przestaliśmy czekać tygodniami na wdrożenia, ale za to spędzamy wieczory na analizie metryk i alarmów”. To kwintesencja połączenia architektury usługowej z kulturą DevOps.

Mikroserwisy wymuszają, aby zespół:

• znał nie tylko kod, ale i zachowanie na produkcji – metryki, logi, zdarzenia;
• projektował serwis z myślą o obserwowalności – sensowne logowanie, korelacja requestów, meaningful alerty zamiast „CPU > 80%”;
• miał wpływ na infrastrukturę – definicje deploymentów, autoskalowanie, limity zasobów;
• rozumiał koszt zewnętrznych zależności – każdy call do innego serwisu lub zewnętrznego API to potencjalny punkt awarii.

Mini-wniosek: przejście na mikroserwisy bez zmiany sposobu pracy zespołów kończy się tylko większą liczbą ruchomych części, ale nie zwiększa realnej elastyczności.

Refaktoryzacja monolitu: „big bang” kontra stopniowa ewolucja

Wiele organizacji stanęło przed zadaniem: „mamy krytyczny monolit, jak go rozbić?”. Pokusa „przepiszmy wszystko od zera w mikroserwisach” pojawia się często, ale rzadko kończy sukcesem. Systemy o dużej złożoności biznesowej nie dają się łatwo odtworzyć na czystej kartce.

Bardziej realistyczna okazuje się stopniowa ekstrakcja:

• identyfikacja obszarów o względnie jasnych granicach (np. moduł faktur, zarządzanie produktami);
• wydzielanie ich najpierw jako modułów wewnątrz monolitu z dobrze pilnowanymi granicami;
• następnie wypychanie ich na zewnątrz jako osobne serwisy, przy użyciu wzorców typu strangler fig – nowy serwis przejmuje ruch krok po kroku;
• pozostawienie części monolitu tam, gdzie nie ma biznesowego uzasadnienia dla rozbijania (np. stabilne, rzadko zmieniane moduły raportowe).

Taka ewolucja jest mniej spektakularna niż ogłoszenie „nowej platformy”, ale lepiej wspiera ciągłość biznesu i redukuje ryzyko.

Architektura ewoluuje razem z organizacją

W pewnej firmie dopiero zmiana sposobu zarządzania produktami – przejście z silosów działowych na cross-funkcjonalne zespoły produktowe – sprawiła, że droga do mikroserwisów naprawdę się otworzyła. Wcześniej każdy zespół miał fragment logiki rozsmarowany po różnych częściach monolitu, co blokowało realną autonomię.

Architektura i struktura organizacji są ze sobą silnie sprzężone:

• tam, gdzie zespoły są zorientowane produktowo, łatwiej o serwisy odpowiadające konkretnym domenom biznesowym;
• tam, gdzie dominują centra kompetencyjne (np. osobno „baza danych”, „frontend”, „integracja”), serwisy mają tendencję do odzwierciedlania warstw technicznych, a nie logiki domenowej;
• zmiana architektury bez zmiany struktury współpracy powoduje, że nowe wzorce są implementowane starymi nawykami – mikroserwis staje się po prostu kolejną techniczną nakładką na stare procesy.

Doświadczenie wielu organizacji pokazuje, że ewolucja od mainframe’ów, przez klient–serwer i SOA, aż po mikroserwisy jest równie mocno historią o technologii, jak o sposobie, w jaki ludzie pracują i współdecydują o systemach, które budują.

Najczęściej zadawane pytania (FAQ)

Co to jest mainframe i po co w ogóle był używany?

Administrator wchodzi do serwerowni, patrzy na wielką szafę IBM i mówi: „Jak to wyłączymy, nie działa połowa firmy”. To właśnie codzienność systemów mainframe – jednego, centralnego „mózgu” organizacji.

Mainframe to duży, bardzo wydajny i niezawodny komputer zaprojektowany do masowego przetwarzania danych. Obsługiwał kluczowe procesy firm: księgowość, listy płac, rozliczenia bankowe, rozrachunki międzybankowe. Użytkownicy łączyli się z nim przez proste terminale tekstowe, które same nie liczyły prawie nic – były tylko „okienkiem” do centralnego systemu.

Dla banków, ubezpieczycieli i administracji był to idealny wybór: jedno, ściśle kontrolowane środowisko, bardzo wysoka niezawodność, mocne bezpieczeństwo i centralne zarządzanie. Ceną była mała elastyczność i wysoki koszt zmian.

Dlaczego firmy odchodzą od mainframe’ów w stronę mikroserwisów?

W wielu firmach wciąż działa mainframe, a obok zespoły DevOps codziennie wdrażają nowe wersje aplikacji w chmurze. Konflikt pojawia się, gdy biznes potrzebuje zmian „na jutro”, a świat mainframe liczy czas w tygodniach i miesiącach.

Firmy przechodzą do architektury mikroserwisów, bo rynek wymaga szybkiego dostarczania nowych funkcji, eksperymentowania i częstych wdrożeń. Mikroserwisy pozwalają rozwijać małe, niezależne usługi, które można modyfikować i wdrażać osobno, bez dotykania całego monolitu czy centralnego systemu.

Mainframe świetnie rozwiązuje problem niezawodnego, masowego przetwarzania transakcji, ale słabo radzi sobie z dynamiczną zwinnością biznesową. Mikroserwisy są odpowiedzią właśnie na potrzebę szybkości zmian i autonomii zespołów, nawet kosztem większej złożoności technicznej.

Na czym polega różnica między mainframe, architekturą klient–serwer a mikroserwisami?

W dużym uproszczeniu można to zobaczyć jako trzy etapy dojrzewania IT w firmach. Każdy kolejny etap próbował rozwiązać problemy poprzedniego.

• Mainframe – jeden centralny komputer, terminale znakowe, wszystkie ważne procesy i dane w jednym miejscu. Maksimum kontroli i niezawodności, minimum elastyczności.
• Klient–serwer – centralny serwer (zwykle baza danych) oraz „gruby klient” na komputerze użytkownika, z logiką biznesową i interfejsem. Dane są scentralizowane, ale moc obliczeniowa i interfejs są rozproszone na PC.
• Mikroserwisy – wiele małych, autonomicznych usług komunikujących się zazwyczaj przez sieć (np. HTTP, komunikaty). Każda odpowiada za wąski fragment biznesu, można ją wdrażać, skalować i rozwijać niezależnie.

Przejście od mainframe do klient–serwer i dalej do mikroserwisów to w praktyce droga od centralizacji do coraz większego rozproszenia – zarówno technologii, jak i odpowiedzialności zespołów.

Dlaczego architektura mainframe utrudnia zwinne wytwarzanie oprogramowania?

Wyobraź sobie, że każda drobna zmiana w aplikacji wymaga przejścia przez kilka komitetów, papierowych akceptacji i okna wdrożeniowego raz na miesiąc. Tak wyglądał (i często nadal wygląda) świat mainframe’ów.

Proces wytwarzania oprogramowania na mainframe jest z natury mocno sformalizowany: ścisły podział ról (analityk, programista, operator, administrator, tester), długie cykle zmian, wdrożenia w ściśle określonych terminach i z dużą ostrożnością. Zmiana na systemie, który obsługuje całą księgowość albo rozliczenia kart płatniczych, zawsze jest ryzykowna.

W praktyce oznacza to małą elastyczność, trudność w szybkim eksperymentowaniu i duże koszty dostosowania systemu do nowych potrzeb rynku. To, co daje stabilność i bezpieczeństwo, jednocześnie blokuje typową „zwinność” w rozumieniu częstych, małych wdrożeń.

Jak powstanie komputerów osobistych i model klient–serwer zmieniły architekturę systemów?

Kiedy komputery trafiły z serwerowni na biurka, każdy dział zaczął robić „swoje IT”: arkusze kalkulacyjne, lokalne bazy danych, małe aplikacje w Accessie. Biznes wreszcie mógł coś zbudować bez wpisywania się w wielomiesięczną kolejkę zmian na mainframe.

Architektura klient–serwer była próbą uporządkowania tego chaosu. Dane znów trafiły na centralny serwer bazy danych, ale logika i interfejs użytkownika zostały na komputerach pracowników. Dzięki temu:

• działy zyskały szybszy rozwój aplikacji dopasowanych do ich potrzeb,
• firma odzyskała centralną kontrolę nad danymi i większą spójność informacji,
• odciążono mainframe, przenosząc część pracy na tańsze PC.

Ten etap pokazał, że da się pogodzić pewien poziom centralizacji z większą autonomią zespołów – co później rozwinęło się w kierunku usług, SOA i mikroserwisów.

Czy mikroserwisy zawsze są lepsze od mainframe i monolitu?

Niektóre organizacje próbowały przepisać wszystko na mikroserwisy, a po roku okazało się, że system jest bardziej skomplikowany, droższy w utrzymaniu i wcale nie tak stabilny, jak stary monolit. Sam „styl architektoniczny” nie rozwiązuje problemów biznesowych.

Mikroserwisy sprawdzają się tam, gdzie:

• produkt szybko się zmienia i trzeba często wdrażać nowe wersje,
• wiele zespołów pracuje równolegle nad różnymi fragmentami systemu,
• istotna jest elastyczna skalowalność (np. osobno dla modułu płatności, osobno dla wyszukiwarki).

Dla stabilnego, przewidywalnego przetwarzania masowych transakcji (np. rozliczenia końca dnia w banku) scentralizowane rozwiązania wciąż mają sens. Historia architektury pokazuje, że nie ma „lepszej na zawsze” opcji – jest tylko lepsze dopasowanie do aktualnych wymagań biznesu i skali złożoności systemu.

Dlaczego wiele firm nadal utrzymuje mainframe’y, skoro są mikroserwisy i chmura?

W niejednym banku obok nowoczesnego klastra Kubernetes działa mainframe sprzed kilku dekad, na którym liczy się księga główna i rozliczenia kart. Nikt go nie dotyka bez powodu, bo jest zbyt krytyczny.

Powodów jest kilka:

• kluczowe procesy biznesowe są głęboko wbudowane w logikę mainframe’a,
• system działa stabilnie od lat i obsługuje ogromne wolumeny transakcji,
• pełna migracja byłaby ekstremalnie ryzykowna i bardzo kosztowna.

Najważniejsze wnioski

• W wielu firmach nadal współistnieją dwa światy: krytyczne systemy na mainframe’ach, których „boi się ruszyć cała organizacja”, oraz szybko rozwijane aplikacje oparte na mikroserwisach w chmurze.
• Mainframe’y powstały jako centralny „mózg” organizacji – jeden mocny komputer, terminale jako okienka i ściśle kontrolowane środowisko, idealne do masowego, przewidywalnego przetwarzania danych.
• Kluczowe zalety architektury mainframe’owej to centralizacja, wysoka niezawodność, mocne bezpieczeństwo i łatwa administracja, ale okupione bardzo wysokimi kosztami sprzętu, licencji i specjalistów.
• Model wytwarzania oprogramowania na mainframe’ach był silnie sformalizowany i wieloetapowy, co sprzyjało jakości i stabilności, lecz oznaczało tygodnie oczekiwania nawet na drobną zmianę.
• Centralizacja i brak izolacji funkcji utrudniały szybkie eksperymenty: każda modyfikacja niosła duże ryzyko dla całego systemu, więc organizacje unikały częstych wdrożeń.
• Gdy rynek przyspieszył, a wymagania klientów zaczęły się dynamicznie zmieniać, przewaga mainframe’ów w obszarze stabilności zamieniła się w ograniczenie blokujące zwinność biznesową.
• Najważniejsza lekcja z epoki mainframe’ów: każda architektura jest zbiorem kompromisów; centralizacja świetnie rozwiązuje problem niezawodnego przetwarzania masowych transakcji, ale słabo radzi sobie z potrzebą szybkiej adaptacji i częstych zmian.