Microservices gelten seit Jahren als Architektur der Wahl. Trotzdem ist in vielen Projekten ein gut strukturierter Monolith die bessere Lösung. Die Entscheidung hängt nicht von technischem Geschmack ab, sondern von Team-Größe, Domänenkomplexität und Betriebsreife. Wann lohnt sich eine Migration wirklich, und wann bleibt der Monolith?
Was Monolithen gut machen
Ein Monolith ist kein Anti-Pattern. Für Teams unter 20 Entwicklern mit einer klar abgegrenzten Domäne bringt er echte Vorteile: ein einzelnes Deployment, ein Debugging-Kontext, keine Netzwerk-Latenz zwischen Komponenten. Ein Rename greift sofort überall, Refactoring über Modulgrenzen bleibt einfach.
Shopify betreibt einen der größten Ruby-on-Rails-Monolithen der Welt. Warum? Die Architektur passt zur Organisationsstruktur. Solange ein Team den gesamten Code überblicken und deployen kann, erzeugt eine Aufteilung in Services vor allem zusätzliche Komplexität.
Kritisch wird es, wenn der Monolith wächst, ohne dass jemand interne Grenzen zieht. Dann entstehen technische Schulden: lange Build-Zeiten, fragile Tests, Angst vor Deployments.
Wann Microservices tatsächlich helfen
Besser als “Sind Microservices besser?” ist die Frage: “Lösen sie ein konkretes Problem, das wir heute haben?” Drei Signale sprechen für eine Aufteilung:
Wenn Team A wöchentlich deployen will, aber auf den Zwei-Wochen-Sprint von Team B warten muss, bremst die gekoppelte Codebasis. Separate Services mit eigenen Pipelines lösen das, vorausgesetzt die DevSecOps-Praktiken stimmen.
Zweites Signal: unterschiedliche Skalierung. Ein Reporting-Modul, das nachts Batch-Jobs verarbeitet, hat andere Ressourcen-Bedürfnisse als eine API mit 10.000 Requests pro Sekunde. Im Monolith skaliert immer alles gemeinsam, und das wird teuer.
Drittes Signal: die fachlichen Kontexte (Bounded Contexts im DDD-Sinne) sind gut verstanden. Dann lassen sich Services entlang dieser Grenzen schneiden. Ohne klare Domänengrenzen entsteht ein verteilter Monolith, und das ist der Worst Case.
Die versteckten Kosten einer Migration
In Beratungsprojekten sehen wir regelmäßig, dass Teams die Betriebskosten von Microservices unterschätzen.
Jeder Service braucht eigenes Monitoring, Logging, Health Checks und Alerting. Ein Setup mit Prometheus, Grafana und Loki ist Pflicht. Die Infrastruktur-Komplexität wächst linear mit der Anzahl der Services.
Dazu kommt Netzwerk-Komplexität. Synchrone Calls zwischen Services erzeugen Latenz-Ketten. Ein Request durch fünf Services wird spürbar langsamer. Asynchrone Kommunikation über Message Queues löst das Latenz-Problem, bringt aber Eventual Consistency mit, und die muss das Team beherrschen.
Auch Testing wird aufwendiger. Unit Tests bleiben einfach, aber Integrationstests über Service-Grenzen hinweg kosten Zeit. Contract Testing mit Pact hilft, erfordert aber Disziplin:
provider:
name: OrderService
base_url: http://localhost:8080
pact_broker:
url: https://pact-broker.internal
token: ${PACT_TOKEN}
verify:
provider_states_setup_url: http://localhost:8080/pact-states
publish_verification_results: true
provider_app_version: ${CI_COMMIT_SHA}Und dann der organisatorische Aufwand: Microservices erfordern klare Ownership. Jeder Service braucht ein verantwortliches Team. Ohne diese Zuordnung entsteht ein Niemandsland, in dem Bugs zwischen Teams hin- und hergeschoben werden.
Der Modular-Monolith als Zwischenschritt
Bevor eine vollständige Migration startet, lohnt sich ein Zwischenschritt: der modulare Monolith. Innerhalb der bestehenden Codebasis werden klare Modulgrenzen gezogen, mit definierten Schnittstellen zwischen den Modulen, aber weiterhin einem gemeinsamen Deployment.
// order-module/src/main/java/de/everbright/order/OrderFacade.java
public class OrderFacade {
// Öffentliche API des Moduls, nur diese Klasse ist von außen sichtbar
public OrderConfirmation placeOrder(CreateOrderRequest request) {
var order = orderService.create(request);
// Kommunikation mit anderen Modulen nur über deren Facades
inventoryFacade.reserve(order.getItems());
return new OrderConfirmation(order.getId(), order.getTotal());
}
}So werden die Domänengrenzen im laufenden Betrieb validiert, bevor sie zu Service-Grenzen werden. Wenn sich herausstellt, dass zwei Module doch eng gekoppelt sind, ist ein Refactoring im Monolith deutlich günstiger als zwischen zwei Services.
Die meisten Teams, die wir beraten, profitieren mehr von sauberer interner Struktur als von verteilten Systemen. Erst modularisieren, dann verteilen.
Entscheidungsrahmen für die Praxis
Fünf Faktoren helfen bei der Entscheidung:
Unter 3 Teams spricht wenig gegen einen Monolith oder Modular Monolith. Ab 4+ autonomen Teams wird der Koordinationsaufwand im Monolith zum Flaschenhals, dann werden Microservices sinnvoll.
Bei der Deployment-Frequenz zählt: Entwickeln sich verschiedene Teile der Anwendung in unterschiedlichem Tempo, spricht das für Services. Wenn alles im gleichen Rhythmus released wird, bringt eine Aufteilung keinen Vorteil.
Betriebsreife ist Voraussetzung. Microservices setzen voraus, dass das Team Container-Orchestrierung, Service Mesh, Distributed Tracing und automatisiertes Deployment beherrscht. Ohne diese Fähigkeiten wird die Migration zum Risiko. Eine solide Cloud-Strategie gehört dazu.
Wer die fachlichen Grenzen noch nicht kennt, sollte im Monolith bleiben und zuerst modularisieren. Falsch geschnittene Services sind teurer als ein unstrukturierter Monolith, weil jede Korrektur ein verteiltes Refactoring erfordert.
Und nicht zuletzt das Budget: Die laufenden Kosten für Infrastruktur, Monitoring und Betrieb steigen mit jedem Service. Für mittelständische Unternehmen rechnet sich das erst ab einer gewissen Größe.
Fazit
Microservices lösen reale Probleme, aber nur, wenn diese Probleme tatsächlich existieren. Die beste Architektur-Entscheidung beginnt nicht mit der Technologie, sondern mit einer ehrlichen Analyse der eigenen Team-Struktur, Domänenkomplexität und Betriebsfähigkeiten. Wer heute einen Monolith betreibt, sollte zuerst interne Modulgrenzen schärfen. Und wer Microservices einführt, braucht einen klaren Plan für Observability, Ownership und Deployment-Automation. Sonst tauscht man alte Probleme gegen neue. Bei der Bewertung eurer Architektur unterstützen wir gern →
Häufige Fragen
Ab wie vielen Entwicklern lohnen sich Microservices?
Ab vier bis fünf autonomen Teams wird der Koordinationsaufwand im Monolith zum Flaschenhals. Unter drei Teams ist ein Monolith oder modularer Monolith wirtschaftlicher. Die Zahlen sind Richtlinien, nicht absolute Regeln.
Wie viel teurer sind Microservices im Betrieb?
Die Betriebskosten sind typischerweise 30-50% höher als bei einem Monolith, weil jeder Service eigenes Monitoring, Logging und Alerting braucht. Hinzu kommt Netzwerk-Komplexität und aufwendigere Integrationstests. Diese Kosten rechnen sich nur bei entsprechender Skalierung oder Deployments-Häufigkeit.
Sollte man gleich mit Microservices starten?
Nein. Besser zunächst mit einem modularen Monolith beginnen, die Domain-Grenzen validieren, und erst dann in Services aufteilen. Das ist günstiger und ermöglicht bessere Schnittstellendefinitionen als von Anfang an zu verteilen.
Was ist ein modularer Monolith?
Ein modularer Monolith ist eine einzelne Codebasis mit strikten Modulgrenzen und definierten Schnittstellen zwischen den Modulen. Jeder Service kann später aus seinem Modul ausgegliedert werden. Das reduziert Risiken einer Migration erheblich.
Was bedeutet Eventual Consistency bei Microservices?
Eventual Consistency heißt: Nach einer Änderung sehen nicht alle Services sofort den neuen Zustand. Asynchrone Kommunikation über Message Queues verbessert Performance, bringt aber Verzögerungen mit sich. Alle Services bekommen die Updates am Ende, aber es gibt ein Zeitfenster, in dem unterschiedliche Sichten auf die Daten existieren. Teams müssen das einplanen und Edge Cases wie doppelte Nachrichten oder Teilausfälle bewusst behandeln.
