Software architecture

---

Stary, Dobry Monolit

Pracuję z różnymi architekturami systemów od wielu lat i zawsze zastanawiam się, dlaczego niektóre rozwiązania sprawdzają się w jednych organizacjach, a w innych nie. Monolit, czyli tradycyjna architektura aplikacji, ma wiele wspólnego z klasycznym autem. Prosty silnik, mało elektroniki, wszystko jest dobrze znane i łatwe do ogarnięcia. Jak silnik benzynowy w klasyku nie odpala, to wszystko sprowadza się do dwóch powodów:

1. nie ma paliwa
2. nie ma prądu/iskry

(uwaga: bardzo, bardzo upraszczam, ale to nie jest miejsce na dogłębne analizy jak działa silnik)

W monolicie masz jedną bazę danych, jeden deployment, jeden zespół. To jak auto, które każdy mechanik potrafi zdiagnozować i naprawić. Debugowanie jest proste — wszystko jest w jednym miejscu. Transakcje bazodanowe działają niezawodnie. Deployment przypomina spacer — jest prosty i przewidywalny.

Problem polega na tym, że to autko, podobnie jak monolit, ma swoje ograniczenia. Brak czujników parkowania, kamer, udogodnień i systemów wspomagania jazdy. Możesz to wszystko dodać samemu, ale nie jest to proste, a im więcej zmieniasz i dodajesz niestandardowych rzeczy, to tym trudniejsze auto jest do utrzymania. I tak jest też z monolitem. Wprowadzanie zmian staje się coraz trudniejsze. Młodzi programiści narzekają na przestarzałe praktyki. Skalowanie wymaga coraz więcej zasobów.

---

Rewolucja Mikroserwisów

I tutaj wchodzą mikroserwisy — jak najnowsze auta, w których silnik i układ jezdny jest opakowanymi przeróżnymi systemami, które potrafią robić cuda. Mikroserwisy oferują wizję systemu złożonego z niezależnych, małych usług. Ale ta wizja, choć kusząca, budzi uzasadnione obawy.

---

1. Złożoność dystrybucji

To jak przejście od etapu, gdzie do naprawy auta była potrzeba grzechotka, śrubokręt i młotek do momentu, gdy bez szeregu narzędzi diagnostycznych i specjalistycznej wiedzy nie ma co się nawet zabierać do diagnostyki. Każdy mikroserwis potrzebuje własnej infrastruktury, monitoringu, logowania. Świat staje się bardziej skomplikowany.

2. Skomplikowana komunikacja

W monolicie wszystko było w zasięgu ręki. Teraz potrzebujesz niezawodnego systemu komunikacji między serwisami. To jak tony kabli w najnowszych samochodach. W mikroserwisach musisz zdecydować czy łączysz się przez REST API, gRPC czy może postawisz na komunikację rozproszoną (eventy i wiadomości)

3. Wyzwania ze spójnością danych

To jak koordynacja pracy wszystkich systemów jazdy w nowoczesnym samochodzie, aby pomagały kierowcy, zamiast go zabić. Gdy każda mikroserwis ma własną bazę danych, musimy zadbać o synchronizację informacji. Zmiana w jednym miejscu musi być odnotowana we wszystkich potrzebnych miejscach.

---

Cena Transformacji

Z własnego doświadczenia przy transformacjach architektonicznych wiem, że każda ścieżka niesie ze sobą określone koszty i ryzyka. Podczas prowadzenia zespołu pracującego nad rozwojem dużego systemu, który tworzył platformę dla klientów posiadających sklepy e-commerce nauczyłem się, że to, co wygląda świetnie na papierze, w rzeczywistości może być znacznie bardziej skomplikowane.

Podejścia do migracji

---

1. Całkowite Przepisanie Systemu

Ta ścieżka przypomina mi historię mojego kolegi, który pracował w firmie, gdzie chcieli przepisać cały system od zera. Po kilku miesiącach pracy i znaczących inwestycjach, projekt został… zamrożony. Dlaczego? Zapewne nie ma jednoznacznej odpowiedzi, natomiast zobaczmy, jakie są plusy i minusy takiego podejścia:

Zalety:

• Możliwość użycia najnowszych technologii
• Czysty kod bez długu technologicznego
• Architektura dostosowana do aktualnych potrzeb

Wady:

• Ogromne ryzyko biznesowe
• Długi czas bez nowych funkcjonalności
• Wysokie koszty równoległego rozwoju
• Ryzyko utraty wiedzy biznesowej ze starego systemu

---

2. Modernizacja Monolitu

Słyszałem o kilku udanych przypadków modernizacji monolitu. Kluczem było skupienie się na tym, co naprawdę wymaga poprawy, zamiast ślepego podążania za trendami.

Zalety:

• Mniejsze ryzyko - system cały czas działa
• Niższe koszty początkowe
• Możliwość stopniowych ulepszeń
• Zachowanie wiedzy biznesowej

Wady:

• Ograniczenia technologiczne pozostają
• Trudności z fundamentalnymi zmianami
• Problemy ze skalowalnością
• Wyzwania w rekrutacji do starszych technologii

---

3. Stopniowa Transformacja

To podejście zastosowaliśmy w jednym z projektów. Zaczęliśmy od wydzielenia kilku krytycznych funkcjonalności do osobnych serwisów, zachowując działający monolit jako rdzeń systemu.

Zalety:

• Kontrolowane ryzyko
• Możliwość uczenia się na małych projektach
• Zachowanie ciągłości biznesowej
• Stopniowe budowanie kompetencji zespołu

Wady:

• Złożoność okresu przejściowego
• Wolniejsze tempo zmian
• Skomplikowana integracja starego z nowym
• Większe wymagania infrastrukturalne

Przy takim podejściu najlepiej sprwdza się w stanie przejściowym architekturea hybrydowa, w której między frontendem a serwisami backendowymi wstawia się Api Gateway. API Gateway odpowiedzialny jest za autentykację oraz wysyłanie requestów do odpowiednich serwisów.

---

Wnioski z Praktyki

Po miesiącach pracy z mikroserwisami doszedłem do kilku ważnych wniosków:

1. Nie ma uniwersalnych rozwiązań - architektura musi pasować do konkretnej organizacji, jej kultury i potrzeb.

2. Ludzie są ważniejsi niż technologia - najlepsza architektura nie pomoże, jeśli zespół nie jest na nią gotowy.

3. Ewolucja jest lepsza od rewolucji - stopniowe zmiany często przynoszą lepsze rezultaty niż radykalne transformacje.

4. Biznes musi być na pierwszym miejscu - architektura powinna wspierać cele biznesowe, nie być celem samym w sobie.

5. Potrzebny jest czas na naukę - zrobienie pierwszego mikroserwisu nie oznacza, że już “umiesz w mikroserwisy”. To dopiero początek nauki, wszystko przed Tobą.

---

Podsumowanie

Wybór między monolitem a mikroserwisami, a także sposób transformacji, to decyzje, które będą miały długofalowy wpływ na każdą organizację. Kluczem jest znalezienie równowagi między ambicjami technologicznymi a realiami biznesowymi.

Pamiętaj, że ani monolit, ani mikroserwisy nie są złe same w sobie — wszystko zależy od kontekstu. Czasem najlepszym rozwiązaniem może być hybryda obu podejść, gdzie część systemu pozostaje monolitem, a krytyczne komponenty działają jako mikroserwisy.

P.S. Jeśli spodobał Ci się ten artykuł i chcesz otrzymywać więcej podobnych treści, zapisz się na mój newsletter.