Microservices-Architektur — wann ist sie sinnvoll und wann bleibt ein Monolith besser?

Monolith und Microservices: der Unterschied

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 — meist REST-APIs, GraphQL oder Message Queues.

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.

Echte Vorteile von Microservices

Microservices haben reale Vorteile — aber nur, wenn die Voraussetzungen stimmen:

• Unabhängiges Deployment: Teams können ihren Service ausliefern, ohne auf andere zu warten. Das beschleunigt Release-Zyklen und macht Änderungen kleiner und isolierter.
• Selektive Skalierbarkeit: Steht nur ein Teilbereich unter hoher Last, lässt sich genau dieser Service skalieren, statt die gesamte Anwendung mit mehr Ressourcen zu versorgen.
• Technologie-Diversität: Verschiedene Services können in unterschiedlichen Programmiersprachen umgesetzt werden — je nach Aufgabe das passende Werkzeug.
• Team-Autonomie: Kleine, autonome Teams mit klarer Service-Ownership entscheiden, experimentieren und liefern schneller.

Microservices lösen organisatorische Probleme allerdings nicht — sie verstärken sie. Funktioniert die Teamkommunikation im Monolith schlecht, wird sie mit zehn Services nicht besser, sondern deutlich schlechter.

Die unterschätzten Nachteile

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 entsprechend höheren Betriebsaufwand gegenüber einem Monolith.

Verteilte Transaktionen sind ein grundlegendes Problem: In einem Monolith ist eine Datenbanktransaktion atomar. Berührt eine Bestellung dagegen drei verschiedene Services (Bestand prüfen, Zahlung verarbeiten, Bestätigung senden), muss Konsistenz über Patterns wie Saga oder Two-Phase Commit hergestellt werden — 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. Und Observability — also das Verstehen, was im System gerade passiert — erfordert bei Microservices spezialisierte Werkzeuge wie Distributed Tracing, zentrale Log-Aggregation und Metrics/Alerting, die vor dem ersten produktiven Service aufgebaut sein müssen.

Entscheidungskriterien: Microservices oder Monolith?

1. Teamgröße unter 10 Entwicklern spricht für einen Monolith: Microservices skalieren mit Teams, nicht mit Traffic. Für kleine Teams überwiegt der Betriebsaufwand für verteilte Services den Nutzen deutlich. 2. Frühe Produktphase spricht für einen Monolith: Wenn sich Anforderungen schnell ändern, ist ein Interface-Refactoring im Monolith eine Sache von Stunden — im Microservices-System bedeutet dieselbe Änderung koordinierte Anpassungen in mehreren Services. 3. Skalierungsanforderungen differenziert betrachten: Haben einzelne Systemteile stark unterschiedliche Lastprofile (etwa ein Echtzeit-Chat neben einem Reporting-Modul), können Microservices selektive Skalierung ermöglichen. Skaliert die Anwendung gleichmäßig, bringt das keinen zusätzlichen Nutzen. 4. Klare Domänengrenzen als Voraussetzung: Microservices funktionieren nur, wenn die fachlichen Grenzen zwischen Services klar definiert sind (Domain-Driven Design, Bounded Contexts). Bei unklaren Grenzen entstehen eng gekoppelte Services, die alle Nachteile ohne die Vorteile mitbringen — der sogenannte „Distributed Monolith". 5. Vorhandene Betriebskapazität: Microservices ohne Container-Orchestrierung sind kaum betreibbar. Fehlt das Kubernetes-Know-how intern, müssen externe Spezialisten oder Managed Services hinzugezogen werden — das erhöht die laufenden Kosten spürbar.

Der Modulith ist der oft unterschätzte Kompromiss: eine Monolith-Anwendung mit klar definierten, technisch getrennten Modulen, die nur über definierte Interfaces kommunizieren und später bei Bedarf in eigenständige Services ausgelagert werden können — ohne die sofortige Betriebskomplexität von Microservices.

Migration ohne Big-Bang-Rewrite

Wer von einem Monolith zu Microservices migrieren möchte, sollte das Strangler-Fig-Pattern anwenden: Neue Funktionen werden direkt als eigenständige Services implementiert, während bestehende Monolith-Teile schrittweise ersetzt werden. So entsteht kein riskanter Big-Bang-Rewrite, und die Anwendung bleibt während der Migration produktiv.

Event-driven Architecture ergänzt Microservices dabei sinnvoll: Statt direkter Service-zu-Service-Kommunikation per REST senden Services Ereignisse an eine Message Queue (etwa Apache Kafka oder RabbitMQ), andere Services abonnieren diese Events und reagieren asynchron. Das reduziert direkte Kopplung und erhöht die Ausfalltoleranz. Container mit Docker und Orchestrierung mit Kubernetes sind die operative Grundlage — Managed-Kubernetes-Dienste reduzieren den Betriebsaufwand, eliminieren ihn aber nicht.