Die Microservices-Falle
Microservices sind seit Jahren der Architektur-Trend schlechthin. Und ja — für die richtige Problemstellung sind sie hervorragend. Aber die Realität zeigt: Viele Teams führen Microservices ein, ohne die Voraussetzungen dafür zu haben.
Das Ergebnis ist kein verteiltes System — sondern ein verteilter Monolith: alle Nachteile beider Welten, keine der Vorteile.
Wann Microservices Sinn machen
Microservices lösen organisatorische Probleme, nicht primär technische:
- Mehrere Teams arbeiten unabhängig an verschiedenen Geschäftsbereichen
- Unterschiedliche Release-Zyklen pro Domäne sind notwendig
- Unterschiedliche Skalierungsanforderungen pro Service
- Technologievielfalt ist gewünscht (ein Service in Java, ein anderer in Python)
Wenn Ihr Team aus 3–5 Entwicklern besteht und eine Anwendung betreut: Microservices sind sehr wahrscheinlich der falsche Ansatz.
Der gut strukturierte Monolith
Ein Monolith ist kein Anti-Pattern. Ein schlecht strukturierter Monolith ist das Problem. Die Lösung ist nicht automatisch eine Microservice-Architektur, sondern oft ein Modularer Monolith:
- Klare Modul-Grenzen mit definierten APIs
- Eigene Datenhaltung pro Modul (kein Shared Database)
- Module können unabhängig getestet werden
- Spätere Extraktion in Services ist möglich, wenn nötig
Das Beste aus beiden Welten
Monolith mit klaren Modulen
┌──────────────────────────────────┐
│ ┌──────────┐ ┌──────────┐ │
│ │ Bestell- │ │ Kunden- │ │
│ │ wesen │ │ verw. │ │
│ │ │ │ │ │
│ └────┬──────┘ └────┬─────┘ │
│ │ definierte │ │
│ │ Schnittstelle│ │
│ ┌────┴──────┐ ┌────┴─────┐ │
│ │ Lager │ │ Billing │ │
│ └───────────┘ └──────────┘ │
│ Ein Deployment │
└──────────────────────────────────┘
Die Kosten von Microservices
Was selten erwähnt wird — Microservices erfordern erhebliche Infrastruktur:
| Thema | Aufwand |
|---|---|
| Service Discovery | Consul, Eureka oder Kubernetes DNS |
| API Gateway | Routing, Rate Limiting, Auth |
| Distributed Tracing | Jaeger, Zipkin oder OpenTelemetry |
| Zentrales Logging | ELK Stack oder CloudWatch |
| CI/CD pro Service | Eigene Pipeline, eigenes Deployment |
| Datenkonsistenz | Saga Pattern, Eventual Consistency |
| Netzwerk-Latenz | Jeder Service-Call ist ein Netzwerk-Call |
Wenn Sie diese Infrastruktur nicht haben oder nicht betreiben können, werden Microservices zum Bremsklotz statt zum Beschleuniger.
Entscheidungshilfe
Starten Sie mit einem Monolith, wenn:
- Ein Team, ein Produkt
- Domäne noch nicht vollständig verstanden
- Schnelle Time-to-Market wichtiger als Skalierbarkeit
Wechseln Sie zu Microservices, wenn:
- Team-Autonomie das Hauptziel ist
- Einzelne Domänen unabhängig skaliert werden müssen
- Sie die Infrastruktur betreiben können (oder wollen)
Fazit
Die beste Architektur ist die, die Ihr Team produktiv macht. Für die meisten mittelständischen Unternehmen ist ein modularer Monolith der pragmatischere Weg — mit der Option, gezielt Services zu extrahieren, wenn der Bedarf entsteht.
Bei CGS IT Solutions beraten wir technologieneutral: Wir empfehlen die Architektur, die zu Ihrer Organisation passt — nicht die, die gerade im Trend liegt. Mehr dazu unter Software Architektur.