Co kilka miesięcy jakiś CTO czyta artykuł o Netflixie lub Amazonie i decyduje, że czas rozłożyć monolit na części. Pół roku później zespół jest wyczerpany, dostarczanie stanęło w miejscu, a architektura mikroserwisowa jest jakoś trudniejsza w utrzymaniu niż to, od czego zaczęli.

Wiedzieć kiedy refaktoryzować monolit do mikroserwisów jest trudniej niż wiedzieć jak. Większość migracji nie kończy się niepowodzeniem przez złe decyzje architektoniczne, lecz dlatego, że decyzja o migracji zapadła zanim problem był wystarczająco realny, żeby ją uzasadniać.

Ten przewodnik opisuje sygnały, które sprawiają, że migracja jest warta zachodu, sygnały, które mówią żeby poczekać i jak wygląda przyrostowa migracja w produkcji, na przykładzie systemu obsługującego 1,8 miliona użytkowników.

Czym jest monolit i dlaczego zaczynanie od niego ma sens

Monolit wdraża się jako jedną jednostkę: cała logika biznesowa w jednej bazie kodu, jedna baza danych, jeden pipeline wdrożeniowy. Na początku ta prostota ma realną wartość, oferuje jedno miejsce do sprawdzenia gdy coś się psuje, jedno wdrożenie do zarządzania, żadnej złożoności systemów rozproszonych.

Zgodnie z szeroko cytowaną zasadą Martina Fowlera „Monolith First”, większość udanych systemów mikroserwisowych zaczynała jako monolity. Architektura staje się problemem dopiero gdy aplikacja ją przerasta. Dzieje się to w konkretny, identyfikowalny sposób: skalowanie jednego komponentu wymaga skalowania całego systemu, zespoły pracujące na jednej bazie kodu zaczynają blokować wzajemne wdrożenia, ryzyko przy deploymencie rośnie wraz z powierzchnią aplikacji. To są symptomy, dla których warto migrować. Wiek bazy kodu, preferencje zespołu i to co robią konkurenci absolutnie nie są.

Kiedy refaktoryzować monolit do mikroserwisów: 4 konkretne sygnały

1. Wąskie gardła skalowalności generują mierzalne straty infrastrukturalne. Jeden komponent potrzebuje 10-krotnie więcej zasobów niż reszta aplikacji. W monolicie skalowanie tego komponentu oznacza skalowanie wszystkiego. Według badania CNCF z 2024 roku, 72% organizacji które skutecznie przeszły na mikroserwisy wskazało niezależne skalowanie jako główny powód. Mikroserwisy pozwalają skalować poszczególne usługi zależnie od rzeczywistego obciążenia. Oszczędności infrastrukturalne narastają z czasem.

2. Overhead koordynacji zespołów widocznie spowalnia dostarczanie. Wiele zespołów, jedna baza kodu. Każde wdrożenie wymaga synchronizacji. Kiedy granice zespołów i granice bazy kodu przestają się pokrywać, coś musi ustąpić. Prawo Conwaya mówi, że organizacje projektują systemy odzwierciedlające ich strukturę komunikacji, jeśli struktura zespołów się zmieniła, a architektura nie, ta luka będzie spowalniać dostarczanie.

3. Ryzyko wdrożenia stało się hamulcem częstotliwości wydań. Mała zmiana funkcjonalna wymaga pełnego testu regresji całej aplikacji. Zespół opóźnia wydania, grupuje zmiany i kumuluje ryzyko zamiast dostarczać. Niezależność wdrożeń (jedna usługa wypuszczana bez dotykania pozostałych) rozwiązuje to bezpośrednio. Jeśli zespół robi mniej niż jedno wdrożenie produkcyjne tygodniowo z powodu ryzyka deploymentu, to konkretny sygnał.

4. Konkretny komponent naprawdę potrzebuje innego stosu technologicznego. Moduł intensywnie przetwarzający dane, który działałby lepiej z inną bazą. Funkcja czasu rzeczywistego wymagająca innej infrastruktury. Monolit narzuca jeden stos każdemu komponentowi, bez względu na dopasowanie. Tu wchodzą w grę migracja systemów IT – przeniesienie konkretnych komponentów do środowisk odpowiadających ich rzeczywistym wymaganiom.

Kiedy NIE refaktoryzować monolitu do mikroserwisów

