Monolith ist tot, lang lebe der Monolith – oder doch nicht?

Die Architektur-Diskussion hat sich gedreht. Während du vor ein paar Jahren noch schräg angeschaut wurdest, wenn dein Stack nicht aus hundert Microservices bestand, hinterfragen heute selbst die größten Tech-Player ihre Entscheidungen. Aber bedeutet das wirklich das Aus für Composable und MACH? Spoiler: Es ist komplizierter.

Wenn „Riesen“ ihre Meinung ändern

Plötzlich passiert etwas Unerwartetes. Teams, die ihre Systeme in Microservices zerlegt haben, konsolidieren wieder. Und das sind keine kleinen Startups – es sind Amazon, Shopify, Basecamp, Segment und sogar Google.

Aber halt: Das sind keine Panik-Reaktionen oder blinde Rückwärtsrollen. Es sind durchdachte, situative Entscheidungen für spezifische Probleme.

Amazon Prime Video: 90% gespart durch Konsolidierung

Der Case, der die Runde macht: Amazon Prime Video hat einen mutigen Schritt gewagt und bestimmte kritische Services von Microservices zurück zu einer monolithischen Struktur migriert. Warum? In ihrem konkreten Szenario brachte die verteilte Architektur schlichtweg nicht die erhofften Vorteile.

Das Ergebnis überraschte selbst Skeptiker: Die Infrastrukturkosten sanken um 90%, nachdem sie von einem verteilten Microservices-Setup zu einer monolithischen Anwendung wechselten.

Die Details sind aufschlussreich: Da Media Converter und Defect Detector nun auf demselben Server liefen, brauchte es keinen Vermittler mehr für die Video- und Audiodaten. Das eliminierte die Notwendigkeit für Zwischenspeicherung und sparte massiv bei S3-Kosten.

Wichtige Einordnung: Diese monolithische Lösung betrifft nur eine Komponente der gesamten Prime Video Services. Andere Bereiche von Prime Video sowie das Amazon-Kernsystem setzen weiterhin auf Microservices.

MACH Alliance: Berechtigte Kritik statt Totgesang

Die Debatte wurde hitziger, als ein prominenter Player auspackte. Mariano Gomide de Faria, Co-CEO von VTEX, formulierte scharf: „Rein best-of-breed orientierte MACH-Architekturen erzeugen häufig eine Komplexität und Fragmentierung, die der Business-Agilität schadet, Innovation ausbremst und die Betriebskosten hochtreibt.“

Seine Kritik trifft einen wunden Punkt. Aber – und das ist entscheidend – er kritisiert die dogmatische Überanwendung, nicht das Konzept selbst.

Andrew Kumar von Uniform, selbst MACH Alliance-Mitglied, bringt es auf den Punkt: Unternehmen fahren einen pragmatischen Kurs. Sie setzen auf Composability dort, wo Flexibilität und Skalierung zählen. Sie konsolidieren dort, wo Einfachheit und Kosteneffizienz wichtiger sind.

Die Zahlen lügen nicht: Reality Check 2025

Aktuelle Erhebungen aus 2024 zeigen: 85% der Unternehmen nutzen Microservices – aber viele kämpfen mit Problemen, die niemand auf dem Radar hatte.

Das Deployment-Paradox

90% der Microservices-Teams deployen weiterhin batch-orientiert, genau wie bei Monolithen. Damit ist der größte architektonische Vorteil dahin.

Die Team-Size-Falle

Microservices entfalten ihre Stärken erst bei Teams mit mehr als 10 Entwicklern. Darunter? Monolithen schlagen sie in Performance und Effizienz.

Operations-Albtraum

Jeder Microservice bedeutet: eigene Infrastruktur, CI/CD-Pipeline, Monitoring, Logging, Security Policies. Bei größerem Maßstab wird dieser Overhead zur echten Belastung, die kleinere Teams schlicht überfordert.

MACH ist nicht gescheitert – es wurde missverstanden

Kumar analysiert scharf: Das Problem liegt nicht in der Architektur selbst. Es liegt daran, wie Firmen sie falsch verstehen oder anwenden. CX- und Marketing-Verantwortliche bewerten Vendor-Versprechen falsch, halten MACH für zu komplex oder glauben, sie bräuchten einen kompletten Platform-Austausch.

Die unbequeme Wahrheit: MACH-Prinzipien sind zum Standard geworden, keine Besonderheit mehr. Die echte Herausforderung ist nicht mehr, eine MACH-Architektur zu bauen. Die Herausforderung ist, damit echten Business Value zu schaffen.

Mein Ansatz: Context-Driven Architecture

Ich sage es seit Jahren in Kundenprojekten: Vergiss das „entweder-oder“. Die Zukunft liegt im intelligenten „sowohl-als-auch“.

Core-Bereiche: Wenn Stabilität zählt

ERP-Fundament: Finanzbuchhaltung, Controlling, Stammdatenverwaltung
PIM-Backbone: Produktdaten, Katalogstrukturen, Klassifizierungen
Commerce-Kern: Bestellabwicklung, Preisfindung, Bestandsführung

