Modularer Monolith oder Microservices. Eine Entscheidungshilfe

Die Debatte über Monolithen und Microservices wird oft als Wahl zwischen alt und modern geführt. Das hilft bei einer Investitionsentscheidung kaum. Architektur sollte dazu passen, wie ein Team entwickelt, veröffentlicht und den Betrieb verantwortet. Jede Servicegrenze schafft Unabhängigkeit. Sie bringt zugleich Netzwerkkommunikation, ein weiteres Deployment und neue Fehlerarten.

Ein modularer Monolith läuft als eine Anwendung, trennt sein Inneres aber nach geschäftlichen Fähigkeiten. Auftrag, Abrechnung und Bestand besitzen eigene Schnittstellen. Microservices verschieben vergleichbare Grenzen in getrennte Prozesse und meist getrennte Datenspeicher. Der wichtige Unterschied liegt in den Betriebskosten der Grenze.

1. 01

   Modularer Monolith

   Ein Prozess und ein Deployment. Module sprechen über interne Verträge.

2. 02

   Microservices

   Eigenständige Prozesse und Deployments. Jede Grenze bringt Netzwerk und Betrieb.

Mit der Domäne beginnen

Kann ein Team eine fachliche Grenze nicht in einem Prozess sauber ziehen, findet ein Netzwerk sie nicht automatisch. Eine unsichere Trennung führt zu vielen entfernten Aufrufen, gemeinsam genutzten Tabellen und weiterhin koordinierten Releases. Das System erhält verteilte Fehler, aber keine echte Unabhängigkeit.

Ein Modul braucht einen öffentlichen Vertrag. Die Abrechnung sollte keine internen Bestandstabellen lesen. Sie fordert eine Reservierung über eine Schnittstelle des Bestandsmoduls an. Abhängigkeitsregeln und Architekturtests halten diese Grenze ein. Ist der lokale Vertrag stabil, lässt er sich später leichter hinter eine API verschieben.

Sinnvolle Module folgen Geschäftsbereichen statt technischen Ordnern wie Controller oder Repository. Eine Preisänderung bleibt dann in der Preislogik. Dasselbe Prinzip zeigt unser Beitrag zu Entwurfsmustern in der Praxis auf Codeebene.

Was ein Microservice erkauft

Ein separat bereitgestellter Dienst kann im eigenen Rhythmus erscheinen. Die Suche wird veröffentlicht, ohne die ganze Anwendung auszuliefern. Rechenintensive Aufgaben lassen sich unabhängig skalieren. Ein sensibler Bereich kann strengere Sicherheitsregeln bekommen. Diese Freiheit ist wertvoll, wenn die Organisation sie tatsächlich nutzen kann.

Die Kosten entstehen sofort. Ein Funktionsaufruf wird zur Netzwerkanfrage. Sie kann langsam sein, doppelt eintreffen oder vollständig ausfallen. Das System braucht Zeitlimits, wiederholbare Verarbeitung, nachvollziehbare Anfragen und einen Plan für Teilausfälle. Eine einzige Datenbanktransaktion kann den gesamten Geschäftsvorgang nicht mehr absichern.

Auch Tests verändern sich. Ein erfolgreicher Unit-Test beweist nicht, dass bereitgestellte Dienste noch zusammenpassen. Verträge benötigen Kompatibilitätsprüfungen. In Produktion müssen Logs, Metriken und Traces zeigen, wo eine Anfrage stehen blieb. Ohne diese Fähigkeiten wächst die Diagnosezeit schnell.

Daten zeigen die echte Grenze

Ein Dienst, der eigenen Code hat, aber fremde Tabellen abfragt, ist nicht unabhängig. Eine Schemaänderung kann ihn ohne Änderung seines Repositorys beschädigen. Datenbesitz gehört deshalb zur Architekturentscheidung.

Getrennte Speicher bedeuten außerdem, dass manche Ansichten kurzzeitig veraltet sind. Ein Auftrag kann bestätigt werden, bevor die Abrechnung das Ereignis verarbeitet. Das Team muss festlegen, wo diese Verzögerung zulässig ist. Kontostand oder Reservierung des letzten Artikels brauchen womöglich ein anderes Modell als eine Auswertung.

