Czym jest architektura monolityczna?
Monolit to tradycyjne podejście, gdzie cała aplikacja działa jako jeden spójny system. Wszystkie komponenty aplikacji – od interfejsu użytkownika po warstwę dostępu do danych – są ściśle powiązane i działają w ramach jednego procesu.
Kluczowe cechy:
- Jedna baza kodu
- Wspólna baza danych
- Wszystkie funkcje aplikacji w jednym procesie
- Jedno wdrożenie całego systemu
Czym jest architektura mikroserwisowa?
Mikroserwisy rozbijają aplikację na zbiór małych, niezależnych usług, które komunikują się ze sobą przez API. Każdy mikroserwis odpowiada za konkretną funkcjonalność biznesową i może być rozwijany, wdrażany i skalowany niezależnie.
Kluczowe cechy:
- Wiele niezależnych serwisów
- Oddzielne bazy danych dla poszczególnych serwisów
- Komunikacja przez API (REST, gRPC, komunikaty itp.)
- Niezależne wdrożenia dla każdego serwisu
Wpływ na proces wdrożenia
Monolit
- Łatwość początkowa: Wdrożenie monolitu jest początkowo proste – uruchamiasz jeden proces i gotowe.
- Rosnąca złożoność: Z czasem wdrożenia stają się coraz bardziej ryzykowne – jedna zmiana może wpłynąć na cały system.
- Dłuższy czas budowania: Gdy aplikacja rośnie, proces budowania i testowania wydłuża się.
Mikroserwisy
- Złożoność od początku: Już na starcie wymaga przygotowania infrastruktury dla wielu serwisów.
- Ciągłe dostarczanie: Łatwiej wprowadzać zmiany w poszczególnych częściach systemu bez ryzyka dla całości.
- Niezależność zespołów: Różne zespoły mogą wdrażać swoje serwisy bez blokowania się nawzajem.
- Wymagania infrastrukturalne: Potrzebujesz narzędzi do orkiestracji kontenerów, monitorowania, CI/CD.
Wpływ na skalowalność
Monolit
- Skalowanie całości: Musisz skalować cały system, nawet jeśli tylko jedna funkcja wymaga dodatkowych zasobów.
- Proste skalowanie horyzontalne: Łatwo dodać więcej instancji tego samego kodu za load balancerem.
- Ograniczenia technologiczne: Cały system musi być napisany w tej samej technologii.
Mikroserwisy
- Precyzyjne skalowanie: Możesz skalować tylko te serwisy, które tego potrzebują, oszczędzając zasoby.
- Różnorodność technologii: Każdy serwis może być napisany w innym języku programowania lub frameworku.
- Elastyczność: Łatwiejsze dostosowanie do zmieniających się wymagań biznesowych.
Wpływ na złożoność systemu
Monolit
- Prosta architektura początkowa: Łatwiej zrozumieć system, gdy wszystko jest w jednym miejscu.
- Rosnący chaos: Z czasem, bez rygorystycznego podejścia, monolit może przerodzić się w „big ball of mud”.
- Łatwiejsze debugowanie: Śledzenie przepływu żądań jest prostsze w ramach jednego procesu.
Mikroserwisy
- Złożoność rozproszona: System jest trudniejszy do zrozumienia jako całość.
- Wyzwania debugowania: Śledzenie żądań przechodzących przez wiele serwisów wymaga zaawansowanych narzędzi.
- Problemy sieciowe: Opóźnienia w komunikacji między serwisami mogą wpływać na wydajność całego systemu.
- Obsługa częściowych awarii: Musisz przewidzieć i obsłużyć sytuacje, gdy niektóre serwisy są niedostępne.
Przykład system e-commerce
Wyobraźmy sobie system e-commerce z funkcjami takimi jak katalog produktów, koszyk, płatności i zarządzanie zamówieniami.
Podejście monolityczne:
Wszystkie funkcje działają w ramach jednej aplikacji. Gdy Black Friday powoduje nagły wzrost ruchu, cały system musi być skalowany, choć przeciążona jest głównie funkcjonalność koszyka i płatności. Wprowadzenie nowej metody płatności wymaga wdrożenia całego systemu, co zwiększa ryzyko.
Podejście mikroserwisowe:
Każda funkcja działa jako oddzielny serwis. Podczas Black Friday można skalować tylko serwisy obsługujące koszyk i płatności. Nowa metoda płatności może być wdrożona bez dotykania reszty systemu.
Jednak w mikroserwisach pojawiają się nowe wyzwania:
- Operacja „złożenie zamówienia” wymaga koordynacji między wieloma serwisami
- Gdy serwis płatności działa wolno, trudniej zdiagnozować, czy problem leży w nim, czy w serwisach, które z nim komunikują
- Z każdym nowym serwisem rośnie złożoność całej infrastruktury
Kiedy wybrać monolit?
- Gdy zaczynasz nowy projekt i nie masz pewności co do wymagań
- Gdy szybkość rozwoju jest kluczowa, a zespół jest mały
- Gdy nie masz doświadczenia z systemami rozproszonymi
- Gdy skala projektu nie jest bardzo duża
Kiedy wybrać mikroserwisy?
- Gdy spodziewasz się dużego wzrostu i skali
- Gdy masz wystarczająco duży zespół, który można podzielić
- Gdy różne części systemu mają różne wymagania wydajnościowe
- Gdy potrzebujesz niezależnego wdrażania poszczególnych komponentów
Podsumowanie
Wybór między monolitem a mikroserwisami nie jest czarno-biały. Wiele firm zaczyna od dobrze zaprojektowanego monolitu, a dopiero gdy pojawią się konkretne problemy ze skalowaniem lub szybkością rozwoju, decydują się na migrację do mikroserwisów.
Pamiętaj, że mikroserwisy nie są celem samym w sobie, ale rozwiązaniem konkretnych problemów. Jeśli nie masz tych problemów, monolit może być prostszym i bardziej efektywnym rozwiązaniem.
Najważniejsze, aby zrozumieć kompromisy, jakie wiążą się z każdym podejściem, i wybrać to, które najlepiej pasuje do Twoich potrzeb biznesowych, możliwości zespołu i planów rozwoju.