Reboot Germany

Microservices vs. Monolith: Wann sich der Umbau lohnt

42 Prozent konsolidieren Microservices zurück. Amazon spart 90 Prozent. Wann welche Architektur passt und warum der modulare Monolith 2026 die Antwort für den Mittelstand ist.

Von Benedikt Langer 31. März 2026 6 Minuten Lesezeit

Microservices vs. Monolith: Wann sich der Umbau lohnt

42 Prozent der Unternehmen, die Microservices eingeführt haben, konsolidieren Services wieder in größere Einheiten. Amazon Prime Video sparte 90 Prozent der Infrastrukturkosten durch die Rückkehr zum Monolithen. Service-Mesh-Adoption fiel von 18 auf 8 Prozent in zwei Jahren. Microservices sind nicht gescheitert. Aber die pauschale Empfehlung, alles in Microservices aufzubrechen, schon. 2026 ist das Jahr der differenzierten Entscheidung: Monolith, modularer Monolith oder Microservices – abhängig von Teamgröße, Skalierungsbedarf und operativer Reife.

Das Wichtigste in Kürze

42 Prozent konsolidieren zurück: Laut CNCF-Survey 2025 haben 42 Prozent der Microservices-Anwender Services wieder zusammengelegt. Hauptgründe: Debugging-Komplexität, operativer Overhead und Netzwerklatenz.
Amazon Prime Video: 90 Prozent Kosteneinsparung durch Migration von verteilten Microservices zu einem Single-Process-Monolithen für den Video-Quality-Analysis-Service.
3,75x bis 6x höhere Infrastrukturkosten für Microservices gegenüber Monolithen bei äquivalenter Funktionalität. Enterprise-Monolith: circa 15.000 Euro monatlich vs. Microservices: 40.000 bis 65.000 Euro.
Der modulare Monolith als Mittelweg: Module kommunizieren über definierte Interfaces, nutzen separate DB-Schemas und können bei Bedarf zu Services extrahiert werden. Architektonische Strenge ohne operativen Overhead.
Entscheidungsregel: Unter 100 Entwickler = modularer Monolith. Über 100 Entwickler mit unabhängigen Skalierungsbedürfnissen = Microservices. Unter 10 = klassischer Monolith.

Die Microservices-Ernüchterung: Was die Daten zeigen

Die Microservices-Welle der 2010er Jahre basierte auf einem einfachen Versprechen: Teile deine Anwendung in kleine, unabhängige Services auf und gewinne Geschwindigkeit, Skalierbarkeit und Teamautonomie. Netflix, Amazon und Google machten es vor. Tausende Unternehmen folgten.

Zehn Jahre später zeigt sich: Das Versprechen gilt, aber nur unter bestimmten Bedingungen. Die CNCF-Befragung 2025 dokumentiert die Gegenbewegung: 42 Prozent der Organisationen, die Microservices adoptiert haben, konsolidieren Services wieder. Nicht zurück zum Monolithen der 2000er Jahre, aber zu größeren, besser abgegrenzten Deployment-Einheiten.

Die Symptome, die zur Konsolidierung führen: Debugging über Service-Grenzen hinweg ist exponentiell schwieriger als innerhalb eines Prozesses. Jeder Netzwerk-Call zwischen Services ist ein potenzieller Fehlerpunkt. Und der operative Overhead von dutzenden oder hunderten Services erfordert ein Platform-Engineering-Team, das viele Mittelständler nicht haben.

CNCF Survey 2025

42 %

der Microservices-Anwender konsolidieren Services zurück

Quelle: CNCF Cloud Native Survey, 2025

Amazon Prime Video: Die Case Study die alles veränderte

Im Mai 2023 veröffentlichte das Amazon Prime Video Team eine Architekturanalyse, die die Cloud-Community erschütterte. Der Video-Quality-Analysis-Service war als verteilte Microservices-Architektur mit AWS Step Functions und Lambda aufgebaut. Die Kosten waren prohibitiv, die Skalierung limitiert.

