Monolith oder Microservices: Was die Wahl wirklich kostet

Die Architekturentscheidung, die Jahre nachwirkt

Irgendwann stellt sich jedes Softwareteam dieselbe Frage: Bleiben wir beim Monolithen, oder zerlegen wir das System in Microservices? Die Frage klingt technisch. Sie ist es auch — aber die Antwort hängt weniger von Technologie ab als von Teamgröße, Deploymenthäufigkeit und dem, was man bereit ist zu unterhalten.

Dieser Artikel beschreibt keine Best Practice. Er beschreibt, was die Entscheidung in beide Richtungen tatsächlich kostet — und warum viele Teams die falsche Wahl treffen, weil sie die Kosten zu spät sehen.

Was ein Monolith eigentlich ist — und was nicht

Monolith ist kein Schimpfwort. Ein Monolith ist eine Anwendung, in der alle Komponenten gemeinsam deployed werden: eine Codebasis, ein Deploymentartefakt, eine Datenbank. Nicht zwingend ein großes, unstrukturiertes Chaos — das verwechseln viele.

Ein gut strukturierter Monolith hat klare Modulgrenzen, saubere Abhängigkeiten und eine testbare Architektur. Er ist einfacher zu debuggen, weil ein Stack Trace durch echten Code läuft und nicht durch drei Netzwerkhops und ein Logging-System, das man erst selbst zusammenklöppeln musste.

Die Nachteile werden real, wenn:

mehrere Teams parallel an derselben Codebasis arbeiten und sich gegenseitig blockieren,
Deployments riskant werden, weil alles auf einmal rausmuss,
einzelne Komponenten unter Last stehen, die anderen nicht,
die Build-Zeit so gewachsen ist, dass niemand mehr lokal testet.

Bevor diese Punkte zutreffen, ist der Monolith meist die günstigere Wahl. Nicht weil er besser wäre, sondern weil er weniger kostet.

Was Microservices tatsächlich kosten

Microservices sind eine Verteilungsstrategie. Man zerlegt ein System in eigenständige Dienste, die über Netzwerk kommunizieren und unabhängig deployed werden können. Das klingt sauber. Ist es auch — aber nur, wenn man versteht, was dazugehört.

Betriebsaufwand

Ein Monolith läuft auf einem Server oder in einem Container. Zehn Microservices brauchen zehn laufende Prozesse, zehn Deploymentpipelines, zehn Konfigurationssätze und ein System, das ihnen sagt, wo sie sich gegenseitig finden. Service Discovery, Load Balancing, Health Checks — das ist kein einmaliger Aufwand, sondern dauerhafter Betrieb.

Kubernetes löst das nicht. Kubernetes verwaltet diesen Aufwand — aber es fügt eigene Komplexität hinzu, die man verstehen und unterhalten muss. Wer noch keine Erfahrung mit Container-Orchestrierung hat, kauft sich mit dem ersten Microservice-Cluster ein neues Handwerk ein.

Netzwerk als Fehlerquelle

In einem Monolithen ist ein Methodenaufruf ein Methodenaufruf. In einer Microservice-Architektur ist er ein HTTP-Request oder eine Nachricht in einer Queue. Das Netzwerk lügt manchmal: Timeouts, partielle Zustellungen, Retries, die zu doppelten Verarbeitungen führen. Verteilte Systeme haben ein eigenes Fehlermodell — und wer es nicht kennt, baut Systeme, die unter Last auf unerwartete Weise falsch liegen.

Observability

Wenn ein Fehler in einem Monolithen auftritt, hat man einen Stack Trace. Wenn er in einem Microservice-System auftritt, hat man Logs in zehn verschiedenen Systemen und die Aufgabe, sie mit einer Trace-ID zu korrelieren. Distributed Tracing, zentrales Logging, Metrics-Aggregation — das ist kein Nice-to-have, sondern Betriebsvoraussetzung. Wer das nachrüstet, merkt schnell, dass es nicht wenige Wochen dauert.

Datenkonsistenz

In einem Monolithen mit einer Datenbank macht eine Transaktion, was ihr Name verspricht. In einem verteilten System ist eine Transaktion über Servicegrenzen hinweg ein eigenes Entwurfsproblem. Eventual Consistency klingt wie ein Kompromiss — es ist einer, und er hat Konsequenzen für Fachlogik, die man früh verstehen muss.

Das eigentliche Problem: Komplexität zu früh anfassen

Viele Teams entscheiden sich für Microservices, bevor sie die Probleme haben, die Microservices lösen. Sie lösen damit Probleme, die sie noch nicht haben — und kaufen sich dafür Probleme ein, die sie noch nicht kennen.

Martin Fowler hat das als „Microservice Premium" beschrieben: Der Ansatz funktioniert gut für Systeme, die komplex genug sind, um die Betriebskosten zu rechtfertigen. Für alles darunter ist der Monolith produktiver.

Ein Zeichen dafür, dass ein Team zu früh gewechselt hat: Die Deployments sind häufiger geworden, aber die Releasezyklen nicht kürzer. Man deployed zwar jeden Service einzeln — aber weil die Services sich gegenseitig kennen, testet man sie noch immer gemeinsam. Man hat die Komplexität verteilt, nicht reduziert.

Wann Microservices sinnvoll werden

Es gibt legitime Gründe für eine Serviceorientierung. Sie werden dann sinnvoll, wenn:

Teamgrenzen es verlangen: Conway's Law ist real. Wenn unterschiedliche Teams an denselben Codebereichen arbeiten und sich dabei behindern, sind Servicegrenzen ein Mittel, um Autonomie herzustellen — nicht umgekehrt.
Lastprofile auseinanderfallen: Wenn eine Komponente unter Hochlast steht, die anderen aber nicht, macht es Sinn, sie unabhängig skalierbar zu machen.
Deploymentgeschwindigkeit zum Engpass wird: Wenn Releases gebremst werden, weil eine gemeinsame Codebasis koordiniert werden muss, können Servicegrenzen helfen.
Technologien sich unterscheiden müssen: Wenn eine Komponente eigene Laufzeitanforderungen hat — etwa ein KI-Modell in Python neben einem Web-Backend in TypeScript — ist eine saubere Servicegrenze oft der ehrlichere Weg als ein polyglotter Monolith.

Keiner dieser Punkte gilt pauschal. Aber wenn keiner zutrifft, fehlt die Rechtfertigung.

Die Mitte: Modularer Monolith

Es gibt einen Mittelweg, der in der Diskussion oft untergeht: den modularen Monolithen. Eine Anwendung, die gemeinsam deployed wird, aber intern so strukturiert ist, dass Grenzen zwischen Domänen klar sind — eigene Pakete, keine zirkulären Abhängigkeiten, explizite Schnittstellen zwischen Modulen.

Dieser Ansatz gibt einem die Möglichkeit, Servicegrenzen später zu ziehen, ohne von Anfang an die Betriebskosten zu tragen. Er ist kein Kompromiss zweiter Wahl — er ist für viele Systeme die richtige Wahl, solange die Teamgröße überschaubar bleibt.

Wer in einem solchen System sauber arbeitet, kann einzelne Module später extrahieren, wenn der Bedarf entsteht. Wer ohne Modulgrenzen startet, hat das Problem oft bereits zu groß werden lassen, wenn er anfängt zu fragen.

Was beide Ansätze nicht lösen

Architektur löst keine Disziplinprobleme. Ein Microservice-System mit schlechten Tests ist gefährlicher als ein Monolith mit schlechten Tests — weil Fehler sich verstecken und durch mehr Schichten propagieren können.

Technische Schulden wandern mit. Wenn eine schlecht strukturierte Codebasis in Microservices zerlegt wird, hat man danach mehrere schlecht strukturierte Codebasen. Der Schnitt macht sie nicht besser. Er verteilt sie nur — was Verbesserungen teurer macht, weil man nun in mehreren Repositories Änderungen koordinieren muss.

Das gilt auch für fachliche Klarheit. Wenn die Domänengrenzen in der Anforderungsanalyse unklar sind, werden sie in einer Microservice-Architektur nicht klarer. Schlechte Servicegrenzen — solche, die fachlich nicht stimmen — sind teurer als ein Monolith, weil man sie dauerhaft unter Betriebskosten schleift.

Wer tiefer in die Frage einsteigen will, wie Fachsoftware realistisch bewertet und geplant wird, findet bei Innosirius Einblicke aus laufenden Projekten — ohne Hochglanz.

Eine Heuristik für die Entscheidung

Keine Architekturentscheidung lässt sich ohne Kontext treffen. Aber es gibt eine einfache Frage, die oft hilft: Welches Problem haben wir heute, und ist es konkret genug, um einen Mehraufwand von 30 bis 40 Prozent in Betrieb und Entwicklung zu rechtfertigen?

Diese Schätzung kommt nicht aus einer Studie — sie kommt aus der Praxis. Teams, die von einem gut strukturierten Monolithen auf Microservices wechseln, berichten regelmäßig von deutlich höheren Betriebskosten in der Anfangsphase. Nicht weil der Ansatz falsch ist, sondern weil die Lernkurve und der Infrastrukturaufbau Zeit kosten, die nicht in Features fließt.

Wenn das Problem konkret ist und der Aufwand gerechtfertigt erscheint — gut. Wenn man nach Gründen sucht, um die Entscheidung nachträglich zu begründen, wartet man besser noch.

Was bleibt

Monolith gegen Microservices ist keine technische Wahrheit. Es ist eine Abwägung zwischen Betriebskomplexität und Entwicklungsagilität — und diese Abwägung verändert sich mit dem Alter eines Systems, der Größe des Teams und der Klarheit der Fachdomänen.

Der häufigste Fehler ist nicht die falsche Wahl — sondern die Wahl, bevor die Grundlage für eine informierte Entscheidung besteht. Ein System, das noch nicht zeigt, wo es wächst, kann seine eigenen Grenzen noch nicht kennen. Wer zu früh schneidet, schneidet falsch.

Das lässt sich korrigieren. Aber Migrationen von einer schlechten Microservice-Architektur zurück zu einem strukturierten Monolithen — oder zu einer besseren Verteilung — kosten regelmäßig mehr als die ursprüngliche Entscheidung hätte kosten dürfen. Lieber einmal länger warten und einmal sauberer schneiden.