Microservices vs. Monolith: Die pragmatische Entscheidung

Amazon Prime Video kehrte 2023 von Microservices zurück zum Monolith - und sparte 90% Infrastrukturkosten. Diese Nachricht erschütterte die Tech-Welt. War alles, was wir über Microservices gelernt haben, falsch? Die Antwort ist komplexer - und pragmatischer.

Die überraschende Realität: 29% kehren zurück

Laut einer O'Reilly-Studie von 2024 haben 61% der Unternehmen Microservices eingeführt. Aber 29% sind wieder zum Monolith zurückgekehrt. Der Grund: Die Komplexität überstieg den Nutzen.

Gartner bestätigt: Unternehmen mit falscher Architektur-Entscheidung haben 40% höhere Entwicklungskosten und 60% längere Time-to-Market.

Wann der Monolith die bessere Wahl ist

Entgegen der Hype-Kultur: Der Monolith ist oft die richtige Entscheidung. Hier ist meine Checkliste:

• Team kleiner als 15 Entwickler: Ein Team kann einen Monolith gut managen. Microservices erfordern dedizierte Teams pro Service.
• Startup oder neues Produkt: Sie brauchen Geschwindigkeit, nicht Skalierbarkeit. Die Domäne ist noch unklar.
• Einfaches Deployment wichtig: Ein Artefakt deployen ist einfacher als 20 Services zu koordinieren.
• Transaktionen über mehrere Bereiche: Wenn Ihre Business-Logik atomare Transaktionen erfordert, macht ein verteiltes System das Leben schwer.

Wann Microservices Sinn machen

Microservices sind kein Selbstzweck. Sie lösen spezifische Probleme:

• Unabhängige Skalierung nötig: Ein Teil Ihrer Anwendung braucht 100x mehr Ressourcen als der Rest.
• Teams müssen autonom arbeiten: Bei 50+ Entwicklern wird der Monolith zum Bottleneck. Jedes Team wartet auf das andere.
• Polyglotte Technologie: Verschiedene Teile profitieren von verschiedenen Sprachen (ML in Python, API in Go, Admin in PHP).
• Unterschiedliche Release-Zyklen: Der Payment-Service released 4x am Tag, der Catalog-Service 1x pro Woche.

Der Mittelweg: Modular Monolith

2025 gewinnt eine dritte Option an Bedeutung: Der Modular Monolith. Er kombiniert das Beste beider Welten:

Der Modular Monolith ist ein Monolith mit klaren Modul-Grenzen. Die Module kommunizieren über definierte Schnittstellen - aber alle laufen im selben Prozess.

Conway's Law: Architektur folgt Organisation

Melvin Conway formulierte 1967: "Organisationen entwerfen Systeme, die ihre Kommunikationsstruktur abbilden."

Das bedeutet konkret:

• Ein Team = Ein Monolith funktioniert gut
• Mehrere Teams mit starker Kommunikation = Modular Monolith
• Autonome Teams mit klaren Verantwortlichkeiten = Microservices

Wenn Ihre Teamstruktur nicht zu Microservices passt, werden Microservices scheitern. Die Architektur wird immer zur Organisation konvergieren - ob Sie es planen oder nicht.

Das unterschätzte Problem: Daten

Über Microservices wird viel diskutiert. Über das Datenmodell zu wenig.

Im Monolith: Eine Transaktion aktualisiert User-Profil und Billing. Fertig.

Bei Microservices: Zwei Services, zwei Datenbanken. Plötzlich brauchen Sie:

• Saga-Pattern oder 2-Phase-Commit
• Eventual Consistency statt Strong Consistency
• Kompensations-Logik für fehlgeschlagene Teiloperationen

Mein Entscheidungsbaum

Nach über 10 Jahren Erfahrung mit beiden Ansätzen nutze ich diesen Entscheidungsbaum:

1. Neues Projekt oder Startup? → Monolith (validieren Sie erst das Produkt)
2. Team < 15 Entwickler? → Monolith oder Modular Monolith
3. Domänen-Grenzen klar? → Modular Monolith als Vorbereitung
4. Skalierungs-Schmerzen real (nicht hypothetisch)? → Microservices für betroffene Domänen
5. Teams autonom organisiert? → Microservices können funktionieren

Fazit: Pragmatik schlägt Dogma

Die richtige Architektur ist die, die zu Ihrem aktuellen Kontext passt - nicht die, die Netflix oder Amazon nutzt.

Starten Sie einfach. Führen Sie klare Modul-Grenzen ein. Extrahieren Sie Services erst, wenn realer Schmerz entsteht. Und ignorieren Sie jeden, der sagt, es gäbe nur einen richtigen Weg.

Falls Sie unsicher sind, welche Architektur für Ihr Projekt passt: Ein Architektur-Audit schafft Klarheit - bevor Sie sich für Jahre festlegen.