Monolith vs. Microservices — die Grundlagen
Bevor wir die pragmatische Entscheidung treffen, müssen wir verstehen, was wir vergleichen.
Ein Monolith ist eine einzelne Deployment-Einheit. Alle Code-Module (User-Management, Billing, Reporting, Notifications) sind in einer Codebasis und laufen in einem Prozess. PostgreSQL-Datenbank, eine Redis-Instanz, fertig. Deployment: Sie pushen auf Main, CI/CD deployt die neue Version, alle Module sind sofort live.
Microservices sind das Gegenteil: Jede Domäne (Users, Billing, Reporting) ist ein eigener Service mit eigenem Code, eigener Datenbank, eigenem Deployment. Services kommunizieren über APIs (HTTP, gRPC, Messaging-Queues). Das klingt modular — und ist es auch. Aber es kommt mit einem Preis.
| Aspekt | Monolith | Microservices |
|---|---|---|
| Deployment | 1 Deployment, alle Features live | N Deployments, orchestriert |
| Skalierung | Ganzer Service horizontal skaliert | Einzelne Services nach Bedarf skaliert |
| Team-Größe | 3-8 Entwickler möglich | 20+ Entwickler nötig, um effizient zu sein |
| Komplexität | Weniger Infrastruktur, klare Code-Struktur | Mehr Infrastruktur, verteilte Systeme-Komplexität |
| Time-to-Market | Feature schnell in Produktion | Mehr Koordination, Overhead |
| Kosten | Einfache VM oder Heroku | Kubernetes, API-Gateways, Observability |
Warum Microservices für die meisten KMUs überdimensioniert sind
Die meisten Blog-Posts über Microservices stammen von Leuten, die Microservices verkaufen. Cloud-Anbieter, DevOps-Consulting-Firmen, Kubernetes-Trainer — alle haben Interesse, dass Sie sich in komplexe Infrastruktur investieren. Das ist kein Vorwurf, das ist ein Geschäftsmodell. Aber es führt zu schlechten Architektur-Entscheidungen.
Hier sind die echten Kosten einer Microservices-Architektur:
1. Infrastruktur-Overhead
Microservices brauchen einen Container-Orchestrator (Kubernetes), einen API-Gateway, Service-Discovery, Distributed Tracing. Das ist keine leichte Setup-Frage — das ist ein Vollzeit-Job für einen DevOps-Ingenieur. Bei 3-5 Entwicklern ist das eine Person, die nichts anderes macht. Der ROI ist negativ.
2. Betriebsaufwand verdoppelt sich
Statt eine Datenbank zu monitoren, monitoren Sie N Datenbanken. Statt eine Service zu debuggen, debuggen Sie Netzwerk-Latenz zwischen Services. Statt einen Deploy zu rollback, koordinieren Sie N Rollbacks. Die Fehlerwahrscheinlichkeit steigt nicht linear, sondern exponentiell.
3. Verteilte Systeme sind verdammt schwer
Sobald Sie Microservices haben, haben Sie ein verteiltes System. Das bedeutet:
- Netzwerk-Partitionierung: Was passiert, wenn Service A und Service B kurzzeitig nicht kommunizieren können? Wer wins bei Datenkonsistenz?
- Transaktions-Grenzen: In einem Monolith ist Atomarität einfach (eine Datenbank-Transaktion). In Microservices? Saga Pattern, Event Sourcing, Eventual Consistency — alles kompliziert.
- Debugging: Ein Request geht durch 5 Services — wie debuggen Sie, welcher Service der Bottleneck ist?
Praxis-Tipp: Wenn Sie weniger als 5 Entwickler haben, ist die Microservices-Diskussion in 99% der Fälle verfrüht. Der Overhead der Koordination ist größer als der Overhead der monolithen Code-Wartung.
4. Team-Entkopplung ist ein Traum ohne Organization
Ein häufiges Argument für Microservices: "Teams können unabhängig arbeiten." Das stimmt — wenn Sie eine klare Organisation haben, wo Team A für Users, Team B für Billing verantwortlich ist. Aber in den meisten KMUs ist die Realität: Jede Änderung betrifft mehrere Module, und plötzlich müssen die Teams ständig miteinander absprechen. Der Vorteil ist weg, die Komplexität bleibt.
Der Modular Monolith — der pragmatische Mittelweg
Es gibt eine bessere Lösung: Den Modular Monolith.
Ein Modular Monolith ist eine einzige Deployment-Einheit mit streng definierten, internen Modul-Grenzen. Jedes Modul hat klare Responsibilities, Interfaces und ist von anderen Modulen entkoppelt — nicht durch APIs, sondern durch Code-Strukturen.
Beispiel in Rails:
app/ ├── modules/ │ ├── users/ │ │ ├── models/ │ │ ├── services/ │ │ └── controllers/ │ ├── billing/ │ │ ├── models/ │ │ ├── services/ │ │ └── webhook_handlers/ │ └── reporting/ │ ├── models/ │ └── jobs/ ├── shared/ │ └── (Authentifizierung, Autorisierung) └── config/
Jedes Modul hat:
- Klare Schnittstellen: Andere Module kommunizieren nur über definierte Services/APIs
- Eigene Tests: Jedes Modul hat Test-Suite
- Datenschicht-Isolation: Jedes Modul hat sein Datenbank-Schema
- Aber: Alles läuft im selben Prozess, in einer gemeinsamen Datenbank, mit einem Deploy
Vorteile gegenüber einem Microservices-Setup:
- Einfaches Deployment (1 Docker-Image statt N)
- Keine Netzwerk-Latenz zwischen Modulen
- Transaktionen bleiben atomar
- Development-Loop schnell (lokal eine Instanz)
- Aber immer noch modular und testbar
Und wenn Sie später feststellen, dass das Billing-Modul anders skaliert als das User-Modul? Dann können Sie selektiv das Billing-Modul in einen Service extrahieren — ohne den ganzen Stack umzuwerfen.
Praxis-Beispiel: Shopify startete als Monolith, Stripe als Monolith, Figma als Monolith. Sie blieben Monolithen — nur modular strukturiert. Shopify nutzt seit Jahren ein "scaled monolith" mit klaren Modul-Grenzen und kann trotzdem Millionen Requests handhaben.
Für wen Microservices tatsächlich Sinn machen
Jetzt die wichtige Klarstellung: Microservices sind nicht schlecht. Für bestimmte Organisationen sind sie die richtige Wahl. Aber das ist selten.
Microservices machen Sinn, wenn:
- Teams ab 20+ Entwicklern: Mit dieser Größe können Sie mehrere autonome Teams haben, die wirklich unabhängig arbeiten
- Fundamental unterschiedliche Skalierungsanforderungen: Ihr User-Management ist 99.9% Reads, aber Ihr Video-Processing ist CPU-intensiv. Das rechnet sich nicht, beide auf einer VM zu hosten
- Multi-Mandanten-Architektur mit Compliance-Anforderungen: Ein Mandant darf nicht die Daten eines anderen sehen — isolierte Services sind sauberer
- Unabhängige Release-Zyklen pro Team: Team A deployed alle 2 Stunden, Team B alle 2 Wochen, Team C einmal pro Monat. Das setzt Microservices voraus
- Regulierte Industrie (Fintech, Healthcare): Isolierte Services erfüllen Compliance-Anforderungen leichter
- Extreme Load (>1M Requests/sec): Bei dieser Größe ist Modular Monolith nicht mehr praktisch
Wenn Sie zwei oder mehr dieser Punkte erfüllen, dann: ja, Microservices. Aber das ist selten in KMUs.
| Kriterium | Monolith OK? | Microservices nötig? |
|---|---|---|
| Entwicklerteam Größe | 5-15 Entwickler | 20+ Entwickler |
| Requests pro Sekunde | Bis ~10k | 100k+ |
| Datenvolumen | Bis ~1TB | 10TB+ |
| Unterschiedliche Skalierungsanforderungen | Nein, ähnlich | Ja, extrem unterschiedlich |
| Unabhängige Teams | 1-2 Teams, enge Abstimmung | 3+ Teams, völlig unabhängig |
Die Entscheidung treffen — ein Framework
Okay, wie entscheiden Sie jetzt? Hier ist ein Framework:
Frage 1: Wie groß ist Ihr Entwicklerteam?
- Weniger als 8 Entwickler → Monolith (Microservices sind overkill)
- 8-15 Entwickler → Modular Monolith (beste Balance)
- 15+ Entwickler → Evaluieren Sie Microservices, wenn Punkt 2 oder 3 zutrifft
Frage 2: Haben Teile Ihres Systems fundamental unterschiedliche Skalierungsanforderungen?
- Nein → Monolith bleibt beste Wahl
- Ja → Modular Monolith mit späterer Option, Module zu extrahieren
- Sehr ja (wie Video-Processing vs. User-Auth) → Microservices für diese spezifischen Module
Frage 3: Können Sie sich den Betriebsaufwand leisten?
- Nein (keine DevOps-Person) → Monolith
- Ja, aber knapp (1 DevOps-Person) → Modular Monolith max, Microservices sprengt Budget
- Ja, großes DevOps-Team → Microservices ist Optionen
Entscheidungs-Regel: Wenn 2 oder mehr Antworten auf der Monolith-Seite sind, starten Sie mit einem Modular Monolith. Sie können später immer noch migrieren, wenn die Anforderungen sich ändern.
Häufig gestellte Fragen
Nein. Ein Monolith ist kein Anti-Pattern — schlechte Architektur ist. Ein gut strukturierter Monolith mit klaren Modul-Grenzen ist wartbar, skalierbar und produktiv. Große Unternehmen wie Stripe, Figma und Shopify setzen auf skalierte Monolithen. Der Fehler wäre, einen Monolith zu bauen, der monolithen Code hat (alles durcheinander gemischt). Das ist unterschiedlich.
Ja, aber mit Aufwand. Der klassische Weg ist, den Monolith erst zu modularisieren (wenn das noch nicht passiert ist), dann einzelne Module selektiv zu extrahieren, indem Sie Wrapper-Services um sie bauen. Das funktioniert am besten, wenn die Modul-Grenzen von Anfang an sauber sind. Deshalb: Mit Modular Monolith starten, nur extrahieren, wenn ein spezifisches Problem echte Schmerzen verursacht.
Microservices brauchen deutlich mehr Infrastruktur: Container-Orchestrierung (Kubernetes), API-Gateways, Service-Discovery, erweiterte Monitoring- und Logging-Systeme, Distributed Tracing. Rechnen Sie mit 2-3x höheren Betriebskosten als bei einem Monolith — ohne dass die Geschwindigkeit steigt. Im Gegenteil: Netzwerk-Latenz ist neuer Bottleneck.
Die Cloud macht Microservices einfacher zugänglich (Container, serverless Functions, Kubernetes as a Service), aber nicht weniger komplex. Ein Monolith läuft auf einem VM auf AWS genauso gut wie auf Heroku — und billiger. Die Cloud-Technologie ist Werkzeug, nicht Ursache der Entscheidung. Viele Leute wählen Microservices, weil "wir jetzt auf AWS sind" — das ist rückwärts gedacht.
Ein Modular Monolith ist ein einzelnes Deployment mit klarer interner Struktur. Beispiel: Eine Rails-App mit /app/modules/users, /app/modules/billing, /app/modules/reporting — jedes Modul hat klare Grenzen und Interfaces (Service-Objekte), kann aber zur Laufzeit direkt miteinander kommunizieren (kein HTTP-Overhead). Das User-Modul ruft ein Billing-Service auf, das User-Modul gibt zurück, fertig — eine Datenbank-Transaktion, atomare Consistency.
Nicht zwingend. Viele erfolgreiche SaaS-Produkte (Figma, Slack, Notion) starten mit einem Modular Monolith. Microservices werden interessant, wenn unterschiedliche Kundensegmente extrem unterschiedliche Skalierungsprofile haben (ein Mandant hat 100k Users, ein anderer 10) oder wenn Sie Teams haben, die wirklich unabhängig voneinander arbeiten können. Für die meisten SaaS-Startups: Modular Monolith ist der smarte Weg.
Fazit: Die beste Architektur ist die, die funktioniert
Die beste Architektur ist nicht die trendigste, nicht die, die Ihre Consultant empfiehlt — es ist die Architektur, die:
- Ihr Team beherrscht und kann maintainen
- Ihr Business unterstützt und nicht blockiert
- Kosteneffizient ist — ohne versteckte Betriebskosten
- Skalierbar ist für die Anforderungen, die Sie tatsächlich haben
Für 90% der KMUs ist das ein gut strukturierter, modular aufgebauter Monolith. Das ist nicht sexy, aber es ist pragmatisch. Und wenn sich später die Anforderungen ändern? Dann haben Sie die Fundamente (klare Modul-Grenzen), um gezielt zu extrahieren.
Die meisten Startup-Fehlentscheidungen entstehen nicht, weil Leute zu wenig technische Komplexität bauen — sondern weil sie zu viel bauen, bevor sie es brauchen.