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.

Damn, das ist cringe: Der Australier Geoffrey Huntley hat die Programmier-KI Claude Code von Anthropic drei Monate in Dauerschleife laufen lassen, um eine eigene Programmiersprache im Stile der verbreiteten Umgangssprache der Generation Z zu entwerfen. Und warum? Nun, weil er es kann, wie er in einem Blogpost darlegt.

Tatsächlich habe ihn einfach die Möglichkeit gereizt, dass mithilfe generativer KI der Traum vom eigenen Compiler Gestalt annehmen kann, schreibt er. Das Ganze sei dann auch ein Lernexperiment gewesen. Der KI sei es dabei selbst überlassen worden, die Sprache jeweils weiter zu verbessern. Das Ergebnis hat er sogar auf einer eigenen Website zum Download bereitgestellt. Der Name der Programmiersprache: Cursed (auf deutsch: verflucht).

Der Compiler verfügt über zwei Modi. Er kann als Interpreter oder als Compiler eingesetzt werden und Binärdateien für macOS, Linux und Windows erstellen. Zudem gebe es halbfertige Erweiterungen für die Editoren VSCode, Emacs und Vim. Wer sich den Entstehungsprozess anschauen möchte, findet dazu entsprechende Videos bei YouTube.

Sprachlich darf man sich das so vorstellen, dass an die Stelle von bekannten Begriffen wie for oder case Wörter treten, die in der GenZ gerne benutzt werden, wie etwa bestie oder mood. Eine Roadmap zur Weiterentwicklung gebe es nicht, darüber soll die Community entscheiden.

Das kostete das Experiment

Der ursprüngliche Prompt lautete: „Hey, kannst du mir eine Programmiersprache wie Golang erstellen, bei der jedoch alle lexikalischen Schlüsselwörter ausgetauscht sind, sodass sie dem Slang der Generation Z entsprechen?“

Wer dem Beispiel von Huntley folgen möchte, sollte allerdings das nötige Kleingeld bereithalten. Der eigene Compiler koste einen etwa 5000 US-Dollar, schreibt er in einem Post auf X. Tatsächlich habe er mit 14.000 US-Dollar fast das Dreifache investieren müssen, da Cursed zunächst in C, dann in Rust und jetzt in Zig entwickelt wurde. Aber so gebe es jetzt eben auch drei Editionen des Compilers. Und am Ende sei das nur ein Vierzehntel des Gehalts eines Entwicklers in San Francisco, scherzt er.

(mki)

Das Entwicklungsteam hinter dem Model Context Protocol (MCP) hat die MCP Registry als Preview eingeführt – einen offenen Katalog und eine API, um öffentlich verfügbare MCP-Server ausfindig zu machen und zu verwenden. Bei MCP handelt es sich um ein offenes Protokoll für den Zugriff von Large Language Models (LLMs) auf externe Datenquellen.

Öffentliche MCP-Server hinzufügen und finden

Bereits vor einigen Monaten teilte das MCP-Team auf GitHub mit, an einem zentralen Register für das MCP-Ökosystem zu arbeiten. Die nun veröffentlichte, quelloffene MCP Registry soll das Verfahren standardisieren, wie MCP-Server verteilt und entdeckt werden. Sie bietet Server-Maintainern die Möglichkeit, ihre Server hinzuzufügen, und Client-Maintainern, auf Serverdaten zuzugreifen.

Um der Registry einen Server hinzuzufügen, muss dieser auf einer Package Registry wie npm, PyPI oder DockerHub veröffentlicht sein. Eine detaillierte Anleitung findet sich auf GitHub. Dort erfahren Developer, wie sie eine server.json-Datei für ihren Server erstellen, Authentifizierung mit der Registry erreichen, ihren Server veröffentlichen und die Veröffentlichung verifizieren können.

Umgang mit Sub-Registries

Wie das MCP-Team betont, soll das zentrale Register als hauptsächliche Source of Truth für öffentlich verfügbare MCP-Server dienen, jedoch den bereits bestehenden Registries von Community und Unternehmen nicht im Weg stehen. Diese können in der MCP Registry öffentliche oder private Sub-Registries anlegen, wie das MCP-Team auf GitHub beschreibt.

Bereits existierende Sammlungen sind etwa eine lange, gepflegte Liste auf GitHub und ein Docker-Verzeichnis für MCP-Quellen.

Da es sich bei der MCP Registry derzeit um eine Preview handelt, gibt es keine Garantie für die Beständigkeit der darin enthaltenen Daten. Auch sind Breaking Changes möglich, bevor die Registry die allgemeine Verfügbarkeit erreicht.

Weitere Informationen sind auf dem MCP-Blog zu finden.

(mai)