Zespół jest mały. Mikroserwisy wprowadzają overhead operacyjny. Service discovery, distributed tracing, komunikację między usługami, wiele pipeline’ów wdrożeniowyc, którym pięcioosobowy zespół będzie zarządzał kosztem budowania produktu.

Granice domen wciąż się zmieniają. Złe granice w monolicie naprawia się tanio, natomiast złe granice między niezależnie wdrażanymi usługami wymagają skoordynowanych migracji. Jeśli produkt wciąż ewoluuje szybko, poczekaj aż model domenowy się ustabilizuje.

Nie ma zdefiniowanego konkretnego problemu. „Powinniśmy używać mikroserwisów” to preferencja architektoniczna. „Tracimy 30% budżetu infrastrukturalnego na nieefektywność skalowania” to problem biznesowy. Według badania InfoQ z 2023 roku, 63% zespołów które porzuciły migracje do mikroserwisów wskazało niejasne uzasadnienie biznesowe jako przyczynę.

Nie możesz napisać jednego zdania opisującego co będzie lepsze po refaktoryzacji. Jeśli to zdanie nie przychodzi łatwo, decyzja nie jest gotowa.

Jak refaktoryzować monolit do mikroserwisów: podejście przyrostowe

Pełne przepisania kończą się niepowodzeniem. Historia oprogramowania jest pełna „big bang” migracji, które przepaliły budżety, wyczerpały zespoły i ostatecznie zostały porzucone lub okrojone.

Wzorzec który działa to Strangler Fig (Figowiec Dusiciel), ukuty przez Martina Fowlera: wyodrębniasz usługi przyrostowo na brzegach monolitu, podczas gdy on sam nadal działa. Monolit kurczy się w miarę jak usługi przejmują jego odpowiedzialności. System działa przez cały czas. Na każdym etapie możliwy jest powrót do poprzedniego stanu.

Nasz refaktoring monolitu do mikroserwisów jest zbudowany właśnie wokół tego przyrostowego wzorca. Żadnych pełnych przepisań, żadnych okien serwisowych dla systemów które na to nie potrzebują.

Krok 1: Zmapuj granice domen przed napisaniem jakiegokolwiek nowego kodu. Zrozum, które części monolitu mają stabilne, jasne odpowiedzialności. To są kandydaci do ekstrakcji. Moduły z wieloma zależnościami od reszty systemu nie są punktem startowym.

Krok 2: Wyodrębnij najpierw usługę z najmniejszą liczbą zależności. Celem pierwszej ekstrakcji jest udowodnienie wzorca i budowanie pewności zespołu, nie rozwiązywanie najtrudniejszego problemu. Sukces tutaj sprawia, że każda kolejna ekstrakcja jest szybsza.

Krok 3: Wymuś własność bazy danych od pierwszego dnia. Każda usługa musi być właścicielem swoich danych. „Mikroserwis” który współdzieli bazę danych z monolitem to rozproszony monolit trudniejszy w rozumowaniu niż punkt wyjścia, bez większości korzyści.

Krok 4: Zbuduj infrastrukturę obserwowalności zanim jej potrzebujesz. Systemy rozproszone psują się inaczej niż monolity. Logowanie i śledzenie przez granice usług musi istnieć zanim wiele usług trafi do produkcji, nie po pierwszym incydencie.

Refaktoryzacja monolitu w praktyce: case study mySugr

W 2018 roku mySugr aplikacja do zarządzania cukrzycą używana przez 1,8 miliona ludzi na całym świecie dołączyła do grupy Roche. Fuzja stworzyła natychmiastowe ograniczenie techniczne: mySugr działał na MySQL, Roche standaryzował na PostgreSQL. Wprowadzenie Aurora 3 przez AWS dodało twardy termin – istniejące środowisko zostałoby bez wsparcia przed 2024 rokiem.

Zespół fireup.pro dostał zadanie przeprowadzenia migracji systemu ze znaczącymi ograniczeniami: działająca produkcyjna aplikacja healthcare bez tolerancji na przestoje, niekompatybilne systemy baz danych i środowisko danych wrażliwych na compliance.

Pierwsze podejście: zbudować gałąź aplikacji mogącą działać równocześnie na MySQL i PostgreSQL. Nie jako stan docelowy lecz w formie ubezpieczenia. Gdyby produkcyjna migracja natrafiła na krytyczny problem, cofnięcie nie wymagałoby pełnego rollbacku.