Eine verteilte Transaktion sollte nicht als Kette anfälliger synchroner Aufrufe versteckt werden. Ereignisse, idempotente Empfänger und fortsetzbare Abläufe können helfen. Auch sie müssen beobachtet und getestet werden. Braucht das Produkt keinen unabhängigen Datenbesitz, ist eine gemeinsame Datenbank hinter starken Modulgrenzen meist günstiger.

Teamverantwortung verändert die Antwort

Microservices funktionieren am besten, wenn Teams einen Dienst vom Entwurf bis zum Produktionsvorfall besitzen. Ein separates Repository ohne stabilen Eigentümer verteilt Verantwortung, statt sie zu klären. Änderungen warten auf Personen, die ein anderes Glied der Kette verstehen.

Ein kleineres Produktteam profitiert oft stärker von einem Deployment, einer Entwicklungsumgebung und direkten Refactorings über Modulgrenzen hinweg. Das verlangt keinen ungeordneten Monolithen. Es bedeutet nur, dass Verteilung ein teurer Weg ist, Codedisziplin zu erzwingen.

Die Lage ändert sich, wenn unabhängige Teams regelmäßig ein gemeinsames Release blockieren, die fachliche Grenze stabil ist und Bereiche einen eigenen Rhythmus brauchen. Dann kann eine Auslagerung Koordination senken. Der Beleg kommt aus der beobachteten Arbeit, nicht aus einem Referenzdiagramm.

1. 01

   Eigenständiger Änderungsrhythmus

   Ein Modul blockiert Releases der übrigen.

2. 02

   Anderes Skalierungsprofil

   Die Last ist isoliert und wiederholt gemessen.

3. 03

   Klarer Eigentümer

   Ein Team kann Entwicklung und Betrieb übernehmen.

4. 04

   Stabiler Vertrag

   Die Domänengrenze verschiebt sich nicht mehr jeden Sprint.

Signale für eine Auslagerung

Ein Signal ist ein unabhängiger Änderungsgrund. Das Modul besitzt eine eigene Roadmap, und die meisten Arbeiten erfordern keine Anpassung anderswo. Ein weiteres Signal ist ein besonderer Betriebsbedarf. Der Bereich braucht andere Skalierung, Verfügbarkeit oder eine Technologie, die der Rest nicht benötigt.

Ebenso wichtig ist ein stabiler Vertrag. Das Team kann Eingaben, Ausgaben, Datenbesitz und Fehlerverhalten benennen. Ändert sich der Vertrag in jedem Sprint, verwandelt ein separates Deployment lokale Instabilität nur in Arbeit an API-Versionen.

Ein sinnvoller Weg stärkt zuerst die Grenze im Monolithen. Direkte Datenbankzugriffe werden entfernt, Vertragstests ergänzt und Interaktionen gemessen. Danach lässt sich der Nutzen der Auslagerung mit den Kosten der Verteilung vergleichen. Der Service ist eine aus Belegen abgeleitete Entscheidung.

Die Entscheidung umkehrbar halten

Für ein neues Geschäftssystem ist ein modularer Monolith oft ein guter Start, solange Produkt und Grenzen noch reifen. Ein Deployment hält Rückmeldung schnell. Gut geschützte Module bewahren die Möglichkeit, einen später unabhängigen Bereich herauszulösen.

Microservices passen, wenn das Unternehmen bereits einen messbaren Preis für gemeinsame Releases, gemeinsames Skalieren oder unklare Verantwortung zahlt. Eine seriöse Schätzung umfasst Plattform, Beobachtbarkeit und Reaktion auf Vorfälle. Das Aufteilen des Quellcodes erzeugt diese Fähigkeiten nicht.

Bei individueller Softwareentwicklung halten wir Annahmen in einer überprüfbaren Architekturentscheidung fest. Bremst ein bestehendes System bereits jede Änderung, erklärt der nächste Beitrag die Modernisierung eines Legacy-Systems ohne Big Bang. Ziel ist kein Sieg in einer Architekturdebatte. Ziel sind sichere Änderungen mit geringerem Aufwand.

Vor einer Trennung sollte außerdem ein Rückweg existieren. Messwerte aus dem Modul zeigen Last, Fehler und Änderungsfrequenz. Erst diese Daten erlauben eine belastbare Kostenrechnung. Wenn nach der Auslagerung weiterhin jedes Release mehrere Teams gleichzeitig benötigt, lag die Grenze falsch. Dann ist eine Korrektur wertvoller als das Festhalten an der gewählten Bezeichnung.