Microservices-Architektur: Wann sie sinnvoll ist – und wann ein Monolith besser bleibt

Eine monolithische Anwendung ist ein einzelnes, zusammenhängendes System. Alle Komponenten – Benutzerauthentifizierung, Bestellverwaltung, Produktkatalog, Benachrichtigungen – laufen in einem einzigen Prozess und teilen sich eine Codebasis sowie eine Datenbank. Das klingt nach einem Nachteil, ist aber in vielen Situationen die einfachste und zuverlässigste Lösung.

Microservices teilen diese Funktionen in eigenständige, unabhängige Dienste auf. Jeder Service hat seine eigene Codebasis, seine eigene Datenbank und kommuniziert mit anderen Services ausschließlich über Netzwerk-Schnittstellen – in der Regel REST-APIs, GraphQL oder Message Queues. Ein Service für Benutzer, ein Service für Bestellungen, ein Service für Benachrichtigungen – alle unabhängig deploybar und skalierbar.

Der entscheidende Unterschied liegt nicht in der Technologie, sondern in der organisatorischen und operativen Komplexität. Ein Monolith kann in einer Zeile gestartet werden. Ein Microservices-System benötigt Container-Orchestrierung, Service Discovery, verteiltes Tracing, zentrales Logging, Circuit Breaker, API Gateways und ein Team, das all das betreiben kann.

Microservices haben echte Vorteile – aber nur, wenn die Voraussetzungen stimmen. Der erste Vorteil ist unabhängiges Deployment: Teams können ihren Service deployen, ohne auf andere warten zu müssen. Das beschleunigt Release-Zyklen erheblich und reduziert Deploymentrisiken, weil Änderungen kleiner und isolierter sind.

Der zweite Vorteil ist selektive Skalierbarkeit: Wenn nur der Bezahlprozess unter hoher Last steht, kann genau dieser Service skaliert werden – ohne die gesamte Anwendung auf mehr Ressourcen zu verteilen. Das spart Infrastrukturkosten bei gezielten Lastspitzen.

Der dritte Vorteil ist Technologie-Diversität: Verschiedene Services können in verschiedenen Programmiersprachen oder Frameworks implementiert werden. Der Produktkatalog in Python für Machine-Learning-Aufgaben, die API in Go für hohe Performance, das Admin-Backend in PHP für schnelle Entwicklung. Teams können das beste Werkzeug für jede Aufgabe wählen.

Der vierte Vorteil ist Team-Autonomie: Kleine, autonome Teams mit klarer Service-Ownership können schneller entscheiden, experimentieren und liefern. Conways Law besagt, dass Systeme die Kommunikationsstrukturen ihrer Organisation abbilden – Microservices sind die technische Entsprechung autonomer Teams.

Die Nachteile von Microservices sind real und werden in Architektur-Diskussionen häufig unterschätzt. Der größte Kostentreiber ist die operative Komplexität. Jeder Service muss einzeln deployed, überwacht, geloggt und gewartet werden. Ein System mit 20 Services erzeugt 20-fachen Betriebsaufwand gegenüber einem Monolith.

Verteilte Transaktionen sind ein grundlegendes Problem. In einem Monolith ist eine Datenbanktransaktion atomar – entweder sie gelingt vollständig oder gar nicht. In einem verteilten System, in dem eine Bestellung drei verschiedene Services berührt (Bestand prüfen, Zahlung verarbeiten, Bestätigung senden), muss Konsistenz durch Patterns wie Saga oder Two-Phase Commit hergestellt werden. Das ist komplex, fehleranfällig und schwer zu debuggen.

Netzwerk-Overhead entsteht bei jeder Service-Kommunikation. Was im Monolith ein einfacher Funktionsaufruf ist, wird zum HTTP-Request mit Latenz, möglichem Timeout und Fehlerbehandlung. Je mehr Services miteinander kommunizieren, desto mehr potenzielle Ausfallpunkte gibt es. Ein Service Mesh wie Istio oder Linkerd managt diese Kommunikation, fügt aber selbst Komplexität hinzu.

Observability – also das Verstehen, was im System gerade passiert – erfordert bei Microservices spezialisierte Werkzeuge. Distributed Tracing mit OpenTelemetry, zentrales Log-Aggregation (ELK Stack, Grafana Loki), Metrics und Alerting (Prometheus, Grafana) – all das muss aufgebaut und gepflegt werden, bevor der erste Service produktiv geht.

Wer von einem Monolith zu Microservices migrieren möchte, sollte das Strangler Fig Pattern anwenden. Das Muster stammt aus dem gleichnamigen Baum, der einen anderen Baum langsam umwächst und schließlich ersetzt: Neue Funktionen werden direkt als eigenständige Services implementiert, während bestehende Monolith-Teile schrittweise durch Services ersetzt werden. So entsteht nie ein Big-Bang-Rewrite, und die Anwendung bleibt während der Migration produktiv.

Event-driven Architecture ergänzt Microservices natürlich: Statt direkter Service-zu-Service-Kommunikation per REST senden Services Ereignisse (Events) an eine Message Queue – Apache Kafka und RabbitMQ sind die häufigsten Systeme. Andere Services abonnieren diese Events und reagieren asynchron. Das reduziert direkte Kopplung, erhöht die Ausfalltoleranz und ermöglicht temporale Entkopplung: Ein Service kann Events verarbeiten, wenn er wieder verfügbar ist.

Container und Kubernetes sind die operative Grundlage moderner Microservices. Docker containerisiert jeden Service mit seinen Abhängigkeiten. Kubernetes orchestriert die Container: Es kümmert sich um Deployment, Scaling, Self-Healing und Service Discovery. Wichtig zu verstehen: Kubernetes ist selbst ein hochkomplexes System. Managed Kubernetes-Dienste wie AWS EKS, Google GKE oder Azure AKS reduzieren den Betriebsaufwand, eliminieren ihn aber nicht.