Microservices vs Monolith: Wann sich der Umbau wirklich lohnt

Microservices waren jahrelang das Synonym für moderne Softwareentwicklung. Wer als Architekt 2018 nicht in Microservices dachte, galt als rückständig. Inzwischen ist der Hype abgekühlt, und das aus guten Gründen.

Das prominenteste Beispiel hat Amazon selbst geliefert. Das Team rund um Prime Video Video Quality Analysis hat seinen Monitoring-Service im März 2023 von einer Microservice-Architektur zurück auf einen Monolithen umgebaut und damit die Infrastrukturkosten um rund 90 Prozent gesenkt. Das war keine grundsätzliche Abkehr von Microservices bei Amazon, sondern ein Eingeständnis: Für diesen konkreten Service war der Monolith die bessere Wahl. Und genau das ist der Punkt, den die meisten Diskussionen verfehlen.

Was Monolith und Microservices wirklich unterscheidet

Ein Monolith ist eine Anwendung, die als ein einziges Deployment-Paket gebaut, getestet und ausgerollt wird. Eine Code-Basis, eine Datenbank, ein Prozess. Das klingt nach 2005 und ist es nicht. Auch moderne Monolithen können modular aufgebaut sein, mit klaren Schnittstellen zwischen Modulen, eigenen Tests pro Domäne und sauberer Trennung der Verantwortlichkeiten.

Microservices teilen die Anwendung in viele kleine, unabhängig deploybare Dienste auf. Jeder Dienst hat im Idealfall seine eigene Datenbank, sein eigenes Team und seinen eigenen Release-Zyklus. Die Kommunikation läuft über das Netzwerk, meistens über REST, manchmal über Message-Queues wie Kafka oder RabbitMQ.

Der Unterschied ist nicht die Code-Struktur, sondern wie und wann Komponenten deployt werden. Ein Monolith muss komplett deployt werden, auch wenn nur eine Zeile geändert wurde. Microservices erlauben dir, ein Modul auszurollen, während andere weiterlaufen.

Wann sich der Umbau wirklich lohnt

Die ehrliche Antwort: seltener, als die meisten denken. Microservices machen Sinn, wenn drei Bedingungen zusammenkommen.

Du hast unabhängige Skalierungsbedürfnisse. Dein Checkout-Service muss am Black Friday das Zehnfache verkraften, deine Produktsuche nicht. Bei einem Monolithen skalierst du immer alles, bei Microservices nur den Teil, der es braucht. Das spart bei wirklich großen Lastunterschieden viel Geld. Bei kleinen oder mittleren Lasten kostet die zusätzliche Komplexität mehr, als sie einspart.

Du hast getrennte Teams mit getrennten Zyklen. Wenn dein Zahlungsteam alle zwei Wochen released, dein Logistikteam aber nur quartalsweise, helfen Microservices, dass beide ihren eigenen Takt halten. Sobald aber alle in einem Repo arbeiten und im selben Sprint releasen, ist die Trennung künstlich.

Du hast DevOps-Kompetenz im Haus. Microservices ohne ordentliche Pipelines, Monitoring, zentrale Log-Aggregation und Tracing sind kein Fortschritt, sondern ein Albtraum. Wer kein Team hat, das mit Kubernetes, Service-Meshes und verteilter Beobachtbarkeit umgehen kann, scheitert spätestens nach dem dritten Service.

Eine Auswertung, die in der Architektur-Community 2025 viel zitiert wurde, zeigt: 67 Prozent der Unternehmen erlebten beim Migrieren zu Microservices höhere Betriebskosten als vorher. Nur 38 Prozent der Startups, die mit Microservices anfingen, würden diesen Weg wieder gehen. Die Botschaft ist nicht „Microservices sind schlecht”. Sie ist „Microservices sind teuer, und du brauchst die Vorteile, die das rechtfertigen”.

Wann der Umbau fast immer ein Fehler ist

Drei Konstellationen sehen wir in Projekten regelmäßig, in denen Microservices die falsche Antwort sind.

Kleines Team, große Architektur. Wer mit fünf Entwicklern zehn Services betreibt, verbringt mehr Zeit mit Infrastrukturpflege als mit Features. Die Faustregel ist nicht festgemeißelt, aber unter rund 30 bis 50 Entwicklern lohnt sich der Aufwand selten.

