Monolith vs. Microservices
Ein Monolith ist eine Anwendung — ein Codebase, ein Deploy, eine Datenbank. Microservices spalten dieselbe Anwendung in viele kleine, eigenständige Dienste, die über das Netz kommunizieren.
| Aspekt | Monolith | Microservices |
|---|---|---|
| Deploy | Alles auf einmal | Jeder Service unabhängig |
| Skalierung | Vertikal — alles zusammen | Horizontal — gezielt pro Service |
| Tech-Stack | Eine Sprache, ein Framework | Polyglot — pro Service wählbar |
| Datenbank | Geteilt | Pro Service eigene |
| Komplexität | Im Code | In der Infrastruktur |
| Team-Skalierung | Schwer ab ~30 Devs | Skaliert (Conway's Law) |
| Fehlersuche | Stack-Trace lokal | Distributed Tracing nötig |
Wann Microservices?
- Team mit 30+ Entwicklern, die unabhängig arbeiten müssen
- Teile der App haben sehr unterschiedliche Skalierungs-Bedürfnisse
- Polyglotte Stacks gefordert (z.B. ML in Python, Web in TypeScript)
- Häufige, unabhängige Deploys
Wann NICHT?
- Startup, kleines Team, Pivot wahrscheinlich → Monolith first!
- Domäne nicht klar geschnitten — Service-Grenzen ändern sich
- Team hat keine DevOps-/SRE-Kapazität (Microservices = Ops-Aufwand)
Faustregel von Martin Fowler: "Monolith first" — erst wenn der Monolith echte Schmerzen verursacht, splitten.
Zurück zu Technik