"Sollen wir Microservices oder einen Monolithen bauen?" — diese Frage begegnet uns in fast jedem Discovery-Workshop. Und die ehrliche Antwort lautet: Es kommt drauf an. Aber nicht auf das, was die meisten denken.
Dieser Artikel räumt mit den häufigsten Mythen auf, zeigt anhand realer Unternehmensbeispiele wann welche Architektur Sinn ergibt, und gibt Ihnen eine praktische Entscheidungshilfe.
Die größten Mythen
Mythos 1: Microservices skalieren besser
Stimmt — aber nur wenn Sie das richtige Problem haben. Die meisten Anwendungen haben kein Skalierungsproblem, das Microservices lösen würden. Sie haben ein Team-Koordinations-Problem oder ein Deployment-Risiko-Problem. Diese kann ein gut strukturierter Monolith genauso lösen. Ein Monolith kann horizontal skaliert werden — mehrere Instanzen hinter einem Load Balancer — und das reicht für die übergroße Mehrheit aller Webanwendungen.
Mythos 2: Microservices sind moderner
Shopify, Stack Overflow, Basecamp und viele weitere erfolgreiche Produkte laufen auf Monolithen. Instagram startete als Monolith und war damit so erfolgreich, dass Facebook es für 1 Milliarde Dollar kaufte — bevor irgendeine Microservice-Migration passierte.
Mythos 3: Microservices sind einfacher zu warten
Das Gegenteil ist oft wahr. Distributed Systems bringen verteilte Fehler, Distributed Tracing, Netzwerklatenzen, Service Discovery und Deployment-Komplexität mit. Das ist nicht komplizierter als ein Monolith — es ist anders kompliziert.
"Don't start with microservices. Start with a well-structured monolith. Split when you feel real pain." — Martin Fowler
Wie Amazon, Netflix und Uber wirklich migrierten
Die drei am häufigsten zitierten Microservices-Erfolgsgeschichten haben eines gemeinsam: Sie alle begannen mit einem Monolithen, der bereits erfolgreich war.
Amazon startete 1995 als einfacher Buchshop. Die Migration zu Microservices begann erst, als das Unternehmen bereits über 2 Millionen aktive Kundschaft hatte und die Teams so groß geworden waren, dass Deployment-Koordination zur Vollzeitbeschäftigung wurde. Microservices waren die Antwort auf ein konkretes, schmerzhaftes Wachstumsproblem, nicht eine strategische Vorabentscheidung.
Netflix betrieb bis 2008 einen monolithischen Dienst. Erst als das Streaming-Angebot explodierte, begann die schrittweise Migration. Sie dauerte sieben Jahre und erforderte ein eigenes Platform-Engineering-Team (Netflix-OSS: Eureka, Hystrix, Ribbon).
Uber migrierte ebenfalls von einem Monolithen, als das Unternehmen in über 50 Städte expandierte. Auch hier: spezifischer Schmerz zuerst, Migration danach. Die Lektion: Erst der Monolith, dann — wenn nötig — die Migration.
Wann ist ein Monolith die richtige Wahl?
- Ihr Team hat weniger als 10–15 Entwickler
- Sie bauen ein neues Produkt (Domain-Grenzen noch unklar)
- Time-to-Market ist kritisch
- Sie haben kein dezidiertes Infrastruktur-Team
- Ihr Traffic ist vorhersehbar und moderat (unter 10.000 gleichzeitige Nutzer)
- Das Produkt ist noch im MVP-Stadium
- Sie kennen die Domain noch nicht gut genug, um sinnvolle Service-Grenzen zu ziehen
Wann sind Microservices sinnvoll?
- Verschiedene Services haben radikal unterschiedliche Skalierungsanforderungen
- Verschiedene Teams arbeiten parallel an komplett getrennten Domänen und Deployment-Abhängigkeiten sind der Engpass
- Sie müssen Services in verschiedenen Programmiersprachen implementieren
- Sie haben bereits einen Monolithen und spüren echten, messbaren Schmerz
- Sie haben ein Team mit Distributed-Systems-Erfahrung und dedizierter DevOps-Kapazität
Der Mittelweg: Modularer Monolith
Unsere bevorzugte Architektur für die meisten neuen Projekte: ein modularer Monolith. Klare Modul-Grenzen innerhalb einer einzigen deployten Anwendung:
// Klare Modul-Grenzen im Monolithen (NestJS)
src/
modules/
auth/
auth.controller.ts
auth.service.ts
auth.module.ts
orders/
orders.controller.ts
orders.service.ts
orders.module.ts
shared/
database/
events/
Kein Modul greift direkt auf Datenbanktabellen eines anderen Moduls zu. Kommunikation läuft über definierte Service-Interfaces oder ein internes Event-System. Domain-Driven Design (DDD) liefert das Werkzeug, diese Grenzen sinnvoll zu ziehen.
Service-Kommunikation: Sync vs. Async
Synchrone Kommunikation über REST oder gRPC: Service A ruft Service B an und wartet. Einfach zu verstehen, leicht zu debuggen. Nachteil: Wenn Service B ausfällt, leidet auch Service A.
Asynchrone Kommunikation über Message Queues (Apache Kafka, RabbitMQ) entkoppelt Services vollständig. Service A schreibt ein Event in eine Queue und macht weiter. Deutlich resilienter.
// Synchron: REST mit Timeout
const result = await fetch('http://inventory-service/check', {
signal: AbortSignal.timeout(2000),
});
// Asynchron: Message an Kafka
await kafkaProducer.send({
topic: 'order.created',
messages: [{ value: JSON.stringify(orderEvent) }]
});
Faustregel: Synchron für Queries (Daten lesen), asynchron für Commands (Dinge anstoßen).
Team-Struktur und Conway's Law
Melvin Conway formulierte 1968: "Organisationen, die Systeme entwerfen, sind darauf beschränkt, Designs zu produzieren, die die Kommunikationsstruktur dieser Organisationen kopieren."
Microservices sind kein technisches Problem — sie sind ein organisatorisches. Wer sie ohne passende Team-Struktur einführt, schafft verteilte Komplexität ohne verteilte Vorteile.
Für ein Team unter 20 Entwicklern ist die Wahrscheinlichkeit hoch, dass Microservices mehr Overhead als Nutzen bringen. Dedizierte DevOps-Kapazität ist keine Option — sie ist eine Voraussetzung.
Migration: Vom Monolith zu Microservices
Falls Sie irgendwann migrieren müssen, empfehlen wir das Strangler Fig Pattern:
Phase 1: Identifiziere den schmerzhaftesten Teil des Monolithen
Phase 2: Extrahiere diesen als ersten Microservice
Phase 3: Betreibe Monolith + Service parallel hinter einem API Gateway
Phase 4: Migriere Traffic schrittweise (10% → 50% → 100%)
Phase 5: Entferne den extrahierten Teil aus dem Monolithen
Phase 6: Repeat für den nächsten Problembereich
Wann Sie NICHT migrieren sollten
- Der Monolith läuft stabil und kein echtes Problem existiert
- Das Team hat nicht die DevOps-Kapazität
- Die Migration ist primär aus technischem Ehrgeiz motiviert
- Die Domain-Grenzen sind noch nicht stabil genug
Kosten und Betrieb im Vergleich
Microservices sind deutlich teurer zu betreiben:
- Monolith: Eine Deployment-Pipeline, eine Logging-Konfiguration, ein Monitoring-Setup
- Microservices: Jeder Service braucht eigene Pipeline, Logging, Health-Monitoring, Service-Mesh, API Gateway, Distributed Tracing
Ein Kubernetes-Cluster für 5 Microservices kostet typischerweise 400–800 € pro Monat. Ein Monolith auf einem mittelgroßen Server: 30–80 €. Der Betriebskostenunterschied über drei Jahre: 15.000–25.000 €.
Fazit: Pragmatisch entscheiden, nicht ideologisch
Starten Sie mit einem gut strukturierten modularen Monolithen. Bauen Sie klare Modul-Grenzen ein. Führen Sie Microservices ein, wenn Sie echten Schmerz spüren: Wenn Teams sich gegenseitig beim Deployen blockieren, wenn ein Service zehnmal mehr Last trägt als alle anderen, wenn Compliance strikte Datenisolation erzwingt. Nicht weil es in einem Blog-Post cool klang.
Die besten Architekturentscheidungen trifft man, wenn man das System bereits kennt — und das kennt man erst nach Monaten im echten Betrieb.
Sie stehen vor einer Architekturentscheidung? Wir bieten kostenlose Architektur-Erstgespräche an.
Haben Sie Fragen zu diesem Thema? Jetzt Kontakt aufnehmen.