Die Rückkehr der Monolithen? – Eine differenzierte Betrachtung der deutschen Architektur-Debatte

Der Amazon-Fall: Ein Einzelbeispiel mit begrenzter Aussagekraft

Der viel­zi­tierte Fall von Amazon Prime Video, bei dem ein Team durch Konsolidierung einer server­less-Architektur zu einem Monolithen 90% Kosten einsparte, ist zwei­fel­los beein­dru­ckend. Doch Vorsicht vor vorschnel­len Verallgemeinerungen: Es handelt sich um eine sehr spezi­fi­sche Optimierung eines Video-Monitoring-Systems, das unter beson­de­ren Lastanforderungen litt.

Was oft über­se­hen wird: Tausende andere Teams bei Amazon setzen weiter­hin erfolg­reich auf Microservices. Der Fall zeigt eher, dass dogma­ti­sche Architekturentscheidungen – egal in welche Richtung – proble­ma­tisch sind. »Die rich­tige Architektur hängt vom Kontext ab«, betont Golo Roden von der native web GmbH, und trifft damit den Kern: Es gibt keine Einheitslösung.

Die deutsche Realität: Zwischen Erfolg und Ernüchterung

Die Datenlage zur Microservices-Adoption in Deutschland ist ambi­va­lent. Während die Capgemini Digital Architecture Study 2024 zeigt, dass 74% der Unternehmen mit föde­ra­len Governance-Strukturen zufrie­den sind, offen­bart die QAware Cloud Native Studie, dass nur 58% signi­fi­kante Vorteile durch Cloud-Native-Technologien sehen.

Aber: Diese Zahlen müssen diffe­ren­ziert betrach­tet werden. In Branchen wie FinTech und E‑Commerce berich­ten viele Unternehmen von erfolg­rei­chen Microservices-Implementierungen. Die LeanIX-Studie zeigt weiter­hin, dass 71% der befrag­ten Unternehmen ihre Microservices-Nutzung ausbauen wollen – aller­dings mit einem reife­ren, selek­ti­ve­ren Ansatz als noch vor Jahren.

Die Wahrheit ist: Beide Architekturen haben ihre Berechtigung, und der Erfolg hängt mehr von der Implementierungsqualität als vom gewähl­ten Paradigma ab.

Modulare Monolithen: Ein pragmatischer Mittelweg

Die in der Branche disku­tier­ten Kosteneinsparungen durch modu­lare Monolithen vari­ie­ren stark und sind hoch­gra­dig kontext­ab­hän­gig. Statt pauscha­ler Prozentangaben ist eine diffe­ren­zierte Betrachtung notwen­dig:

• Kurzfristig können Monolithen güns­ti­ger sein (weni­ger Infrastruktur, einfa­che­res Deployment)
• Langfristig können Microservices bei wach­sen­den Teams und sich ändern­den Anforderungen flexi­bler sein
• Total Cost of Ownership (TCO) muss Faktoren wie Time-to-Market, Skalierbarkeit und Wartbarkeit einbe­zie­hen

Spring Modulith und ähnli­che Frameworks bieten einen evolu­tio­nä­ren Pfad: Start als Monolith, schritt­weise Extraktion wo sinn­voll. Dieser Ansatz ist weni­ger eine »deut­sche Eigenart« als viel­mehr eine prag­ma­ti­sche Reaktion auf struk­tu­relle Herausforderungen wie Fachkräftemangel und begrenzte Ressourcen.

Die »10-Entwickler-Regel«: Heuristik, nicht Gesetz

Die häufig zitierte Schwelle von »10 Entwicklern für Microservices« ist eine grobe Faustregel, kein empi­risch fundier­tes Gesetz. Die Realität ist nuan­cier­ter:

• Kleine Teams (< 5) profi­tie­ren selten von der Komplexität verteil­ter Systeme
• Mittlere Teams (5–15) müssen Kosten und Nutzen sorg­fäl­tig abwä­gen
• Große Teams (> 15) können von klaren Service-Grenzen profi­tie­ren – wenn die Organisation stimmt

Entscheidender als die Teamgröße sind Faktoren wie:

• Technische Kompetenz im Umgang mit verteil­ten Systemen
• Qualität der DevOps-Praktiken und des Toolings
• Klarheit der fach­li­chen Domänengrenzen
• Anforderungen an unab­hän­gige Skalierbarkeit und Deployment

Deutsche Unternehmen im Spannungsfeld

Developer Experience: Das eigentliche Problem

Die Stack Overflow Umfrage 2024 iden­ti­fi­ziert tech­ni­sche Schulden als Hauptfrustration für 62,4% der Entwickler.
Aber: Diese Schulden entste­hen nicht durch Microservices per se, sondern durch:

• Unklare Architekturentscheidungen ohne Kontext
• Mangelnde Investition in Developer Tooling
• Fehlende Kompetenzen im Umgang mit verteil­ten Systemen
• Übereilte Technologieentscheidungen ohne Migrationsplan

