Was ist ein modularer Monolith?

Eine einzige auslieferbare Anwendung, deren Code in klar getrennte Module mit definierten Schnittstellen aufgeteilt ist, etwa Abrechnung, Benutzer und Katalog. Module greifen nicht direkt auf die Daten anderer Module zu. So bleibt die Einfachheit eines Deployments erhalten, und eine spätere Aufteilung wird vorbereitet.

Wann sollten wir einen Microservice abspalten?

Wenn ein konkretes Problem es rechtfertigt: Eine Komponente skaliert ganz anders, ein eigenes Team braucht einen eigenen Release-Takt, oder ein Teil muss aus Sicherheits- oder Compliance-Gründen isoliert laufen. „Weil es modern ist“ zählt nicht.

Sind Microservices ausfallsicherer?

Nicht von selbst. Sie können Fehler eingrenzen, bringen aber neue Fehlerarten wie Netzwerk-Timeouts und Teilausfälle mit. Zuverlässigkeit entsteht durch Timeouts, Wiederholungen, Monitoring und Tests, egal welche Architektur.

Kann ein Monolith skalieren?

Ja. Mehrere Instanzen derselben Anwendung laufen hinter einem Load Balancer, die Datenbank wird separat skaliert. Viele große Webanwendungen laufen jahrelang als Monolith.

Microservices oder Monolith? Entscheidungshilfe

Für die meisten kleinen und mittleren Teams ist ein modularer Monolith die bessere Wahl: eine Anwendung, ein Deployment, aber mit sauberen inneren Grenzen. Microservices lohnen sich, wenn mehrere Teams unabhängig voneinander ausliefern müssen oder Teile des Systems sehr unterschiedlich belastet werden. Die Entscheidung hängt weniger an der Technik als an Teamstruktur und Betriebsaufwand.

Drei Modelle

Monolith: Die gesamte Anwendung wird als eine Einheit gebaut, getestet und ausgeliefert, meist mit einer gemeinsamen Datenbank. Aufrufe zwischen Teilen sind Funktionsaufrufe im selben Prozess.

Microservices: Die Anwendung zerfällt in kleine Dienste mit eigener Codebasis, eigener Pipeline und idealerweise eigenem Datenspeicher. Sie sprechen über das Netzwerk miteinander, per HTTP-API oder Message Queue.

Modularer Monolith: der Mittelweg. Eine auslieferbare Einheit, intern aber in Module mit klaren Schnittstellen geteilt, ohne gegenseitigen Zugriff auf Tabellen. Für die meisten Teams der praktikabelste Einstieg.

Gegenüberstellung

Aspekt	Monolith (modular)	Microservices
Deployment	eine Pipeline, ein Artefakt	eine Pipeline je Dienst
Lokale Entwicklung	eine App starten	viele Dienste oder Mocks starten
Aufrufe zwischen Teilen	im Prozess, schnell, transaktional	über das Netz, können scheitern oder hängen
Datenkonsistenz	eine Datenbank, Transaktionen	verteilte Daten, eventual consistency
Skalierung	ganze App skaliert gemeinsam	jeder Dienst einzeln
Teamautonomie	gemeinsame Codebasis, abgestimmte Releases	Teams besitzen und releasen ihre Dienste
Betrieb	wenige bewegliche Teile	Orchestrierung, Service Discovery, Tracing
Passt zu	einem oder wenigen Teams	vielen Teams, großen Systemen

Was Microservices wirklich kosten

Aufteilen beseitigt keine Komplexität, es verlagert sie in die Infrastruktur. Jeder zusätzliche Dienst braucht Build, Deployment, Konfiguration, Logging, Metriken und Alarmierung. Aus Funktionsaufrufen werden Netzwerkanfragen mit Timeouts, Wiederholungen und versionierten APIs. Eine Transaktion über zwei Dienste ist keine Datenbanktransaktion mehr, sondern ein Koordinationsproblem.

In der Praxis braucht eine Microservice-Architektur deshalb eine Plattform, meist Kubernetes samt Werkzeugen für Observability. Für ein Team aus drei bis zehn Entwicklern frisst dieser Überbau schnell mehr Zeit, als er spart. Leichtere Wege zeigt Container-Deployment für kleine Teams.

Wann Microservices passen

Microservices sind sinnvoll, wenn mehrere dieser Punkte zutreffen:

Mehrere Teams arbeiten am System und blockieren sich mit gemeinsamen Releases.
Stark unterschiedliche Last: Eine Komponente, etwa die Bildverarbeitung, braucht ein Vielfaches der Ressourcen des Rests.
Andere technische Anforderungen: Ein Teil braucht eine andere Sprache, Laufzeit oder Hardware, zum Beispiel GPUs.
Isolation: Eine Komponente verarbeitet besonders schutzbedürftige Daten und soll mit eigenen Zugriffsregeln getrennt laufen.
Reifer Betrieb: Automatische Deployments, zentrales Logging, Tracing und Bereitschaftsdienst sind schon etabliert.

Trifft nichts davon zu, ist der Monolith kein Kompromiss, sondern die wirtschaftlichere Wahl. Gerade im Mittelstand, wo oft ein kleines Team eine Fachanwendung über Jahre pflegt, ist das der Normalfall.

Eine einfache Faustregel

Architektur folgt Organisation. Wer ein Team hat, kommt mit einer auslieferbaren Einheit am weitesten. Wächst die Entwicklung auf mehrere Teams mit getrennten Zuständigkeiten, werden diese Zuständigkeiten zu natürlichen Kandidaten für eigene Dienste. Fragen Sie deshalb vor jeder Aufteilung: Welches Team besitzt diesen Dienst künftig, wer hat nachts Bereitschaft, und welches Problem lösen wir damit, das wir heute messbar haben? Gibt es auf eine dieser Fragen keine klare Antwort, ist es für die Aufteilung zu früh.

So gelingt ein modularer Monolith

Module nach Fachlichkeit schneiden, nicht nach technischen Schichten. „Bestellungen“, „Abrechnung“ und „Kunden“ sind Module, „Controller“ und „Repositories“ nicht.
Öffentliche Schnittstellen festlegen und direkten Zugriff auf Interna oder Tabellen anderer Module verbieten.
Datenhoheit klären: Jede Tabelle gehört genau einem Modul.
Tests und Deployment automatisieren, von Anfang an, wie unter Was bedeutet Cloud-native? beschrieben.
Messen: Logs und Metriken je Modul zeigen früh, welcher Teil später ein eigener Dienst werden könnte.

Mit diesen Regeln wird das spätere Herauslösen eines Moduls zu einem überschaubaren Projekt statt zu einer Neuentwicklung.

Wo der Monolith läuft

Ein Monolith im Container läuft gut auf einem PaaS, das aus Git baut, ausliefert und über zusätzliche Instanzen skaliert. Welche Betriebsform passt, klärt PaaS, IaaS oder Serverless?. Werden später Dienste abgespalten, kann dasselbe PaaS sie oft ebenfalls betreiben, lange bevor Kubernetes nötig wird. Einen Einstieg in das Modell bietet Was ist PaaS?.

Der Weg zurück

Manche Teams, die mit Microservices begonnen haben, führen Dienste wieder zusammen, weil der Aufwand den Nutzen übersteigt. Das ist eine legitime Entscheidung. Beginnen Sie mit Diensten, die sich immer gemeinsam ändern und Daten teilen, liefern Sie sie als Einheit aus und behalten Sie die Modulgrenzen im Code bei.