Modularer Monolith vs. Microservices

Wenige Entscheidungen in der Softwaretechnik werden so sehr als Identität geführt und so selten als Ingenieurfrage. „Microservices" gilt als modern, „Monolith" als rückständig — und schon ist aus einer Abwägung ein Bekenntnis geworden. Dabei benennen beide Wörter keine Qualität, sondern eine Topologie: wie ein System ausgeliefert wird und wo seine Grenzen verlaufen.

Dieser Text trifft keine Vorentscheidung. Er behandelt die Frage als das, was sie ist: eine Entscheidung darüber, wohin man die unvermeidliche Komplexität eines Systems verlegt. In den Code oder ins Netz. In den Compiler oder in den Betrieb. Beide Wege haben ihren Preis, und keiner ist fortgeschrittener als der andere. Die Kunst besteht nicht darin, den richtigen Stil zu wählen, sondern die Kräfte zu erkennen, denen das eigene System tatsächlich ausgesetzt ist.

Warum diese Diskussion überhaupt existiert

Die Diskussion existiert, weil ein Wort zum Statussymbol wurde. Als einige sehr große Unternehmen ihre Systeme in Dienste zerlegten, um mit hunderten Teams unabhängig zu liefern, übernahm die Branche die Topologie — aber nicht die Kräfte, die sie erzwungen hatten. „Microservices" wurde zum Zeichen für ernsthaftes Engineering, „Monolith" zum Schimpfwort für alles Alte. Das ist der Kern des Missverständnisses: Eine Antwort auf ein organisatorisches Skalierungsproblem wurde als allgemeiner Fortschritt verkauft.

Die nüchterne Sicht ist einfacher. Jedes nicht-triviale System trägt eine gewisse Menge Komplexität, und diese Menge verschwindet nicht — sie lässt sich nur verschieben. Im modularen Monolithen lebt sie im Code: Grenzen sind Modulgrenzen, Aufrufe sind Funktionsaufrufe, Konsistenz ist eine Transaktion. In Microservices lebt dieselbe Komplexität im Netz und im Betrieb: Grenzen sind Prozessgrenzen, Aufrufe sind Netzaufrufe mit Ausfallmodi, Konsistenz wird zur verteilten Aufgabe. Die Frage ist nie „welcher Stil ist besser", sondern „welche Verteilung der Komplexität passt zu den Kräften, die auf dieses System wirken".

Ein Detail macht die Entscheidung asymmetrisch, und es wird oft übersehen: Die beiden Fehler kosten nicht gleich viel. Eine Grenze im Code, die sich als falsch erweist, lässt sich verschieben — es ist ein Refactoring innerhalb eines Deployables. Eine Grenze im Netz, die sich als falsch erweist, ist eine Tür, die sich nur teuer wieder öffnen lässt: getrennte Datenbanken, versionierte Verträge und Betriebsapparat müssen zurückgebaut werden. Wer im Zweifel ist, sollte deshalb den umkehrbaren Fehler wählen — den, den man später günstig korrigiert.

Was ein modularer Monolith wirklich ist

Der modulare Monolith wird meist missverstanden, weil man ihn mit seinem Zerrbild verwechselt: dem ungegliederten Monolithen, dem „Big Ball of Mud", in dem alles auf alles zugreift und jede Änderung überallhin ausstrahlt. Das ist nicht gemeint. Ein modularer Monolith ist ein einziges Deployable, das im Inneren klar in Module geteilt ist — jedes Modul besitzt seine Domäne, legt eine schmale Schnittstelle offen und greift nicht in die Interna oder Tabellen eines anderen Moduls. Die Grenzen sind real; sie werden nur nicht durch das Netz erzwungen, sondern durch Disziplin und Werkzeuge.

Damit liegt der modulare Monolith bewusst zwischen zwei Extremen. Er hat die klaren Grenzen, die den ungegliederten Monolithen fehlen — und er spart sich die Netz- und Betriebskosten, die Microservices verlangen. Man bekommt den größten Teil des Nutzens von Modularität, ohne den vollen Preis der Verteilung zu zahlen.

Schema: Dieselben drei Fähigkeiten — einmal als Module hinter einer Grenze aus Disziplin, einmal als Dienste hinter einer Grenze aus Netz.

Dieselbe Entscheidung lässt sich entlang mehrerer Dimensionen betrachten. Keine Zeile ist ein Vorteil ohne Kehrseite — jede beschreibt nur, wohin die Komplexität wandert:

