Microservices vs. Monolith: Die richtige Architektur

Die Wahl der Architektur beeinflusst Ihr gesamtes Projekt. Lernen Sie die Unterschiede und wann welcher Ansatz passt.

Übersicht

Monolith:                     Microservices:
┌─────────────────────┐       ┌─────┐ ┌─────┐ ┌─────┐
│                     │       │User │ │Order│ │Pay- │
│    Eine Anwendung   │       │Svc  │ │ Svc │ │ment │
│                     │       └──┬──┘ └──┬──┘ └──┬──┘
│  User │ Order │ Pay │          │       │       │
│       │       │     │       ┌──┴───────┴───────┴──┐
│       │       │     │       │    Message Queue    │
└───────┴───────┴─────┘       │    / API Gateway    │
        │                     └─────────────────────┘
   ┌────┴────┐                ┌───┐ ┌───┐ ┌───┐
   │   DB    │                │DB │ │DB │ │DB │
   └─────────┘                └───┘ └───┘ └───┘

Vergleich

Monolith-Vorteile

# Gut strukturierter Monolith
app/
├── modules/
│   ├── users/
│   │   ├── controllers/
│   │   ├── services/
│   │   └── models/
│   ├── orders/
│   │   ├── controllers/
│   │   ├── services/
│   │   └── models/
│   └── payments/
│       ├── controllers/
│       ├── services/
│       └── models/
├── shared/
│   ├── database/
│   └── utils/
└── main.js

# Klare Modul-Grenzen → Spätere Extraktion möglich

Microservices-Vorteile

# Microservices Kommunikation

# Synchron (REST/gRPC)
User Service → HTTP → Order Service
# Einfach, aber: Latenz, Kopplung

# Asynchron (Message Queue)
User Service → Kafka → Order Service
# Entkoppelt, resilient, aber: Eventual Consistency

# Beispiel Event
{
  "event": "user.created",
  "data": {
    "userId": "123",
    "email": "user@example.com"
  },
  "timestamp": "2024-01-15T10:30:00Z"
}

Microservices-Herausforderungen

# 1. Distributed Data
# Jeder Service hat eigene DB → Keine Joins!

# Statt:
SELECT * FROM orders
JOIN users ON orders.user_id = users.id

# Muss:
# 1. Order Service: Get orders
# 2. User Service: Get users by IDs
# 3. Client: Kombinieren

# 2. Distributed Transactions
# SAGA Pattern statt ACID

# 3. Service Discovery
# Wo läuft Service X?
# → Kubernetes, Consul, etc.

# 4. Observability
# Logging, Tracing, Metrics über alle Services
# → ELK, Jaeger, Prometheus

Wann Microservices?

# Checkliste:

☐ Team > 10 Entwickler
☐ Klare Domänengrenzen identifiziert
☐ Unterschiedliche Skalierungsanforderungen
☐ DevOps/Platform-Team vorhanden
☐ CI/CD Pipeline etabliert
☐ Monitoring/Logging-Infrastruktur
☐ Container-Orchestrierung (K8s) möglich

# Wenn < 3 Punkte: Erst Monolith!

Der Modular Monolith

# Kompromiss: Monolith mit klaren Grenzen

┌────────────────────────────────────────┐
│              Monolith                  │
│  ┌──────────┬──────────┬──────────┐   │
│  │  User    │  Order   │ Payment  │   │
│  │  Module  │  Module  │  Module  │   │
│  └────┬─────┴────┬─────┴────┬─────┘   │
│       │          │          │         │
│  ┌────┴──────────┴──────────┴────┐   │
│  │       Shared Infrastructure    │   │
│  └────────────────────────────────┘   │
└────────────────────────────────────────┘

# Regeln:
# - Module kommunizieren nur über definierte APIs
# - Keine direkten Datenbank-Zugriffe zwischen Modulen
# - Jedes Modul könnte später extrahiert werden

Migration: Monolith → Microservices

# Strangler Fig Pattern

1. Neuen Service für NEUE Features
   ┌─────────┐     ┌─────────┐
   │ Monolith│ ←── │New Svc  │
   └─────────┘     └─────────┘

2. Traffic für Feature zu neuem Service
   ┌─────────┐     ┌─────────┐
   │ Monolith│     │New Svc  │◄── Users
   └─────────┘     └─────────┘

3. Alte Implementierung entfernen
   ┌─────────┐     ┌─────────┐
   │ Smaller │     │New Svc  │◄── Users
   │ Monolith│     └─────────┘
   └─────────┘

4. Wiederholen bis Monolith weg

Weitere Informationen

• ☸️ Kubernetes Grundlagen
• 🐳 Docker Compose
• 📊 API Design