Różnice techniczne między systemami były realne. MySQL podchodzi do standardów SQL permisywnie; PostgreSQL jest ścisły. Precyzja DateTime różni się – MySQL do sekundy, PostgreSQL do mikrosekund. Typy FLOAT zachowują się inaczej. Wielkość liter działa inaczej. Każda luka wymagała indywidualnego rozwiązania, zweryfikowanego przez dwa miesiące testów QA przed głównym przełączeniem.

Migracja wykorzystała wiedzę z zakresu konsultingu Amazon Web Services i AWS Database Migration Service w dwóch fazach:

  • Faza 1 — Initial load: Pełna kopia istniejących danych
  • Faza 2 — Ciągła migracja CDC: Wszystkie zmiany przechwytywane od momentu initial load, eliminując potrzebę okna serwisowego

Karl Spies, Backend Developer w mySugr, opisał projekt: „Zrobiliśmy coś podobnego do zmiany opon w Formule 1, ale kiedy samochód był jeszcze na torze wyścigowym, w ruchu.”

Wynik: 50% redukcja kosztów utrzymania aplikacji. Dziewięć miesięcy od proof of concept do produkcji. Zero przerw w działaniu serwisu dla 1,8 miliona użytkowników.

Pełny opis techniczny w case study mySugr.

Rzeczywiste koszty migracji monolitu do mikroserwisów

Czas deweloperski i infrastruktura to widoczne pozycje budżetowe. Projekty konsekwentnie przekraczają szacunki z powodu kosztów niewidocznych na początku.

Infrastruktura testowa to najczęstsze zaskoczenie. Systemy rozproszone wymagają testów integracyjnych przez granice usług, które nie istnieją na początku migracji. Odpowiednia automatyzacja testów, zbudowana zanim pierwsza usługa trafi do produkcji zwraca tę inwestycję. Zespoły które ten krok pomijają, odkrywają to później przy wyższym koszcie.

Złożoność operacyjna rośnie z liczbą usług. Każda nowa usługa to nowy pipeline wdrożeniowy, nowa konfiguracja monitoringu, nowy zestaw możliwych awarii. Pojemność DevOps musi skalować się z architekturą.

Onboarding deweloperów staje się trudniejszy zanim stanie się łatwiejszy. Nowi członkowie zespołu muszą rozumieć wiele usług i ich granice. Dokumentacja staje się nośną infrastrukturą, nie opcją.

Latencja sieciowa zastępuje wywołania wewnątrz procesu. Dla większości przypadków użycia to nie problem. Dla komunikacji wysokiej częstotliwości lub ostrych wymagań czasowych tworzy ograniczenia wydajności, które trzeba projektować od początku.

Według Gartnera (2024), organizacje które niedoszacowują te ukryte koszty są 2,3-krotnie bardziej skłonne do wstrzymania lub porzucenia migracji w połowie wykonania.

Kiedy zewnętrzna ekspertyza ma znaczenie

Część migracji leży w możliwościach wewnętrznego zespołu. Inne nie i to nie ze względu na brak umiejętności zespołu, lecz dlatego że złożoność domeny, ryzyko migracji i bieżące dostarczanie produktu tworzą obciążenie zbyt duże do zarządzania równocześnie.

Zewnętrzna ekspertyza dodaje mierzalną wartość w konkretnych sytuacjach: regulowane środowiska danych gdzie błędy mają implikacje compliance (healthcare, fintech); zespoły bez wcześniejszego doświadczenia w dekompozycji żywych systemów produkcyjnych; monolity na tyle słabo udokumentowane że granice domen nie są jasne wewnętrznie; terminy których aktualna pojemność zespołu nie udźwignie bez opóźnienia prac nad produktem.

Nasze usługi refaktoryzacji systemów obejmują pełny zakres: wstępna ocena architektury, mapowanie domen, przyrostowa ekstrakcja i przekazanie na produkcji. Rozpoznawanie wzorców z poprzednich migracji skraca czas planowania i redukuje koszt nieoczekiwanych problemów.

fireUp.pro realizuje projekty refaktoryzacji monolitu i migracji systemów, w tym aplikacje healthcare z milionami aktywnych użytkowników. Jeśli oceniasz czy migracja ma sens dla Twojego systemu, porozmawiaj z naszym zespołem — damy Ci uczciwy feedback, nie ofertę handlową. Zobacz naszą usługę refaktoryzacji monolitu i case study mySugr dla kontekstu.