»If you can’t build a well-struc­tu­red mono­lith, what makes you think you can build well-struc­tu­red micro­ser­vices?« – Diese provo­kante Frage eines Delivery Hero Teamleiters trifft den Punkt: Architekturkompetenz ist wich­ti­ger als das gewählte Paradigma.

2025: Die Post-Dogma-Ära

Die Zukunft gehört weder Monolithen noch Microservices, sondern anwen­dungs­fall­ba­sier­ten Architekturen. Internationale Trends zeigen:

Selektive Service-Extraktion wird Standard

Unternehmen welt­weit extra­hie­ren nur noch Services, die klaren Geschäftswert durch Isolation bieten. Der »Microservices-first«-Ansatz weicht einem »Monolith-first, Extract-when-needed«-Paradigma.

Platform Engineering als Enabler

Die Komplexität von Microservices wird durch bessere Plattformen abstra­hiert. Internal Developer Platforms (IDPs) wie Backstage (Spotify), Humanitec oder Port machen verteilte Systeme hand­hab­ba­rer, indem sie Self-Service-Portale für Entwickler bereit­stel­len. Diese Tools stan­dar­di­sie­ren Deployment-Prozesse, auto­ma­ti­sie­ren Infrastruktur-Provisionierung und redu­zie­ren kogni­tive Last – erfor­dern aber erheb­li­che Vorabinvestitionen.

AI-gestützte Architekturentscheidungen

KI-Tools helfen bei der Identifikation opti­ma­ler Service-Grenzen und warnen vor Overengineering. Die Entscheidung bleibt mensch­lich, wird aber daten­ge­stützt.

Entscheidungsmatrix statt Dogma

Für deut­sche Unternehmen empfiehlt sich folgende Entscheidungsheuristik:

Das ungelöste Dilemma

Die Architektur-Debatte spie­gelt tiefere Zielkonflikte wider:

• Produktivität vs. Skalierbarkeit: Monolithen ermög­li­chen schnel­lere Entwicklung, Microservices bessere Skalierung
• Einfachheit vs. Flexibilität: Simple Architekturen sind wart­ba­rer, verteilte flexi­bler
• Stabilität vs. Innovation: Bewährte Ansätze sind siche­rer, neue verspre­chen Wettbewerbsvorteile

Diese Konflikte lassen sich nicht auflö­sen – sie müssen für jeden spezi­fi­schen Anwendungsfall neu ausba­lan­ciert werden.

Fazit: Reife statt Revolution

Die »Rückkehr zu Monolithen« ist keine Kehrtwende, sondern Zeichen einer reifen­den Industrie. Nach Jahren dogma­ti­scher Debatten setzt sich die Erkenntnis durch: Es gibt keine univer­sell beste Architektur.

Deutsche Unternehmen stehen vor der Herausforderung, zwischen Legacy-Last und Innovationsdruck zu navi­gie­ren. Die Lösung liegt nicht in neuen Paradigmen, sondern in:

• Situationsgerechten Entscheidungen statt Architektur-Dogmen
• Evolutionären Ansätzen statt Big-Bang-Migrationen
• Investitionen in Architekturkompetenz statt über­mä­ßi­ges Vertrauen auf Tooling
• Ehrlicher Evaluation der eige­nen Capabilities

Die Zukunft gehört Teams, die kontext­sen­si­bel entschei­den, konti­nu­ier­lich dazu­ler­nen und Architekturen als evol­vie­rende Systeme verste­hen – nicht als einma­lige Weichenstellungen.

Was wie eine Rückkehr zu Monolithen wirkt, ist in Wahrheit ein Fortschritt zu reife­rem Architekturdenken

Quellenangaben

1. Return of the Monolith: Amazon Dumps Microservices for Video Monitorin: https://thenewstack.io/return-of-the-monolith-amazon-dumps-microservices-for-video-monitoring/
2. Capgemini Invent, “Digital Architecture Study 2024”: https://www.capgemini.com/de-de/wp-content/uploads/sites/8/2024/11/Digital-Architecture-Study-2024_vF.pdf
3. QAware Cloud Native Studie: https://www.qaware.de/studien/cloud-native-studie-2024/
4. Stack Overflow Developer Survey 2024: https://survey.stackoverflow.co/2024/professional-developers#2‑most-common-frustrations
5. Atlassian State of DevEx Study: https://www.atlassian.com/blog/developer/developer-experience-report-2025
6. Computerwoche- Bericht über LeanIX-Studie: https://www.computerwoche.de/article/2752455/microservices-machen-die-it-schneller-und-agiler.html
7. N26: https://medium.com/insiden26/engineering-at-n26-a-tour-of-our-tech-stack-and-architecture-9e58ce96f889
8. Telekom Access 4.0: https://www.reply.com/de/telco-and-media/access‑4–0