Monolit vs mikroserwisy - porownanie

Wprowadzenie

Wybor architektury systemu to jedna z najwazniejszych decyzji projektowych, która wpływa na cały cykl zycia aplikacji. Dwie dominujace strategie to architektura monolityczna i architektura mikroserwisowa. Każde podejscie ma swoje zalety i ograniczenia, a wybor zależy od kontekstu projektu.

Nie istnieje uniwersalnie “lepsza” architektura - kluczem jest dopasowanie do wymagan biznesowych, wielkosci zespołu i etapu rozwoju produktu.

Kluczowe pojecia

Monolit

Monolit to aplikacja zbudowana jako pojedyncza, spojona jednostka wdrozeniowa. Wszystkie funkcjonalnosci (autentykacja, logika biznesowa, dostep do danych) znajduja się w jednym procesie i współdziela ten sam kod źródłowy.

Cechy charakterystyczne:

Jeden repozytorium kodu
Jedna baza danych
Jedno wdrozenie
Współdzielona pamieci w runtime

Mikroserwisy

Mikroserwisy to podejscie architektoniczne, w którym system składa się z wielu małych, niezaleznych usług. Każdy mikroserwis odpowiada za jedna funkcjonalnosc biznesowa i może być wdrazany niezależnie.

Cechy charakterystyczne:

Każdy serwis ma własne repozytorium (lub monorepo)
Każdy serwis może mieć własna baze danych
Niezależne wdrozenia
Komunikacja przez siec (HTTP/gRPC/kolejki)

Jak to działa?

Architektura monolityczna

┌─────────────────────────────────────────┐
│              MONOLIT                     │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐   │
│  │  Auth   │ │ Orders  │ │Products │   │
│  └─────────┘ └─────────┘ └─────────┘   │
│  ┌─────────┐ ┌─────────┐ ┌─────────┐   │
│  │  Users  │ │Payments │ │ Reports │   │
│  └─────────┘ └─────────┘ └─────────┘   │
│                  │                       │
│         ┌────────┴────────┐             │
│         │   Baza danych   │             │
│         └─────────────────┘             │
└─────────────────────────────────────────┘

Architektura mikroserwisowa

┌─────────┐   ┌─────────┐   ┌─────────┐
│  Auth   │   │ Orders  │   │Products │
│ Service │   │ Service │   │ Service │
│   DB    │   │   DB    │   │   DB    │
└────┬────┘   └────┬────┘   └────┬────┘
     │             │             │
     └─────────────┼─────────────┘
                   │
           ┌───────┴───────┐
           │  API Gateway  │
           └───────────────┘

Porownanie

Aspekt	Monolit	Mikroserwisy
Złożoność początkowa	Niska	Wysoka
Wdrozenie	Proste (1 artefakt)	Złożone (wiele serwisow)
Skalowalnosc	Pionowa (cały system)	Pozioma (per serwis)
Technologie	Jedna technologia	Możliwość polyglot
Testowanie	Łatwiejsze E2E	Trudniejsze E2E
Debugging	Prostszy	Wymaga distributed tracing
Zespół	Mniejszy, współpracujący	Większy, autonomiczne zespoły
Czas do produkcji	Szybszy start	Wolniejszy start
Odpornosc na błędy	Awaria = cały system	Izolacja błędów

Przykłady w kodzie

Monolit - struktura projektu

ecommerce-monolith/
├── src/
│   ├── auth/
│   │   ├── AuthController.ts
│   │   ├── AuthService.ts
│   │   └── User.entity.ts
│   ├── orders/
│   │   ├── OrderController.ts
│   │   ├── OrderService.ts
│   │   └── Order.entity.ts
│   ├── products/
│   │   ├── ProductController.ts
│   │   └── Product.entity.ts
│   └── app.module.ts
├── package.json
└── docker-compose.yml

Przykład wywołania wewnętrznego (monolit):

// OrderService.ts - bezposrednie wywołanie
class OrderService {
  constructor(
    private productService: ProductService,
    private paymentService: PaymentService
  ) {}

  async createOrder(userId: string, items: CartItem[]) {
    // Bezposrednie wywołanie - ta sama przestrzen pamieci
    const products = await this.productService.validateStock(items);
    const payment = await this.paymentService.processPayment(userId, total);
    return this.orderRepository.save({ userId, items, paymentId: payment.id });
  }
}

Mikroserwisy - struktura projektow

ecommerce-microservices/
├── auth-service/
│   ├── src/
│   ├── Dockerfile
│   └── package.json
├── order-service/
│   ├── src/
│   ├── Dockerfile
│   └── package.json
├── product-service/
│   ├── src/
│   ├── Dockerfile
│   └── package.json
├── api-gateway/
│   └── ...
└── docker-compose.yml

Przykład wywołania miedzy serwisami (mikroserwisy):

// OrderService.ts - wywołanie HTTP do innego serwisu
class OrderService {
  constructor(private httpClient: HttpClient) {}

  async createOrder(userId: string, items: CartItem[]) {
    // Wywołanie sieciowe do innego serwisu
    const products = await this.httpClient.post(
      'http://product-service:3001/api/validate-stock',
      { items }
    );

    const payment = await this.httpClient.post(
      'http://payment-service:3002/api/process',
      { userId, amount: total }
    );

    return this.orderRepository.save({ userId, items, paymentId: payment.id });
  }
}

Kiedy wybrać która architekture?

Wybierz monolit gdy

Projekt jest w fazie MVP/startupu
Zespół jest mały (do 5-10 osob)
Domena biznesowa nie jest jeszcze dobrze poznana
Potrzebujesz szybko dostarczyc produkt
Budzet na infrastrukture jest ograniczony

Wybierz mikroserwisy gdy

System jest duży i dojrzały
Zespół to wiele niezaleznych grup (10+ osob)
Różne części systemu maja różne wymagania skalowania
Potrzebujesz niezaleznych wdrozen
Masz doswiadczenie z DevOps i Kubernetes

Najczestsze błędy

Ewolucja architektury

Start z monolitem - szybki rozwoj, łatwe debugowanie
Modularny monolit - podział na moduły z jasnymi granicami
Wydzielanie serwisow - stopniowa ekstrakcja krytycznych komponentow
Pełna mikroserwisowa - gdy organizacja i produkt tego wymagaja

Podsumowanie

Monolit to dobry wybor na start - prosty, szybki w rozwoju, łatwy do debugowania
Mikroserwisy sprawdzaja się w dużych, dojrzałych systemach z wieloma zespołami
Modularny monolit to czesto najlepszy kompromis - zalety obu podejsc
Decyzja powinna być oparta na kontekscie biznesowym, nie modzie technologicznej
Migracja monolit -> mikroserwisy jest możliwa; odwrotnie - bardzo trudna

Zasoby

Martin Fowler - Microservices Klasyczny artykuł definiujacy architekture mikroserwisowa

Sam Newman - Building Microservices Książka referencyjna o projektowaniu mikroserwisow

MonolithFirst - Martin Fowler Dlaczego warto zaczac od monolitu