Warum viele Teams mit Monolithen besser fahren als mit Micro-Frontends

Softwarearchitektur kennt Moden und Gegenbewegungen. Frontends in winzige unabhängige Teile zu zerschneiden, galt in den letzten Jahren als modern: Micro-Frontends und Microservices. Heute zeigt sich: Der Ansatz bleibt wertvoll. Aber nur dort, wo er die organisatorische Realität tatsächlich abbildet. Für viele kleine bis mittlere Teams ist ein modularer Monolith oft die robustere Startarchitektur.

State of Frontend

Die internationale Umfrage State of Frontend des Unternehmens The Software House zeigt eine klare Bewegung: 2022 gaben 75,4 Prozent der Befragten an, Micro‑Frontends zu nutzen. 2024 waren es nur noch 23,6 Prozent. Das klingt auf den ersten Blick dramatisch, ist aber kein Tod der Idee. Der Rückgang zeigt, dass viele Teams Micro-Frontends nicht mehr als Standardlösung betrachten, sondern selektiv dort einsetzen, wo organisatorische oder architektonische Gründe es rechtfertigen. Denn parallel dazu steigt die Popularität von Module Federation, und zwar nicht nur für Micro‑Frontends: 2024 berichten 51,8 Prozent die Nutzung, oft auch in monolithischen Anwendungen, um Teile unabhängig zu aktualisieren. Das stützt die These einer Konsolidierung auf weniger Deployment-Einheiten bei weiterhin modularer Struktur.

Bemerkenswert ist, dass auch KI Microservices favorisiert: Fragt man ChatGPT ohne Kontext nach Architekturmustern, empfiehlt es fast immer Microservices und oft auch Micro-Frontends. Das ist kein Indiz für universelle Richtigkeit, sondern für den Hype-Bias in den Trainingsdaten. Ohne fachliche Einordnung bleibt es eine Wahrscheinlichkeitsaussage und ersetzt nicht die Analyse eines erfahrenen Architekten oder einer erfahrenen Architektin.

Warum der Micro-Frontend-Hype abkühlt

Micro-Frontends entstanden als Analogie zu Microservices und erfreuen sich nicht ohne Grund großer Beliebtheit. Die Idee besteht darin, schwerfällige SPAs oder Webportale in kleine, autonome Apps aufzuteilen. Jedes Team kann sein Stück mit dem Lieblingsframework entwickeln und unabhängig deployen. Das reduziert den Koordinationsaufwand, vermeidet monolithische Rebuilds und erlaubt, Teile des Frontends asynchron zu laden.

In der Praxis führt diese Freiheit jedoch auch oft zu neuen Problemen: Mehrere Frameworks oder UI-Bibliotheken erhöhen die Downloadgröße und verlängern die Time to Interactive, globale Stores oder Shells schaffen den berüchtigten Hidden Monolith oder verteilten Monolithen, in dem Micro-Apps weiterhin denselben Zustand teilen, und zusätzliche Deployments erzeugen Overhead bei CI/CD, Feature Flags und Versionierung.

Micro‑Frontends eignen sich, wenn wirklich unabhängige Teams und heterogene Stacks aufeinandertreffen, etwa bei Tech‑Riesen wie Amazon oder Spotify. In sehr vielen Projekten erzeugt die zusätzliche Orchestrierung jedoch mehr Probleme, als sie löst und sorgt schnell für komplexe Builds und längere Ladezeiten. Gerade bei kleineren Teams und klar abgegrenzten Produkten übersteigt der Aufwand den Nutzen, und die erhoffte Entkopplung bleibt aus. Oft entsteht faktisch ein verteilter Monolith mit zahlreichen Teilprojekten, die doch nur gemeinsam leben können. Eine fatale Entwicklung, denn der verteilte Monolith vereint oft die schlechtesten Eigenschaften beider Welten in sich.

Monolith vs. Microservices vs. Serverless

Die Debatte über Monolithen und Microservices krankt oft daran, dass Begriffe nicht klar sind. Ein Beitrag auf dem Dev-Details-Blog erläutert anschaulich, dass die Einordnung nicht von der Anzahl der Repositories, Container oder Teams abhängt:

• Ein Monolith entsteht, wenn mehrere Teile so eng gekoppelt sind, dass sie nur gemeinsam deployt werden können.
• Microservices wiederum zeichnen sich durch lose Kopplung und hohe Kohäsion aus. Sie können Daten und Ressourcen mit anderen Diensten teilen, solange jede Komponente ihre eigene Verantwortung behält.
• Serverless bedeutet nur, dass die Infrastrukturverwaltung abstrahiert wird. Es ist kein Synonym für Function as a Service. Entscheidend ist, dass sich die Teams nicht um Server kümmern müssen und nur für tatsächliche Nutzung bezahlen.

Diese Perspektive hilft, Modebegriffe zu entmystifizieren. Man kann monolithische, Microservices‑basierte oder Serverless-Architekturen mischen – entscheidend ist, wie stark die Komponenten voneinander abhängen. Wenn mehrere Services stets gemeinsam deployt werden müssen, entsteht faktisch wieder ein „verteilter Monolith“.

Das Fallbeispiel Amazon Prime Video

Oft zitiert wird das Team hinter Amazon Prime Video, wie auch bereits auf heise berichtet. Es hat 2023 die Audio/Video-Monitoring-Komponente von einem Step-Functions-getriebenen verteilten Design auf ein monolithisches Prozessdesign umgestellt, was zu über 90 Prozent geringeren Kosten und höherer Skalierbarkeit für diese Komponente führte.

Das ist keine Abkehr von Microservices im gesamten Produkt, aber eine klare kontextspezifische Optimierung: weniger Netzwerk-Hops, wegfallender S3-Zwischenspeicher und weniger Orchestrierungs-Overhead.

Ein hervorragendes Beispiel dafür, dass Architektur keinem Etikett folgen sollte, sondern in diesem Fall dem Lastprofil und Coupling. Microservices und Serverless sind Werkzeuge, die bei passender Problemklasse hervorragend funktionieren; andernfalls ist ein enger gekoppelter Entwurf aber günstiger und einfacher zu betreiben.

Einfachheit schlägt Cleverness: Lehren aus Code‑Audits

Praktische Erfahrungen bestätigen diese Sicht: Ken Kantzer, VP Engineering bei FiscalNote und Gründer der Sicherheits- und Architekturberatung PKC Security, hat in über zwanzig Code-Audits von Start-ups wiederkehrende Muster identifiziert. Sein Befund: Die erfolgreichsten Unternehmen hielten ihre Architektur bewusst einfach. Teams, die konsequent nach dem Prinzip „Keep it simple“ arbeiteten, dominierten später ihre Märkte.

Demgegenüber verschwanden viele Firmen, die sich früh in komplexe Architekturexperimente stürzten. Kantzer hält die vorzeitige Umstellung auf Microservices, stark verteilte Systeme und Messaging-lastige Designs für eine eine selbst verschuldete Falle, die Teams in unnötige Betriebs- und Entwicklungsprobleme manövriert. In seinen Audits zeigte sich, dass solche Systeme einen Großteil der Entwicklerzeit mit Queue-Fehlern, Versionsinkompatibilitäten und Netzwerk-Latenzen blockierten, während die eigentliche Produktentwicklung ins Stocken geriet.

Die Lehre: Komplexität ist keine Investition in Zukunftsfähigkeit, wenn sie dem Kontext vorauseilt – sie ist ein Kostenfaktor, der den Markterfolg gefährden kann.

Modularer Monolith: Bewährtes Konzept mit Renaissance

Der modulare Monolith oder auch Modulith vereint die Vorteile von Monolith und Microservices: Die Anwendung wird in klar abgegrenzte Module unterteilt, die sich intern unabhängig entwickeln, testen und versionieren lassen, aber gemeinsam deployed werden. Thoughtworks beschreibt ihn als „best of both worlds“: Es gibt weniger bewegliche Teile, einfache Deployments und geringere Infrastrukturkosten, während eine klare Aufteilung in Module dennoch möglich ist. Durch die gemeinsame Deployment-Einheit entfallen Gateways, Service Discovery und verteiltes Logging. Das verbessert die Performance, da Module über Funktionsaufrufe statt über das Netzwerk kommunizieren und das System bei Ausfall eines Moduls nicht sofort fragmentiert. Gleichzeitig lassen sich klare Teamgrenzen und Domänen definieren, sodass Entwickler ein Modul später relativ leicht ausgliedern können.