Diese Prozesse sind keine Spielwiese für Experimente. Sie brauchen Verlässlichkeit, Performance und Datenintegrität. Ein gut geschnittener Monolith oder eng gekoppelte Services sind hier oft die klügere Wahl.

Edge-Bereiche: Wo Flexibilität trumpft

Frontend & Experience: A/B-Tests, neue Kanäle, ständige UX-Optimierung
Content & Marketing: Kampagnen, Marketing Automation, SEO-Optimierung
Integration & Analytics: Externe APIs, Datenauswertung, Business Intelligence
Innovation Lab: KI/ML-Experimente, neue Touchpoints, Beta-Features

Hier zahlt sich MACH-Flexibilität aus. Schnelle Zyklen, unabhängige Deployments, beste Tools für jeden Zweck.

Aus der Praxis: Ein E-Commerce-Beispiel

Großer Fashion-Retailer mit allen Herausforderungen des Unified Commerce:

Commerce-Core als Monolith: Order Management, Payment Processing, Inventory
MACH-Frontend: Drei unterschiedliche Storefronts für verschiedene Brands
Composable Marketing: CMS, Personalization Engine, Analytics Suite
Gezielt Microservices: Live-Chat-System, Recommendation Engine

Das Ergebnis spricht für sich: 40% schnellere Feature-Releases bei gleichzeitig 30% niedrigeren Betriebskosten.

Warum diese drastischen Verbesserungen?

40% schnellere Feature-Delivery durch:

Parallele Entwicklung: Marketing, Frontend-Teams und Product arbeiten ohne gegenseitige Blockaden
Zero Dependencies: Frontend-Changes brauchen keine Core-Releases mehr
Deployment-Frequenz: Von 2-Wochen-Sprints zu täglichen Deployments

30% niedrigere Betriebskosten durch:

Eliminierter Microservices-Overhead: Von 47 CI/CD-Pipelines auf 4
Reduzierte Netzwerk-Komplexität: In-Memory-Calls statt API-Calls im Core
Optimierte Ressourcen: 3 große Container statt 20 kleine mit je eigenem Overhead
Vereinfachtes Operations: Von 5 On-Call-Rotationen auf 2

Die Kombination ist entscheidend: Stabiler Core eliminiert operative Komplexität. Flexible Edge ermöglicht schnelle Innovation.

Der Trend 2025: Modulare Monolithen als dritter Weg

2025 etabliert sich der modulare Monolith als ernsthafte Alternative. Viele Teams wählen diesen Mittelweg für neue Projekte – eine Brücke zwischen klassischem Monolith und vollständig verteilten Microservices.

Die Debatte dreht sich nicht mehr ums Schwarz-Weiß. Es geht um kontextbasierte Entscheidungen. Teams erkennen neu: Oft führen Einfachheit und gute Developer Experience zu nachhaltigeren Systemen als fancy Architektur-Muster.

Decision Framework: Der Praktiker-Leitfaden

Erfolgreiche Architekturen entstehen durch progressive Modularisierung, selektive Extraktion echter Microservices und einen klaren Fokus auf Teamgröße und Velocity.

Die Strategie für nachhaltige Systeme:

Phase 1 – Smart Start: Beginne mit einem sauber strukturierten Monolith oder Modulith. Klare Grenzen zwischen Modulen, aber noch keine Netzwerk-Calls.
Phase 2 – Identifizieren: Finde die echten Bottlenecks. Wo drückt der Schuh? Skalierung? Team-Unabhängigkeit? Deployment-Frequenz?
Phase 3 – Selektiv extrahieren: Schneide Services nur raus, wenn der Business Case klar ist. Nicht weil es trendy ist.
Phase 4 – MACH als Guideline: Nutze MACH-Prinzipien als Orientierung, nicht als Gesetz. Kontext schlägt Dogma.

Die Team-Size-Faustregel:

Unter 10 Entwickler: Monolith oder Modulith meist die bessere Wahl
10-50 Entwickler: Hybrid-Ansatz entfaltet sein Potenzial
50+ Entwickler: MACH kann seine Stärken voll ausspielen

Bottom Line: Erwachsen werden statt Extreme

Monolithen sind weder besser noch schlechter als Microservices. Es sind unterschiedliche Architekturmuster für unterschiedliche Business Cases und Anwendungsfälle.

MACH hat definitiv seine Berechtigung. Die Möglichkeit, für jeden Zweck das beste Tool zu wählen, ist in vielen Szenarien unschlagbar. Aber das blinde Jagen nach MACH-Prinzipien führt zu Overengineering.

Die Lehre aus Amazon Prime Video, aus der MACH-Debatte und aus dutzenden Kundenprojekten: Der Kontext entscheidet.
Nicht jeder Service muss ein Microservice sein. Nicht jede App braucht einen Monolith. Smart ist, wer die Balance findet.

Stabile Cores für geschäftskritische Prozesse. Flexible Edges für Innovation und Experimente. Das ist die Formel für 2025.

MACH ist nicht tot. Es ist erwachsen geworden. Zeit, dass wir es auch werden.

Interesse geweckt? Lass uns über deine Architektur-Herausforderungen sprechen.

Quellen: