Microservices oder Monolith? Architekturentscheidungen für wachsende Teams
Microservices klingen modern, Monolithen gelten als veraltet. Der Beitrag ordnet beide Ansätze praxisnah ein und hilft Teams bei einer passenden Architekturentscheidung.
“Wir brauchen Microservices.” Diesen Satz höre ich oft - manchmal schon im ersten Gespräch, bevor irgendjemand die Anforderungen wirklich durchgedacht hat. Microservices gelten als modern, skalierbar, zukunftssicher. Monolithen dagegen klingen nach technischer Schuld und verpassten Chancen.
Die Realität ist deutlich nuancierter. In den letzten Jahren habe ich beide Ansätze in sehr unterschiedlichen Kontexten eingesetzt - von einem großen Open-Source-Datenökosystem für die Automobilindustrie bis hin zu schlanken Web-Applikationen für mittelständische Unternehmen. Hier ist, was ich gelernt habe.
Weiterführende Artikel zu diesem Thema: Modularer Monolith Zu Microservices Migration und Wann Kubernetes Sinnvoll Ist.
Was Microservices wirklich kosten
Microservices bieten echte Vorteile: unabhängiges Deployment, technologische Flexibilität, bessere Skalierbarkeit einzelner Komponenten. Aber sie bringen auch erhebliche Komplexität mit sich, die oft unterschätzt wird.
Betriebsaufwand. Jeder Service braucht eigenes Deployment, eigene Logs, eigene Healthchecks, eigenes Monitoring. In einem Projekt mit über einem Dutzend Services - verteilt auf Kubernetes mit Helm Charts und ArgoCD - ist die Infrastruktur selbst eine Vollzeitaufgabe. Ohne ein erfahrenes Team und reife DevOps-Prozesse wird das schnell zur Belastung.
Netzwerklatenz und verteilte Fehler. Was in einem Monolithen ein einfacher Methodenaufruf ist, wird zum HTTP-Request oder Nachrichten-Event. Timeouts, Retry-Logik, Idempotenz, Circuit Breaker - all das muss durchdacht und implementiert werden. Ein Fehler in Service A kann Service B blockieren. Distributed Tracing wird unerlässlich.
Datenkonsistenz. Jeder Service sollte seine eigene Datenbank besitzen. Das bedeutet: keine Transaktionen über Service-Grenzen hinweg. Für Szenarien, in denen mehrere Services an einem fachlichen Vorgang beteiligt sind, braucht man Sagas oder ähnliche Muster. Das ist lösbar - aber komplex.
Entwicklungsaufwand. Das lokale Starten einer Entwicklungsumgebung mit zehn Services daürt. Integration Tests werden aufwändiger. Code-Reviews müssen API-Kontrakte zwischen Services berücksichtigen.
Wann Microservices sinnvoll sind
Das heißt nicht, dass Microservices falsch sind. Bei dem Open-Source-Projekt für die Automobilindustrie, an dem ich mehrere Jahre mitgearbeitet habe, war eine Microservice-Architektur die richtige Wahl - weil:
- Verschiedene Teams (in unterschiedlichen Unternehmen) unabhängig voneinander an verschiedenen Services arbeiten mussten
- Die einzelnen Komponenten (Portal, Policy Hub, SSI Credential Issür, Authority Registry) fachlich klar getrennt waren
- Unterschiedliche Services unterschiedliche Skalierungsanforderungen hatten
- Der Betrieb von vornherein auf Kubernetes/AWS ausgelegt war und ein dafür ausgebildetes Ops-Team vorhanden war
Microservices passen gut, wenn Sie bereits organisatorisch nach Services aufgeteilt sind - Conway’s Law funktioniert auch in umgekehrter Richtung.
Wann der Monolith die bessere Wahl ist
Für die meisten mittelständischen Projekte, die ich im Bereich Business Applications begleite, ist ein Monolith - oder besser: ein Modularer Monolith - die bessere Ausgangsbasis.
Warum? Weil die Anforderungen am Anfang oft noch nicht klar genug sind, um sinnvolle Service-Grenzen zu ziehen. Wenn Sie Services zu früh schneiden, schneiden Sie sie wahrscheinlich falsch - und refactoren später teür nach.
Ein Monolith ermöglicht:
- Schnelleres initiales Entwicklungstempo
- Einfachere Debugging und Tracing
- Atomare Transaktionen ohne Saga-Komplexität
- Niedrigere Infrastrukturkosten
Der Modular Monolith als Mittelweg
Mein bevorzugter Ansatz für neü Projekte: Der Modulare Monolith. Ein einzelner Deployment-Artefakt, aber mit klar definierten Modulen, die über Interfaces kommunizieren - nicht direkt über Datenbankzugriffe oder statische Methodenaufrufe.
Das Schöne daran: Wenn später bestimmte Module tatsächlich eigene Skalierung oder unabhängiges Deployment benötigen, lassen sie sich mit überschaubarem Aufwand in echte Microservices extrahieren. Die Modul-Grenzen werden zu Service-Grenzen.
In .NET sieht das konkret so aus: Verschiedene Module als separate Class Library-Projekte, jeweils mit eigener Domäne, Application-Schicht und Infrastruktur. Das Hauptprojekt verbindet alles über Dependency Injection. Kein Modul greift direkt auf den DbContext eines anderen Moduls zu.
Die Entscheidungshilfe
Einige Fragen, die ich mir bei neün Projekten stelle:
| Frage | Microservices | Monolith |
|---|---|---|
| Verschiedene Teams an verschiedenen Teilen? | ✓ | - |
| Stark unterschiedliche Skalierungsanforderungen? | ✓ | - |
| Klare, stabile fachliche Grenzen? | ✓ | - |
| Erfahrenes DevOps-Team vorhanden? | ✓ | - |
| Schneller Start wichtig? | - | ✓ |
| Anforderungen noch im Fluss? | - | ✓ |
| Team kleiner als 5-8 Personen? | - | ✓ |
Wenn die meisten Kriterien für den Monolith sprechen: Starten Sie als Modularer Monolith. Sie können später noch immer aufteilen. Andersherum ist es deutlich schwieriger.
Fazit
Microservices sind kein Qualitätsmerkmal. Sie sind eine Lösung für bestimmte Skalierungs- und Organisationsprobleme - die Sie vielleicht (noch) nicht haben.
Der Modular Monolith bietet einen pragmatischen Mittelweg: klare Struktur ohne die operationale Komplexität von Microservices. In vielen Projekten ist das der richtige Einstieg - mit der Option, bei Bedarf gezielt zu splitten.
Sie planen ein neüs Projekt und sind unsicher, welche Architektur die richtige ist? Kontaktieren Sie uns - wir besprechen Ihr Vorhaben gerne unverbindlich.
Weiterführende Beiträge
Wenn dieses Thema für Ihre Roadmap relevant ist, sind diese Beiträge der nächste sinnvolle Schritt: