Das Ende der Microservices

Microservices versprachen unabhängige Deployments, freie Technologiewahl pro Service und eine Skalierbarkeit, die monolithische Systeme nicht bieten konnten. Für Unternehmen wie Netflix, Amazon und Spotify – mit tausenden Entwicklern und globalen Nutzerzahlen – war diese Architektur eine nachvollziehbare Antwort auf reale Probleme.

Doch die meisten Organisationen sind nicht Netflix. Sie haben Teams von 5 bis 50 Entwicklern, eine überschaubare Domänenkomplexität und keine Notwendigkeit, einzelne Services unabhängig auf Millionen von Requests zu skalieren. Für diese Unternehmen bringen Microservices Kosten mit, die selten in der ursprünglichen Architekturentscheidung eingepreist waren:

• Netzwerkkomplexität: Jeder Aufruf zwischen Services ist ein potenzieller Fehlerfall. Timeouts, Retries, Circuit Breaker und Service Discovery erzeugen eine Infrastrukturschicht, die gewartet und verstanden werden muss
• Verteilte Datenhaltung: Jeder Service besitzt seine eigene Datenbank. Konsistenz über Servicegrenzen hinweg erfordert Patterns wie Saga oder Event Sourcing – beides erheblich komplexer als eine Transaktion in einer gemeinsamen Datenbank
• Debugging und Observability: Ein Fehler, der drei Services durchläuft, ist um Größenordnungen schwerer zu diagnostizieren als ein Stacktrace in einem Monolithen. Distributed Tracing, zentralisiertes Logging und Correlation IDs sind keine optionalen Extras, sondern Voraussetzung
• Deployment-Orchestrierung: 30 unabhängig deploybare Services klingen nach Agilität. In der Praxis bedeuten sie 30 CI/CD-Pipelines, Versionskonflikte zwischen APIs und ein Release-Management, das Koordination erfordert

Die Frage ist nicht, ob Microservices funktionieren. Sie funktionieren – unter bestimmten Voraussetzungen. Die Frage ist, ob die Voraussetzungen in der eigenen Organisation gegeben sind.

Microservices sind keine schlechte Architektur. Sie sind eine Architektur für ein spezifisches Problem: organisatorische Skalierung bei hoher Domänenkomplexität.

Es gibt klare Indikatoren dafür, dass eine Microservice-Architektur gerechtfertigt ist:

Unabhängige Teams mit eigener Verantwortung: Wenn 10 oder mehr Teams parallel an einem Produkt arbeiten und sich gegenseitig nicht blockieren dürfen, schaffen Servicegrenzen die nötige Entkopplung. Conway's Law gilt: Die Architektur spiegelt die Organisationsstruktur.

Unterschiedliche Skalierungsanforderungen: Wenn ein Teilsystem 100.000 Requests pro Sekunde verarbeiten muss, ein anderes aber nur 100, ist eine getrennte Skalierung wirtschaftlich sinnvoll.

Polyglotte Anforderungen: Wenn ein Service von Machine-Learning-Modellen in Python profitiert, ein anderer aber in .NET performanter umgesetzt werden kann, ermöglicht die Servicegrenze diese Freiheit.

Regulatorische Isolation: In manchen Branchen müssen Systeme, die personenbezogene Daten verarbeiten, physisch von anderen Systemen getrennt sein. Microservices bieten hier eine natürliche Grenze.

Wenn keiner dieser Indikatoren zutrifft – und das ist in der Mehrzahl der Fälle so – erzeugen Microservices Komplexität, die keinen Geschäftswert schafft.

Ein modularer Monolith ist kein Rückschritt zum unstrukturierten Big Ball of Mud der 2000er Jahre. Er verbindet die strukturellen Vorteile von Microservices – klare Modulgrenzen, definierte Schnittstellen, getrennte Verantwortlichkeiten – mit der operativen Einfachheit eines einzelnen Deployments.

Die Kernprinzipien:

Bounded Contexts als Module

Jeder fachliche Bereich wird als eigenständiges Modul implementiert – mit eigenen Datenmodellen, eigener Geschäftslogik und einer definierten öffentlichen Schnittstelle. Die Module kommunizieren über In-Process-Aufrufe oder interne Events, nicht über das Netzwerk.

Klare Abhängigkeitsregeln

Modulare Monolithen erzwingen auf Codeebene, dass Module nur über ihre öffentlichen Schnittstellen kommunizieren. Zirkuläre Abhängigkeiten werden durch statische Analyse verhindert. In .NET lässt sich das über separate Projekte und ArchUnit-Tests durchsetzen.

Eine Datenbank, getrennte Schemata

Statt 15 Datenbanken für 15 Services nutzt ein modularer Monolith eine gemeinsame Datenbankinstanz mit getrennten Schemata pro Modul. Transaktionskonsistenz innerhalb eines Moduls ist trivial. Cross-Modul-Konsistenz kann über Domain Events gelöst werden – aber innerhalb desselben Prozesses, ohne Netzwerk-Overhead.

Ein Deployment, ein Betrieb