Entscheidend ist eine Eigenschaft, auf die der Migrationspfad später aufbaut: Ein Modul mit sauberer, schmaler Schnittstelle ist die Naht, an der man einen Dienst herauslösen kann, falls eine Kraft es später verlangt. Der modulare Monolith ist damit nicht die Alternative zu Microservices, sondern oft ihre Vorstufe.

Warum viele Teams zu früh aufteilen

Der häufigste Fehler ist nicht die Wahl von Microservices, sondern ihre Wahl zum falschen Zeitpunkt — bevor die Kräfte da sind, die sie rechtfertigen. Die Gründe sind menschlich und wiederkehrend. Der Stil gilt als Zeichen von Reife, also wählt man ihn, um ernst genommen zu werden. Man verwechselt logische Grenzen mit physischen und glaubt, nur ein Netzaufruf mache eine Grenze „echt". Man hofft, die Verteilung erzwinge gutes Design — dabei wird eine schlecht gezogene Grenze durch einen Netzaufruf nicht besser, sondern nur teurer. Und man fürchtet Skalierungsprobleme, die noch niemand gemessen hat.

Der Preis dieser frühen Teilung ist hoch und fällt sofort an: verteilte Transaktionen statt einer lokalen; Netzaufrufe mit ihren Ausfallmodi statt Funktionsaufrufen; eventuale Konsistenz, wo vorher eine Transaktion genügte; ein Betriebsapparat, den es vorher nicht brauchte; Debugging über Prozessgrenzen hinweg; versionierte Verträge zwischen Diensten, die man selbst gebaut hat. Man zahlt die volle Rechnung der Verteilung, lange bevor man ihren Nutzen einlöst.

Die Empfehlung: Beginnen Sie mit einem modularen Monolithen und teilen Sie erst, wenn eine konkrete, gegenwärtige Kraft es verlangt. Der Preis ist, dass man später einen Dienst herauslösen muss, statt ihn von Anfang an getrennt zu haben — und Nachrüsten unter Druck kostet mehr, als es von Beginn an gehabt zu haben. Anders entscheiden wir, wenn eine dieser Kräfte schon am ersten Tag nachweislich und unumkehrbar vorliegt — etwa eine regulatorische Trennung, die das Gesetz verlangt; dann zieht man diese eine Grenze sofort, aber gezielt, nicht als Prinzip über das ganze System.

Wann Microservices objektiv die bessere Wahl sind

Es gibt Situationen, in denen die Teilung nicht Mode ist, sondern die technisch überlegene Antwort. Sie haben eines gemeinsam: Eine reale Kraft macht die Prozessgrenze wertvoller als ihren Preis.

Unabhängige Skalierung ist der klarste Fall. Wenn ein Teil des Systems ein grundlegend anderes Last- und Ressourcenprofil hat — rechenintensiv gegen speicherintensiv, selten gegen dauernd gefragt — kann man ihn getrennt und kostengünstiger skalieren, statt das ganze System auf das teuerste Teil auszulegen. Unabhängige Auslieferung und Team-Autonomie zählen ebenso: Wenn genug Teams existieren, die ohne Abstimmung über ein gemeinsames Deployable liefern müssen, wird die Prozessgrenze zur organisatorischen Notwendigkeit. Fehlerisolation ist ein echter Gewinn dort, wo ein Teil unabhängig ausfallen können muss, ohne den Rest mitzureißen — eine Isolation, die nur die Prozessgrenze wirklich gibt. Technologische Heterogenität rechtfertigt einen Schnitt, wenn ein Teil nachweislich eine andere Laufzeit oder Sprache braucht. Und unabhängige Lebenszyklen — getrennte Compliance, Datenresidenz, unterschiedliche Ausfallanforderungen — können eine Trennung erzwingen, die im gemeinsamen Deployable nicht sauber abbildbar wäre.

Ein Beispiel, das ohne Zahlen auskommt: Ein System hat einen transaktionalen Kern, der viele kleine, schnelle Vorgänge verarbeitet, und daneben eine rechenintensive Aufgabe — etwa eine Auswertung, die kurzzeitig viel Prozessorleistung braucht und auf anderer Hardware am günstigsten läuft. Im gemeinsamen Deployable zwingt die rechenintensive Aufgabe den ganzen Kern auf teure Maschinen und kann ihn unter Last verdrängen. Als eigener Dienst skaliert sie getrennt, auf der Hardware, die zu ihr passt, ohne den Kern zu berühren. Hier kauft die Prozessgrenze etwas Konkretes — getrennte Skalierung und Fehlerisolation —, das der Monolith nicht bieten kann. Genau das ist eine Kraft.

Der gemeinsame Nenner ist wichtig: Es sind die Kräfte, die den Schnitt rechtfertigen, nicht die Größe. Und ein Schnitt ist selten alles-oder-nichts. Man kann genau den einen Teil herauslösen, auf den eine Kraft wirkt, und den Rest im Monolithen lassen. Die überlegene Architektur ist oft nicht „Microservices", sondern „ein modularer Monolith mit wenigen extrahierten Diensten dort, wo es zählt".

Die Empfehlung: Lösen Sie einen Dienst heraus, wenn eine benannte, gegenwärtige Kraft es verlangt — und nur diesen Dienst. Der Preis ist der volle Betriebs- und Konsistenzaufwand für den herausgelösten Teil, gezahlt ab dem ersten Tag seiner Existenz. Anders entscheiden wir, wenn dieselbe Kraft sich auch im Monolithen beherrschen lässt — etwa eine Lastspitze, die ein Cache oder eine asynchrone Queue auffängt; dann kauft der Schnitt nichts, was die günstigere Lösung nicht auch böte.

Die Kräfte im Überblick

Fehlt die Kraft, bleibt vom Schnitt nur der Preis.

Organisatorische Voraussetzungen

Microservices sind zuerst eine organisatorische Entscheidung und erst danach eine technische. Die Prozessgrenzen folgen den Teamgrenzen: Ein Dienst braucht ein Team, das ihn besitzt — entwirft, liefert und betreibt. Ohne diese Zuordnung entsteht das schlimmste Ergebnis: ein verteiltes System, das allen und niemandem gehört, bei dem jede Änderung mehrere Teams berührt und keiner die Verantwortung trägt.

Die Voraussetzungen sind konkret. Es braucht genug Teams, um Dienste sinnvoll zu besitzen; eine Kultur der Eigenverantwortung, in der ein Team seinen Dienst auch betreibt; die Reife für Bereitschaftsdienst und Incident-Bearbeitung; und die Disziplin, Verträge zwischen Teams zu pflegen, statt sich über gemeinsame Interna abzustimmen. Fehlen diese Dinge, bekommt man die Kosten der Verteilung ohne ihren Nutzen.

Die Empfehlung: Teilen Sie ein System nur so weit, wie Ihre Organisation Dienste tatsächlich besitzen kann. Der Preis ist, dass die Architektur an die Organisation gebunden bleibt — wächst das Unternehmen, muss man den Schnitt nachziehen; schrumpft es, trägt man zu viele Dienste für zu wenige Teams. Anders entscheiden wir, wenn eine rein technische Kraft einen einzelnen Dienst erzwingt, den auch ein kleines Team betreiben kann — dann ist der Schnitt gerechtfertigt, obwohl die Organisation nicht auf breite Verteilung ausgelegt ist.

Technische Voraussetzungen

Man kann nicht sauber schneiden, was man nicht versteht. Die erste technische Voraussetzung sind klare fachliche Grenzen — Bounded Contexts, die im modularen Monolithen bereits als Modulgrenzen existieren. Wer Dienste zieht, bevor die Grenzen verstanden sind, zementiert einen falschen Schnitt in Netz und Betrieb, wo er am teuersten zu korrigieren ist.

Darauf bauen die weiteren Voraussetzungen auf: stabile, versionierte Verträge zwischen den Diensten, damit ein Dienst sich ändern kann, ohne die anderen zu brechen; asynchrone Kommunikation dort, wo enge Kopplung droht, mit idempotenten Empfängern, damit doppelte Zustellung keinen Schaden anrichtet; eigene Datenhaltung je Dienst, denn eine geteilte Datenbank hebt die Grenze wieder auf, die man gerade gezogen hat; und durchgehende Nachverfolgbarkeit über Dienstgrenzen, damit ein Vorgang quer durch das System sichtbar bleibt.

Die Empfehlung: Ziehen Sie einen Dienst erst, wenn seine Grenze im Monolithen erprobt ist und Vertrag, Datenhaltung und Nachverfolgbarkeit stehen. Der Preis ist Vorlaufarbeit, die keinen sichtbaren Fortschritt bringt, bevor der erste Dienst überhaupt existiert. Anders entscheiden wir bei einem Dienst an der klaren Außenkante des Systems — eine Anbindung an einen Fremddienst etwa —, dessen Grenze ohnehin eindeutig ist; dort darf der Schnitt früher fallen, weil das Risiko einer falschen Grenze gering ist.

Betriebliche Voraussetzungen

Der Betriebsaufwand ist der am meisten unterschätzte Teil der Rechnung. Er ist weitgehend fix: Man zahlt ihn, sobald man verteilt, fast unabhängig davon, ob man drei Dienste betreibt oder dreißig. Ein einzelnes Deployable braucht eine Pipeline, ein Logziel, einen Deploy. Verteilte Dienste brauchen mehr, und zwar für jeden Dienst.