Unklare Domänengrenzen. Wenn du selbst nicht weißt, wo ein Service aufhört und der nächste anfängt, baust du am Ende einen verteilten Monolithen. Alle Services rufen sich gegenseitig synchron auf, eine Änderung in einem zwingt zu Anpassungen in drei anderen. Du hast alle Nachteile eines Monolithen plus alle eines verteilten Systems.

Niemand kennt Domain-Driven Design. Microservices funktionieren nur, wenn die Aufteilung den fachlichen Bereichen folgt, nicht den technischen Schichten. Wer einen Service je für Frontend, Backend und Datenbank baut, hat Microservices nur dem Namen nach. Die Konsequenz ist immer dieselbe: Latenz, Komplexität, Frust.

Ehrlich gesagt, der häufigste Fehler ist nicht die Architekturentscheidung selbst, sondern dass sie zu früh getroffen wird. Erst das Geschäft verstehen, dann die Domänen modellieren, dann entscheiden, wie man deployt.

Die dritte Option: Modular Monolith

Zwischen klassischem Monolith und vollständigen Microservices hat sich in den letzten Jahren der Modular Monolith etabliert. Das Konzept: Du baust eine einzige Anwendung, aber strukturierst sie intern in klar getrennte Module mit eigenen Schnittstellen und Datenbereichen. Spring hat dafür mit Spring Modulith ein eigenes Framework, .NET-Welt nutzt vermehrt Vertical Slice Architecture mit ähnlichem Effekt.

Was du gewinnst: Die Vorteile eines Monolithen (einfacher Deploy, ein Testlauf, kein Netzwerk zwischen Modulen) bleiben. Gleichzeitig hast du saubere Grenzen, die du später einfach in Microservices überführen kannst, wenn das Geschäft es wirklich verlangt. Du musst nicht im Voraus raten, welche Teile sich auseinander entwickeln werden.

Für die meisten KMU und auch viele größere Mittelständler ist das die pragmatischste Wahl. Du sparst dir den DevOps-Overhead, behältst aber die Option, später zu splitten. Kein Lock-in in eine Architektur, die in zwei Jahren nicht mehr passt.

Häufige Fallen beim Umbau

Wer doch den Schritt zu Microservices wagt, läuft in ein paar typische Probleme.

Der verteilte Monolith. Du hast zwölf Services, die alle dieselbe Datenbank nutzen oder synchron miteinander reden. Eine Änderung im einen erzwingt einen Release im anderen. Du hast das Schlechteste aus zwei Welten kombiniert. Erkennbar ist das daran, dass deine Deploys weiterhin synchronisiert laufen müssen.

Datenbank pro Service ohne Plan. „Jeder Service seine eigene Datenbank” klingt gut, bringt aber sofort die Frage: Wie funktionieren Transaktionen, die mehrere Services betreffen? Wer keine Antwort hat (Saga-Pattern, Outbox-Pattern, Eventual Consistency akzeptieren), produziert Inkonsistenzen, die der Kunde später als Bug meldet.

Monitoring kommt zuletzt. Bei einem Monolithen kannst du Bugs noch im Log finden. Bei Microservices brauchst du verteiltes Tracing, sonst weißt du bei einem Fehler nicht einmal, in welchem Service er passiert ist. Wer das nachträglich einbaut, zahlt das Mehrfache.

Was du jetzt entscheiden kannst

Wenn du heute vor einer Architekturentscheidung stehst, frag dich vor allem das: Hast du echte Skalierungs- oder Organisationsprobleme, die ein Monolith nicht lösen kann? Wenn nein, bleib monolithisch und mach es modular. Wenn ja, fang trotzdem mit zwei oder drei Services an, nicht mit zwölf, und entscheide nach drei Monaten Betrieb, ob du weiter aufteilst.

Was du vermeiden willst: Eine Architekturwahl, die das Team in den nächsten zwei Jahren mehr Zeit kostet als die eigentliche Geschäftslogik. Software muss dein Geschäft tragen, nicht umgekehrt. Wer das vergisst, baut beeindruckende Diagramme und liefert wenig.

Wir helfen bei individueller Softwareentwicklung und bei Architektur-Audits bestehender Systeme. Wenn du nicht sicher bist, ob euer aktueller Stack noch trägt oder ob ein Umbau Sinn ergibt, bekommst du in einer Fokus-Session eine ehrliche Einschätzung. Lieber 45 Minuten klares Bild als monatelang das Falsche bauen.