Microservices
Microservices sind ein Architekturstil, bei dem eine Anwendung aus vielen kleinen, fachlich geschnittenen Diensten besteht. Jeder Dienst wird unabhängig entwickelt, deployt und skaliert und kommuniziert mit den anderen über definierte Schnittstellen. Microservices erhöhen Flexibilität und Skalierbarkeit — um den Preis deutlich höherer Betriebskomplexität.
Merkmale einer Microservices-Architektur
- Fachlicher Schnitt: Die Dienste folgen Geschäftsdomänen — im Sinne von Domain-Driven Design (DDD) und Bounded Contexts —, nicht technischen Schichten.
- Eigene Datenhaltung: Jeder Dienst besitzt seine Daten; andere Dienste greifen nur über Schnittstellen zu.
- Unabhängiges Deployment: Jeder Dienst ist einzeln releasbar — typischerweise als Container (Docker) auf einer Orchestrierungsplattform (Kubernetes) mit automatisierten CI/CD-Pipelines.
- Kommunikation über APIs und Events: synchron per REST oder gRPC, asynchron über Event-Streams (etwa Kafka).
- Teamautonomie: Kleine Teams verantworten ihre Dienste end-to-end — von der Entwicklung bis zum Betrieb.
Microservices vs. Monolith: die ehrlichen Trade-offs
| Kriterium | Monolith | Microservices |
|---|---|---|
| Deployment | ein Artefakt — jede Änderung ist ein Gesamtrelease | Dienste einzeln releasbar, kurze Release-Zyklen |
| Skalierung | nur als Ganzes | gezielt je Dienst, nach tatsächlicher Last |
| Teamorganisation | Koordination am gemeinsamen Code nötig | autonome Teams mit klaren Dienstgrenzen |
| Konsistenz & Transaktionen | einfach — eine Datenbank, lokale Transaktionen | verteilte Daten, Eventual Consistency, aufwendige Fehlerbehandlung |
| Betrieb & Debugging | überschaubar | verteiltes System: Observability, Netzwerklatenz, neue Ausfallmuster |
| Einstiegskosten | niedrig | hoch — Container-Plattform, Automatisierung und Monitoring sind Voraussetzung |
Die Tabelle zeigt: Microservices tauschen Entwicklungs- und Skalierungsflexibilität gegen Betriebskomplexität. Wer die nötige Infrastruktur nicht hat oder nicht aufbauen will, holt sich die Nachteile ohne die Vorteile.
Microservices in der Legacy-Modernisierung
Ein häufiger Anwendungsfall ist die schrittweise Entflechtung gewachsener Monolithen — etwa aus veraltetem Java EE (EJB), C++ oder .NET Framework — in cloud-native Architekturen. Bewährt hat sich das Strangler-Fig-Pattern: Das neue System wächst um das alte herum und löst es Funktion für Funktion ab, ohne riskanten Big Bang; bereits migrierte Dienste liefern sofort Nutzen.
Der wichtigste Fallstrick dabei ist der falsche Schnitt: Wer den Monolithen entlang technischer statt fachlicher Grenzen zerlegt, erhält einen verteilten Monolithen — getrennt deployte, aber eng gekoppelte Dienste, bei denen jede Änderung mehrere Dienste betrifft. Der Domänenschnitt ist deshalb die eigentliche Architekturarbeit, nicht die Technik.
Microservices in der Praxis: wann der Monolith die bessere Wahl ist
Microservices lohnen sich, wenn einzelne Funktionen unabhängig skalieren müssen, viele Teams parallel arbeiten oder unterschiedliche Release-Zyklen den Mehraufwand rechtfertigen. Für kleine Teams und überschaubare Domänen ist ein gut strukturierter, modularer Monolith oft die wirtschaftlichere Wahl — und mit sauber gezogenen Modulgrenzen bleibt die spätere Zerlegung möglich. Die richtige Frage ist erfahrungsgemäß nicht „Monolith oder Microservices?“, sondern: Wo verlaufen die fachlichen Grenzen — und welche davon brauchen wirklich unabhängige Deployments?