Die Lösung: Migration zu einem Single-Process-Monolithen. Das Ergebnis: 90 Prozent Infrastrukturkostenreduktion und bessere Skalierungsfähigkeit. Der Grund: Der Service hatte keinen echten Bedarf für unabhängige Skalierung einzelner Komponenten. Alle Teile verarbeiteten denselben Video-Stream. Die Microservices-Architektur erzeugte Netzwerk-Overhead und Orchestrierungskomplexität ohne Mehrwert.

Die Lektion ist nicht, dass Microservices schlecht sind. Die Lektion ist: Microservices lösen ein spezifisches Problem (unabhängige Skalierung und Deployment durch autonome Teams). Wenn dieses Problem nicht existiert, erzeugen sie nur Kosten.

Die Kostenwahrheit: Monolith vs. Microservices

Die Zahlen sind eindeutig. Microservices-Infrastrukturen kosten 3,75x bis 6x mehr als äquivalente Monolithen. Bei Enterprise-Skala bedeutet das: ein Monolith bei circa 15.000 Euro monatlich, eine äquivalente Microservices-Architektur bei 40.000 bis 65.000 Euro, wenn Infrastruktur, Operations, Platform-Teams und Koordinationsoverhead eingerechnet werden.

Der Personalaufwand potenziert die Differenz. Ein modularer Monolith braucht 1 bis 2 Operations-Ingenieure. Eine äquivalente Microservices-Architektur braucht 2 bis 4 Platform Engineers plus zusätzlichen operativen Aufwand, der auf Produktteams verteilt wird. Bei Jahresgehältern von 140.000 bis 180.000 Euro für Platform Engineers (DevOps Salary Reports 2025) sind die Personalkosten der Differenz größer als die Infrastrukturkosten.

Für DACH-Unternehmen mit 10 bis 50 Entwicklern ist die Rechnung klar: Ein modularer Monolith liefert 90 Prozent der architektonischen Vorteile zu einem Bruchteil der Kosten. Microservices lohnen sich erst, wenn Conway’s Law die Architektur erzwingt: wenn die Organisationsstruktur so groß und fragmentiert ist, dass Teams unabhängig deployen müssen.

// O-Ton

90 Prozent der Microservices-Architekturen werden immer noch wie Monolithen deployed. Die Organisationen haben die Services aufgeteilt, aber nicht die Deployment-Pipeline.

The New Stack · Why 90% of Microservices Still Ship Like Monoliths, 2025

Der modulare Monolith: Die pragmatische Antwort

Der modulare Monolith ist kein Kompromiss. Er ist eine eigenständige Architekturentscheidung. In einem gut designten modularen Monolithen kommunizieren Module über definierte Interfaces, nutzen separate Datenbank-Schemas innerhalb derselben Datenbank und können bei Bedarf zu eigenständigen Services extrahiert werden.

Der Schlüssel ist das „bei Bedarf“. Statt prophylaktisch alles in Services aufzubrechen (und den Overhead sofort zu zahlen), baut der modulare Monolith die Modulgrenzen ein, ohne den Netzwerk-Overhead und die Deployment-Komplexität zu erzeugen. Wenn ein Modul tatsächlich unabhängig skaliert werden muss, kann es extrahiert werden. Wenn nicht, bleibt es im Monolithen.

Eine systematische Literaturübersicht in der ACM-Konferenz zu Software Architecture Trends (2024) bestätigt: Der modulare Monolith ist keine Nische mehr, sondern eine anerkannte Architektur zwischen klassischem Monolith und verteilten Microservices. Die Kombination aus operativer Einfachheit, Modularität und Wartbarkeit trifft genau den Sweet Spot für Unternehmen mit 10 bis 100 Entwicklern.

Die Entscheidungsmatrix: Wann welche Architektur

Klassischer Monolith: Unter 10 Entwickler. MVP, Prototyp oder erste Produktversion. Geschwindigkeit vor Architektur. Der schnellste Weg zum Product-Market-Fit. Refactoring kommt später, wenn klar ist, was funktioniert.

Modularer Monolith: 10 bis 100 Entwickler. Tausende bis Millionen Nutzer (nicht Milliarden). Weniger als 5 Platform Engineers. Priorität: Kosteneffizienz und Entwicklungsgeschwindigkeit. Die Architektur der Wahl für den DACH-Mittelstand.

