Wann keine Microservices?
Microservices sind kein Reifegrad.
Sie sind eine Organisations- und Skalierungsstrategie.
Nicht jedes Problem braucht verteilte Systeme.
Die entscheidende Frage ist:
Übersteigt der Autonomiegewinn die zusätzliche Systemkomplexität?
Typische Situationen, in denen Microservices ungeeignet sind
1️⃣ Kleines Team mit engem Time-to-Market
- 1–3 Entwickler
- Schnelle Iteration wichtiger als Skalierung
- Hohe Änderungsfrequenz im Code
Verteilte Architektur erhöht hier unnötig:
- Deployments
- Infrastrukturaufwand
- Testkomplexität
2️⃣ Domäne noch instabil
Wenn:
- Fachmodell sich stark ändert
- Boundaries noch unklar sind
- Geschäftslogik häufig neu geschnitten wird
Dann führen früh definierte Service-Grenzen zu:
- künstlicher Fragmentierung
- späterem Merge-Aufwand
- unnötiger Komplexität
Erst Domänenstabilität, dann Verteilung.
3️⃣ Geringe Last, geringe organisatorische Komplexität
Wenn:
- keine differenzierte Skalierung nötig ist
- keine mehreren autonomen Teams existieren
- Infrastruktur einfach bleibt
Dann erzeugen Microservices mehr Overhead als Nutzen.
4️⃣ Fehlende Plattform- und Betriebsreife
Microservices erfordern:
- CI/CD-Reife
- Observability
- Resilienz-Standards
- Incident-Prozesse
- On-Call-Strukturen
Ohne diese Grundlagen wird Verteilung zur operativen Last.
No-Go-Signale
Wenn mehrere dieser Punkte zutreffen, ist Vorsicht geboten:
- Kein Monitoring/Tracing
- Kein durchgängiges Logging
- Kein On-Call
- Unklare Teamverantwortungen
- Kein Budget für Plattformarbeit
- Keine Erfahrung mit verteilten Systemen
- E2E-Tests als einzige Absicherung
Microservices ohne Betriebsreife sind riskant.
Bessere Alternative: Modularer Monolith
Ein modularer Monolith bietet:
- Klare Modulgrenzen
- Gemeinsame Codebasis
- Einfaches Debugging
- Geringere Infrastrukturkosten
- Spätere Extraktion einzelner Module möglich
Ein gut geschnittener Monolith ist kein Rückschritt.
Er ist oft die strategisch klügere Startarchitektur.
Evolutionsgedanke
Architektur ist kein Dogma, sondern ein Evolutionspfad.
Ein häufiger, gesunder Weg:
- Modularer Monolith
- Stabilisierung der Domänen
- Extraktion einzelner Services bei Bedarf
- Plattformisierung
Nicht:
„Wir starten direkt mit 20 Services.“
Fazit
Microservices sind sinnvoll, wenn:
- Organisation und Architektur zueinander passen
- Autonomie ein echter Hebel ist
- Plattform und Betrieb mitwachsen können
In allen anderen Fällen gilt:
Komplexität zuerst reduzieren,
nicht verteilen.