Eine Anwendung, eine CI/CD-Pipeline, ein Logging-Stack, ein Monitoring-Dashboard. Die operativen Kosten sinken um Größenordnungen. Ein Team von fünf Entwicklern kann einen modularen Monolithen betreiben. Für 15 Microservices bräuchte es ein dediziertes Platform-Team.

Der Rückbau von Microservices ist kein theoretisches Szenario. Führende Technologieunternehmen haben diesen Schritt öffentlich dokumentiert.

Amazon Prime Video veröffentlichte 2023 eine Fallstudie, in der das Team beschrieb, wie es seinen Video-Monitoring-Service von einer Microservice-Architektur zu einem Monolithen konsolidierte. Das Ergebnis: 90 Prozent Kostenreduktion bei der Infrastruktur und eine deutlich einfachere Wartbarkeit. Der Hauptgrund war, dass die Kommunikation zwischen den Services über AWS Step Functions den Grossteil der Kosten und der Latenz verursachte.

Shopify betreibt eines der grössten E-Commerce-Systeme weltweit – als modularen Monolithen in Ruby on Rails. Statt auf Microservices zu setzen, investierte Shopify in strikte Modulgrenzen innerhalb einer einzigen Codebasis. Ihr Open-Source-Werkzeug Packwerk erzwingt die Einhaltung von Modulgrenzen durch statische Analyse.

Basecamp und Hey haben ihre Produkte bewusst als Monolithen konzipiert. David Heinemeier Hansson, CTO von 37signals, argumentiert, dass Microservices für Teams unter 100 Entwicklern nahezu immer eine Fehlentscheidung sind – und dass die Industrie zu lange einer Architektur gefolgt ist, die für die Probleme einer Handvoll Hyperscaler entwickelt wurde.

Diese Beispiele sind keine Einzelfälle. Sie markieren einen Paradigmenwechsel, der sich durch die gesamte Branche zieht.

Der Rückbau einer Microservice-Architektur ist ein Projekt, das Planung und Disziplin erfordert. Ein pragmatischer Ansatz in vier Schritten:

1. Servicelandschaft analysieren Welche Services existieren? Wie kommunizieren sie? Welche sind tatsächlich unabhängig deploybar, welche werden immer gemeinsam released? Die Antworten zeigen, wo die Servicegrenzen realen Wert schaffen und wo sie nur Komplexität erzeugen.

2. Kandidaten identifizieren Services, die immer gemeinsam deployed werden, die synchron voneinander abhängen oder die von demselben Team verantwortet werden, sind Kandidaten für eine Konsolidierung. Der Zusammenschnitt folgt der tatsächlichen Teamstruktur, nicht dem theoretischen Domänenmodell.

3. Schrittweise konsolidieren Die Migration erfolgt Service für Service. Ein Service wird als Modul in den Monolithen integriert, seine API wird zur internen Schnittstelle. Der externe Endpunkt bleibt bestehen, bis alle Konsumenten migriert sind. Parallelbetrieb minimiert das Risiko.

4. Modulgrenzen härten Nach der Konsolidierung werden die Modulgrenzen durch Tests, statische Analyse und Code-Reviews abgesichert. Ohne diese Disziplin entsteht über die Zeit derselbe unstrukturierte Monolith, den man ursprünglich durch Microservices ersetzen wollte.

Entscheidend ist: Die Migration ist kein Rückschritt. Sie ist eine bewusste Architekturentscheidung auf Basis realer Erfahrungen – das Gegenteil von Dogma.

Die Debatte zwischen Microservices und Monolith wird zu oft als Glaubensfrage geführt. Architekturentscheidungen sind aber keine Identitätsfragen – sie sind Trade-off-Analysen.

Eine nüchterne Bewertung berücksichtigt:

• Teamgrösse: Unter 50 Entwicklern ist ein modularer Monolith fast immer die bessere Wahl. Die operativen Kosten von Microservices amortisieren sich erst bei grösseren Organisationen
• Domänenkomplexität: Wenn die Fachdomäne überschaubar ist, erzeugen Servicegrenzen keinen Mehrwert. Wenn sie hochkomplex ist und von unabhängigen Teams bearbeitet wird, können Microservices die richtige Antwort sein
• Time to Market: Ein modularer Monolith ist schneller produktionsreif. Es gibt weniger Infrastruktur aufzusetzen, weniger Integrationen zu testen, weniger Betriebskomplexität zu beherrschen
• Betriebsfähigkeit: Hat die Organisation ein Platform-Team, das Kubernetes, Service Mesh und Distributed Tracing betreiben kann? Wenn nicht, ist eine Microservice-Architektur ein Risiko, das nicht durch die Entwicklungsabteilung allein getragen werden kann

Die beste Architektur ist die, die das Team versteht, betreiben kann und die das Geschäftsproblem löst. Nicht die, die auf der letzten Konferenz den meisten Applaus bekommen hat.

Bei EXPERIOR DIGITAL setzen wir auf modulare .NET-Monolithen mit klaren Bounded Contexts – und behalten uns die Option vor, einzelne Module bei Bedarf in eigenständige Services zu extrahieren. Diese Richtung – vom Monolith zum Service, nicht umgekehrt – ist fast immer risikoärmer und kosteneffizienter.