Konkret verlangt der verteilte Betrieb: automatisierte Auslieferung und Rückrollung je Dienst; Containerisierung und eine Orchestrierung, die viele Dienste verwaltet; zentrale Logs, Metriken und verteilte Traces, denn ohne durchgehende Beobachtbarkeit ist ein verteiltes System eine Blackbox; Dienstauffindung und Konfiguration; Verwaltung von Geheimnissen über Dienstgrenzen; und einen Bereitschafts- und Incident-Prozess, der mit der Zahl der Dienste mitwächst. Beobachtbarkeit gehört dabei an den ersten Tag, nicht an den ersten Incident.

Die Empfehlung: Verteilen Sie erst, wenn der Betriebsapparat — Pipelines, Orchestrierung, durchgehende Beobachtbarkeit, Rückrollung — nachweislich steht. Der Preis ist eine erhebliche Anfangsinvestition, die sich erst ab einer gewissen Zahl von Diensten und Teams amortisiert. Anders entscheiden wir, wenn eine einzelne Kraft genau einen Dienst erzwingt und der zusätzliche Betriebsaufwand für diesen einen Dienst überschaubar bleibt — dann trägt man die kleine feste Kostenstelle bewusst, statt das ganze System zu verteilen.

Migrationspfad

Der falsche Weg zu Microservices ist derselbe wie der falsche Weg weg vom Legacy-System: der große Neubau. Ein System auf der grünen Wiese in Dienste zu zerlegen bedeutet, Grenzen im Netz festzuschreiben, die man noch nicht verstanden hat — und das gesamte Risiko auf einen Stichtag zu bündeln. Der richtige Weg ist die schrittweise, umkehrbare Extraktion, wie bei jeder Modernisierung.

Er beginnt beim modularen Monolithen mit sauberen Grenzen. Erscheint eine konkrete Kraft — ein Teil muss getrennt skalieren, ein Team muss unabhängig liefern —, löst man genau dieses eine Modul entlang seiner bestehenden Schnittstelle heraus. Weil das Modul schon eine schmale Schnittstelle hat, ist die Extraktion weitgehend mechanisch: Man gibt ihm eigene Daten, ersetzt den bisherigen Funktionsaufruf durch einen Netzaufruf mit seinen Ausfallmodi und stellt genau für diesen Dienst den nötigen Betriebsapparat bereit. Man extrahiert einen Dienst nach dem anderen, beweist jeden im Betrieb und lässt den Rest im Monolithen. So wächst die Verteilung mit den Kräften, statt sie vorwegzunehmen.

Schema: Der modulare Monolith ist die Naht — man extrahiert aus ihm, statt ihn zu ersetzen.

Die Empfehlung: Migrieren Sie durch schrittweise Extraktion einzelner Module, nicht durch einen Big-Bang-Umbau in Dienste. Der Preis ist eine Übergangszeit, in der Monolith und einzelne Dienste koexistieren und gemeinsam betrieben werden müssen. Anders entscheiden wir, wenn das bestehende System keine tragfähigen Grenzen hat, aus denen sich extrahieren ließe — dann zieht man die Grenzen zuerst im Monolithen, bevor überhaupt ein Dienst entsteht, statt entlang eines falschen Schnitts zu verteilen.

Häufige Fehler

Die immer gleichen Muster machen die Verteilung teuer oder gefährlich:

• Der verteilte Monolith: Dienste, die synchron voneinander abhängen und sich eine Datenbank teilen — die Kosten der Verteilung, keiner ihrer Vorteile.
• Schnitt entlang technischer Schichten statt fachlicher Grenzen, sodass jede Fachänderung mehrere Dienste berührt.
• Die geteilte Datenbank, die genau die Grenze wieder aufhebt, die der Schnitt ziehen sollte.
• Nanoservices: so fein zerlegt, dass mehr Aufrufe zwischen Diensten als innerhalb stattfinden.
• Verteilung ohne Beobachtbarkeit — ein System, dessen Vorgänge man über Dienstgrenzen nicht mehr verfolgen kann.
• Der Big-Bang-Umbau in Microservices, der falsche Grenzen im Netz festschreibt.
• Microservices für ein einzelnes Team, das nun mehr Betrieb verwaltet, als es Nutzen zieht.
• Der Netzaufruf, wo ein Funktionsaufruf genügt hätte — Verteilung als Selbstzweck.

Entscheidungs-Checkliste

Fragen, die ein Team vor dem Schnitt stellen kann. Es sind Diagnosefragen, keine Urteile.