Microservices: Über 100 Entwickler mit Conway’s-Law-Problemen. Unabhängige Skalierung genuinely benötigt (Payment-Service braucht 50x Compute vs. andere Services). Polyglot-Anforderungen (ML in Python, Core in Java). Regulatorische Isolation erzwingt physische Trennung (PCI-Compliance für Payment-Processing).

Die häufigste Fehlentscheidung: Unternehmen mit 20 Entwicklern, die Microservices einführen, weil Netflix es tut. Netflix hat 10.000 Entwickler. Die organisatorische Komplexität, die Microservices lösen, existiert bei 20 Entwicklern nicht. Das Ergebnis: Distributed-Monolith. Alle Nachteile beider Welten, keine Vorteile.

Fazit

Die Microservices-vs-Monolith-Debatte ist 2026 keine ideologische Frage mehr. Es ist eine pragmatische Entscheidung basierend auf Teamgröße, Skalierungsbedarf und operativer Reife. 42 Prozent konsolidieren zurück. Amazon spart 90 Prozent mit einem Monolithen. Die Kosten für Microservices liegen 3,75x bis 6x über Monolithen. Der modulare Monolith ist für den DACH-Mittelstand die richtige Architektur in 90 Prozent der Fälle: architektonische Strenge ohne den operativen Overhead verteilter Systeme. Die Frage ist nicht Monolith oder Microservices. Die Frage ist: Welches Problem löst die Architektur konkret? Wenn die Antwort „Team-Autonomie bei 200 Entwicklern“ ist, sind Microservices richtig. Wenn die Antwort „wir wollen modern sein“ ist, wird es teuer.

Häufige Fragen

Sind Microservices gescheitert?

Nein. Microservices lösen ein reales Problem: unabhängige Skalierung und Deployment bei großen, autonomen Teams. Was gescheitert ist, ist die pauschale Empfehlung, jede Anwendung in Microservices aufzubrechen. 42 Prozent konsolidieren, weil sie erkannt haben, dass der Overhead die Vorteile überwiegt, wenn das Problem gar nicht existiert.

Was ist ein Distributed Monolith?

Eine Architektur, die wie Microservices aussieht (viele Services, Netzwerk-Kommunikation), aber wie ein Monolith funktioniert: Alle Services müssen zusammen deployed werden, teilen sich Daten und können nicht unabhängig skaliert werden. Das ist das worst-case-Ergebnis einer schlecht geplanten Microservices-Migration: mehr Komplexität ohne die versprochene Autonomie.

Wie erkenne ich, dass mein Monolith zu groß wird?

Drei Warnsignale: Erstens, Deployment-Konflikte – Teams blockieren sich gegenseitig bei Releases. Zweitens, Build-Zeiten über 15 Minuten. Drittens, eine Änderung in Modul A bricht Tests in Modul B, obwohl die Module eigentlich unabhängig sein sollten. Das sind Signale für fehlende Modulgrenzen, nicht zwingend für den Wechsel zu Microservices.

Wie migriert man von Microservices zum modularen Monolithen?

Schrittweise, nicht Big Bang. Identifiziere Services, die immer zusammen deployed werden und keine unabhängige Skalierung brauchen. Diese werden als Module in eine gemeinsame Codebasis zusammengeführt. Die Kommunikation wechselt von HTTP/gRPC zu In-Process-Aufrufen. Datenbanken werden konsolidiert, aber mit getrennten Schemas. Pro Quartal drei bis fünf Services konsolidieren.

Welche Sprache eignet sich am besten für einen modularen Monolithen?

Java (mit Spring Modulith), .NET (mit Domain-Driven Design Patterns) und Go (mit klarer Package-Struktur) haben die beste Tool-Unterstützung. Spring Modulith bietet seit 2024 explizite Modul-Boundary-Checks und Event-basierte Inter-Modul-Kommunikation. In .NET ist Vertical Slice Architecture der bevorzugte Ansatz. Node.js/TypeScript ist möglich, aber die Modul-Isolation erfordert mehr Disziplin.