Eine praktische Entscheidungshilfe in Tabellenform stellen die Architekturexperten hinter der Toolsuite Ptidej zur Verfügung. Microservices bieten Vorteile, wenn autonome Teams mit eigenen Releasezyklen an unterschiedlichen Teilen eines großen Systems arbeiten, wenn einzelne Komponenten sehr unterschiedlich skalieren oder wenn verschiedene Technologien notwendig sind. Ein Monolith hingegen genügt, wenn das Team überschaubar ist, die Domäne klar umrissen und die Skalierungsanforderungen homogen sind. Wichtig ist, dass das System modular bleibt, damit es sich bei Bedarf später in Microservices zerlegen lässt.

Der modulare Monolith bietet somit einen pragmatischen Mittelweg: Er teilt eine Anwendung in klar abgegrenzte Module, deployt sie aber gemeinsam. Im Python/Django-Umfeld ist das Prinzip seit Jahren gelebte Praxis („Apps“ als Modulgrenzen), auch wenn es dort nicht Modulith heißt.

Thoughtworks empfiehlt, mit einem solchen Monolithen zu starten und erst nach gründlichem Verständnis der Geschäftsprozesse einzelne Module auszulagern. Die Vorteile sind klar: einfache Deployments, gute Performance, niedrigere Betriebskosten und weniger Latenz.

Monorepos: Modularisieren ohne Zerreißen

Moderne Monorepo‑Werkzeuge senken die Reibung größerer Codebasen: Nx etwa bietet Computation Caching (lokal und remote) und „Affected“‑Mechaniken, sodass bei Änderungen nur die betroffenen Projekte gebaut und getestet werden. Das senkt Build‑ und CI‑Zeiten drastisch und macht ein Repo mit vielen Modulen praktikabel.

Interessant ist, dass Nx explizit dokumentiert, dass Micro‑Frontends vor allem dann empfehlenswert sind, wenn unabhängiges Deployment wirklich notwendig ist. Andernfalls lassen sich dieselben Build‑Effekte zunehmend auch ohne Micro-Frontend‑Architektur erzielen (etwa Module Federation nur zur Build‑Beschleunigung).

Entscheidungsrahmen: Architektur vom Kopplungsgrad ableiten

Aus Daten, Praxisberichten und Werkzeugtrends lassen sich pragmatische Leitlinien ableiten:

1. Für die meisten kleinen bis mittleren Teams ist ein modularer Monolith der schnellste Weg zu Features und Feedback. Er reduziert Kosten, minimiert Betriebsrisiken und bleibt evaluierbar.
2. Wenn Komponenten immer gemeinsam deployt werden müssen, ist die Anwendung monolithisch – unabhängig davon, auf wie viele Container oder Repos sie verteilt ist. Umgekehrt sind Microservices erst dann sinnvoll, wenn Deployments wirklich unabhängig sind.
3. Verteilte Systeme erkauft man sich mit Betriebskosten: Observability, Versionierung, Backward Compatibility, Netzwerklatenz, CAP‑Trade‑offs (Abwägungen zwischen Konsistenz, Verfügbarkeit und Partitionstoleranz). Wer diese Reife nicht hat oder nicht braucht, verliert Zeit und Fokus aufs Produkt. Genau das zeigen Code‑Audits aus der Start‑up‑Praxis.
4. Was in einem Konzern mit Dutzenden Teams sinnvoll ist, ist für ein Team mit zehn Leuten häufig Overkill. Architektur folgt Teamschnitt und Geschäftsprozess, nicht dem Blog‑Hype. Der Artikel auf Heise hat das am Prime‑Video‑Beispiel sorgfältig eingeordnet (Stichwort Modulith).
5. Werden einzelne Module zu Engpässen (abweichender Release‑Rhythmus, stark abweichende Last, anderes Team), lassen sie sich sauber herauslösen. Ohne vorzeitige Zersplitterung bleibt die Komplexität beherrschbar.