• Haben wir die Grenzen zuerst im Monolithen gefunden und erprobt? Was man nicht sauber abgrenzen kann, sollte man nicht verteilen.
• Gibt es eine benannte, gegenwärtige Kraft — Skalierung, Fehlerisolation, Team-Autonomie, Technologie, Compliance? Eine vermutete Zukunft ist keine Kraft.
• Lässt sich dieselbe Kraft im Monolithen beherrschen — mit Cache, Queue oder einem Modul? Wenn ja, kauft der Schnitt nichts.
• Kann unsere Organisation die Dienste tatsächlich besitzen und betreiben? Ohne Eigentümer entsteht ein verteiltes System ohne Verantwortung.
• Steht der Betriebsapparat — Pipelines, Orchestrierung, durchgehende Beobachtbarkeit, Rückrollung? Der feste Betriebspreis fällt sofort an.
• Ist es ein gezielt extrahierter Dienst entlang einer echten Grenze — oder eine Zerlegung des ganzen Systems? Der Schnitt ist selten alles-oder-nichts.
• Können wir die gekaufte Kraft und den gezahlten Preis in einem Satz benennen? Wenn nicht, ist die Entscheidung nicht reif.
• Im Zweifel: Haben wir die umkehrbare Voreinstellung — den modularen Monolithen — gewählt? Eine Grenze im Code ist billiger zurückzunehmen als eine im Netz.

FAQ

Ist der Monolith nicht einfach veraltet? Nein. „Monolith" beschreibt eine Auslieferungstopologie, keine Qualität und kein Alter. Ein modularer Monolith kann sauberer strukturiert sein als ein schlecht geschnittenes Dienstgeflecht. Modern ist nicht, wer verteilt, sondern wer die Komplexität dorthin legt, wo sie am wenigsten kostet.

Erzwingen Microservices nicht besseres Design? Nein. Eine schlecht gezogene Grenze wird durch einen Netzaufruf nicht besser, sondern teurer und schwerer zu korrigieren. Gutes Design entsteht durch verstandene Grenzen — die man im Monolithen genauso ziehen kann, dort aber günstiger wieder verschiebt.

Sollten wir mit Microservices anfangen, um später nicht migrieren zu müssen? Das kehrt die Kosten um. Man zahlt den vollen Betriebs- und Konsistenzpreis sofort und schreibt Grenzen fest, die man am Anfang am wenigsten versteht. Der modulare Monolith ist die günstigere Startaufstellung, gerade weil aus ihm später extrahiert werden kann.

Ist ein modularer Monolith nicht ein Monolith mit Extra-Schritten? Die „Extra-Schritte" sind die Grenzen — und sie sind der ganze Punkt. Sie geben die Modularität, aus der man Nutzen zieht und aus der man später schneiden kann, ohne die Netz- und Betriebskosten der Verteilung vorwegzunehmen.

Wie viele Dienste sind richtig? So wenige, wie die Kräfte verlangen. Die richtige Zahl ergibt sich nicht aus einem Ideal, sondern aus der Zahl der Stellen, an denen eine reale Kraft die Prozessgrenze wertvoller macht als ihren Preis. Oft ist das Ergebnis ein Monolith mit wenigen extrahierten Diensten, nicht ein Feld aus vielen.

Und Serverless-Funktionen? Sie sind eine weitere Stufe auf derselben Achse: noch feinere Verteilung, noch mehr Betrieb im Netz statt im Code. Dieselbe Frage gilt — welche Kraft rechtfertigt die Grenze? Ohne Kraft bleibt auch hier nur der Preis.

Weiterführend

• Software, die in zehn Jahren noch läuft — warum Umkehrbarkeit und Grenzen über die Lebensdauer entscheiden.
• Legacy-Modernisierung ohne Big Bang — die schrittweise Extraktion, auf ganze Systeme angewandt.
• API-Versionierung ohne Kunden zu brechen — die Verträge, ohne die verteilte Dienste nicht tragen.
• Modularer Monolith und Modularer Monolith vs. Microservices — unser Standpunkt und die dokumentierte Entscheidung dazu.

Grundlage ist die Batunet Engineering Method: keine vorzeitige Komplexität, Umkehrbarkeit vor Vorhersage, Grenzen bewusst und in kleinen Schritten.

Es gibt keinen Sieger in dieser Frage — nur ein System, das den Kräften ausgesetzt ist, die auf es wirken, und eine Architektur, die diese Kräfte kennt. Wer den Preis und die Kraft in einem Satz benennen kann, hat richtig entschieden, gleich wie die Antwort lautet.