Verteilte Architekturen galten lange als Mittel zum Zweck. IT-Teams setzten sie dort ein, wo Skalierbarkeit, Ausfallsicherheit oder organisatorische Anforderungen den zusätzlichen Aufwand rechtfertigten. In vielen heutigen IT-Landschaften ist eine verteilte Architektur jedoch zum Standard geworden – häufig unabhängig davon, ob der konkrete Anwendungsfall diese Komplexität tatsächlich erfordert.

Warum moderne Architekturen häufig unnötig komplex sind

Aktuelle Entwicklungen deuten auf ein Umdenken hin. Ein erheblicher Teil der Unternehmen verlagert Teile seiner Workloads aus Public-Cloud-Umgebungen zurück in private Infrastrukturen oder stärker kontrollierte Betriebsmodelle. Ausschlaggebend sind dabei weniger funktionale Einschränkungen als vielmehr die im Betrieb gewachsene Komplexität. Cloudarchitekturen, die ursprünglich Agilität und Effizienz versprachen, erschweren im Alltag zunehmend Transparenz, Wartbarkeit und Kostenkontrolle.

Phänomene wie die sogenannte Microservices-Falle entstehen selten durch einzelne Fehlentscheidungen. In der Praxis führen schrittweise eingeführte Konzepte wie Containerisierung, Orchestrierung, Service-Zerlegung und Multicloudstrategien zu einer Verdichtung technischer Abhängigkeiten. Diese erschwert es, Verantwortlichkeiten klar zuzuordnen, Deployments kontrolliert durchzuführen und Kosten belastbar zu planen. Der Beitrag ordnet diese Entwicklung im Folgenden ein und zeigt auf, warum der "modulare Monolith" in vielen Szenarien einen pragmatischen Gegenentwurf darstellt.

Von der Cloudeuphorie zur Betriebsrealität

Den Ausgangspunkt heutiger Cloudarchitekturen bildet eine Phase grundlegender technologischer und ökonomischer Veränderungen. Mit der Einführung von AWS EC2 im Jahr 2006 wurde Infrastruktur erstmals nutzungsbasiert und ohne Vorabinvestitionen verfügbar. Unternehmen konnten Rechenleistung flexibel beziehen, während Hyperscaler durch aggressive Preissenkungen, insbesondere im Storage-Bereich, erhebliche Kostenvorteile versprachen.

Parallel dazu entwickelten sich Virtualisierung und Containerisierung weiter. Anwendungen mussten nicht länger an physische Server gebunden sein, sondern ließen sich in abstrahierte, flexibel skalierbare Einheiten überführen. Docker etablierte Container als Standard, Kubernetes übernahm die Orchestrierung im großen Maßstab. In diesem Umfeld gewann die Zerlegung von Systemen in Microservices an Bedeutung, da sie unabhängigere Entwicklungs- und Deploymenteinheiten versprach.

Mit der zunehmenden Verbreitung von Multicloud-Strategien wuchs jedoch auch die operative Komplexität. Viele Organisationen kombinierten unterschiedliche Cloudanbieter, um regulatorische Anforderungen zu erfüllen oder Abhängigkeiten zu reduzieren. In der Praxis entstanden dadurch heterogene Plattformen mit zahlreichen Schnittstellen, Betriebsmodellen und Abrechnungslogiken. Gleichzeitig veränderten sich die wirtschaftlichen Rahmenbedingungen: Preissenkungen stagnierten, Egress-Gebühren erschwerten den Anbieterwechsel, und komplexe Preismodelle machten eine verlässliche Kostenkontrolle zunehmend anspruchsvoll.

Zusätzlich verstärken regulatorische und geopolitische Faktoren diese Entwicklung. Spannungen zwischen europäischen Datenschutzanforderungen und US-amerikanischen Gesetzen wie dem CLOUD Act führen dazu, dass Unternehmen ihre Cloudstrategien neu bewerten. Initiativen zur Stärkung europäischer Cloudangebote konnten diese Abhängigkeiten bislang nur begrenzt reduzieren.

Das Ergebnis ist eine Cloudbetriebsrealität, in der technische Möglichkeiten schneller gewachsen sind als organisatorische und operative Strukturen. Viele IT-Abteilungen betreiben heute Systeme, die theoretisch hochskalierbar sind, im Alltag jedoch einen erheblichen Koordinations-, Tooling- und Kostenaufwand erfordern.

Wann Microservices zur Falle werden

Ob eine Architektur zu komplex ist, lässt sich weniger an der Anzahl eingesetzter Technologien erkennen als an ihrer praktischen Beherrschbarkeit im Alltag. Ein zentrales Indiz ist die Nachvollziehbarkeit von Anfragen innerhalb des Systems. Wenn bereits das einfache Nachverfolgen eines Requests mehrere spezialisierte Tools erfordert – etwa verteiltes Tracing, zentrale Logsysteme und zusätzliche Orchestrierungsansichten – deutet dies auf eine Architektur hin, deren operative Komplexität den eigentlichen Nutzen überlagert.

Ein weiteres Warnsignal zeigt sich bei der Umsetzung fachlicher Änderungen. Werden selbst überschaubare Funktionserweiterungen über mehrere Services hinweg verteilt, entstehen Abhängigkeiten, die koordinierte Deployments und aufwendige Integrationstests erforderlich machen. Technisch getrennte Komponenten bilden dann keine fachlich sinnvollen Grenzen mehr ab, sondern fragmentieren zusammengehörige Geschäftsprozesse. Änderungen verlangsamen sich, Fehlersuche wird aufwendiger, und die Fehlertoleranz des Gesamtsystems sinkt.

Auch die Verständlichkeit der Gesamtarchitektur spielt eine zentrale Rolle. Wenn neue Teammitglieder mehrere Wochen benötigen, um den Weg einer Anfrage durch das System zu verstehen, liegt die Ursache häufig nicht in fehlender Dokumentation, sondern in einer übermäßig feingranularen Service-Zerlegung. Mit wachsender Anzahl verteilter Komponenten steigt der kognitive Aufwand, Zusammenhänge zu erfassen und Auswirkungen von Änderungen korrekt einzuschätzen.

Zusätzliche Komplexität entsteht durch technologische Heterogenität. Der parallele Einsatz mehrerer Programmiersprachen, Frameworks und Laufzeitumgebungen mag kurzfristig flexibel erscheinen, führt langfristig jedoch zu Wissenssilos, erschwerten Code-Reviews und steigenden Anforderungen an Betrieb und Wartung. Was als technologische Vielfalt beginnt, entwickelt sich im Betrieb häufig zu einem Produktivitätshemmnis.

Diese Faktoren treten selten isoliert auf. In Kombination verstärken sie sich gegenseitig und führen zu einer Situation, in der Microservices nicht mehr zur Entkopplung beitragen, sondern neue Abhängigkeiten schaffen. Die Architektur wird damit zum limitierenden Faktor für Weiterentwicklung, Stabilität und Kostenkontrolle.

Erste Schritte zur Konsolidierung

Bevor neue Funktionen oder weitere Services hinzukommen, empfiehlt sich eine Phase der Stabilisierung. In komplexen Systemlandschaften erhöht jede zusätzliche Änderung das Risiko, bestehende Abhängigkeiten weiter zu verfestigen. Eine temporäre Fokussierung auf Analyse und Konsolidierung schafft die Grundlage, um strukturelle Probleme gezielt anzugehen, statt sie weiter zu überdecken.

Ein zentraler Ansatzpunkt liegt in der Zusammenführung fachlich zusammengehöriger Abläufe. In vielen Microservice-Architekturen erstrecken sich einzelne Geschäftsprozesse – etwa Registrierungen, Checkout-Flows oder andere transaktionale Workflows – über mehrere Services, obwohl sie fachlich eine Einheit bilden. Diese Trennung verursacht zusätzlichen Koordinationsaufwand bei Deployments, Tests und Fehleranalysen. Die Bündelung solcher Abläufe zu gröberen Einheiten, etwa in Form von Macroservices oder eines wachsenden Monolithen, reduziert Netzwerkschnittstellen und vereinfacht den Betrieb spürbar.

Parallel dazu lohnt sich ein kritischer Blick auf die eingesetzte Technologielandschaft. Eine hohe Anzahl unterschiedlicher Programmiersprachen im Backend erschwert nicht nur Wartung und Weiterentwicklung, sondern auch Onboarding, Code-Reviews und den Aufbau von Betriebskompetenz. Eine gezielte Konsolidierung auf wenige, breit beherrschte Sprachen erhöht die Produktivität und senkt den operativen Aufwand. Performancekritische Sonderfälle lassen sich weiterhin isoliert behandeln, ohne die gesamte Architektur zu fragmentieren.

Diese Schritte zielen nicht darauf ab, verteilte Systeme grundsätzlich infrage zu stellen. Sie schaffen jedoch die Voraussetzungen, um Architekturentscheidungen wieder stärker an fachlichen Anforderungen, Betriebsrealitäten und verfügbaren Ressourcen auszurichten.

Der modulare Monolith

Für viele Anwendungsfälle stellt der modulare Monolith einen praktikablen Mittelweg zwischen klassischem Monolithen und stark verteilter Microservice-Architektur dar. Er kombiniert eine gemeinsame Codebasis und ein einheitliches Deployment mit klar abgegrenzten fachlichen Modulen. Dadurch reduziert sich die operative Komplexität, ohne auf Struktur, Wartbarkeit oder Skalierbarkeit verzichten zu müssen.

Praxisbeispiele zeigen, dass dieses Modell auch in großen Umgebungen funktioniert. Shopify betreibt mehrere Millionen Zeilen Code in einer einzigen deploybaren Einheit, an der über tausend Entwickler arbeiten. Auch Amazon selbst zog im Prime-Video-Team entsprechende Konsequenzen. Dort setzte eine konsequent cloudnative Architektur auf Lambda-Funktionen, Step Functions zur Orchestrierung und S3 als Zwischenspeicher. Der Betrieb verursachte jedoch einen extrem hohen Ressourcenverbrauch mit Milliarden von Storage-Operationen pro Monat. Die Konsolidierung in eine monolithische Anwendung senkte die Kosten erheblich, während Skalierbarkeit und Stabilität gleichzeitig zunahmen.

Entscheidend für den Erfolg eines modularen Monolithen ist die konsequente Durchsetzung interner Strukturen. Jedes Modul stellt seine Funktionalität über klar definierte interne Schnittstellen bereit. Änderungen innerhalb eines Moduls bleiben dadurch nach außen isoliert, solange die Schnittstellen stabil bleiben. Müssen sich Schnittstellen weiterentwickeln, sorgen Versionierung und Deprecation-Strategien dafür, dass abhängige Komponenten kontrolliert migrieren können. Diese Disziplin verhindert die schleichende Erosion, die Monolithen häufig unwartbar macht.

Ebenso wichtig sind strikt eingehaltene Modulgrenzen im Code. Module dürfen ausschließlich über ihre vorgesehenen Schnittstellen miteinander interagieren. Direkte Zugriffe auf interne Implementierungen bleiben ausgeschlossen und werden idealerweise bereits zur Compile-Zeit unterbunden. Moderne Plattformen unterstützen diese Vorgehensweise technisch, etwa durch explizite Moduldefinitionen oder Assembly-Grenzen. Architekturregeln lassen sich zusätzlich automatisiert in Build- und CI-Prozesse integrieren, sodass Verstöße frühzeitig auffallen.

Darüber hinaus spielt die Richtung von Abhängigkeiten eine zentrale Rolle. Module sollten einen gerichteten, azyklischen Abhängigkeitsgraphen bilden. Zirkuläre Abhängigkeiten erschweren isoliertes Testen, behindern Refactorings und erhöhen das Risiko unbeabsichtigter Seiteneffekte. Werkzeuge zur Architekturprüfung helfen dabei, diese Regeln dauerhaft einzuhalten und die Komplexität sichtbar zu machen.

Die fachliche Strukturierung orientiert sich idealerweise an den Prinzipien des Domain-Driven-Design. Statt technische Komponenten in den Vordergrund zu stellen, definieren sogenannte "Bounded Contexts" die Grenzen der Module. Begriffe und Datenmodelle dürfen sich je nach fachlichem Kontext unterscheiden, ohne globale Abhängigkeiten zu erzeugen. Auf diese Weise entstehen Module, die fachlich kohärent sind und Änderungen besser aufnehmen können, ohne das Gesamtsystem zu destabilisieren.

Fazit

Architekturen entfalten ihren Wert vor allem dann, wenn sie im Alltag beherrschbar bleiben. Systeme, deren Funktionsweise sich neuen Teammitgliedern innerhalb kurzer Zeit erklären lässt und bei denen sich Anfragen, Fehler und Abhängigkeiten nachvollziehen lassen, sind langfristig stabiler und wirtschaftlicher zu betreiben als hochgradig verteilte, schwer durchschaubare Landschaften.

Cloud- und Microservice-Ansätze haben das Versprechen gegeben, Infrastruktur und Betrieb zu vereinfachen. Ob dieses Versprechen eingelöst wird, entscheidet sich jedoch nicht an der Anzahl eingesetzter Technologien, sondern an klaren Verantwortlichkeiten, kontrollierbaren Deployments und transparenter Kostenstruktur. Für viele Workloads erweist sich ein modularer Monolith daher als pragmatischer Mittelweg zwischen Flexibilität und operativer Stabilität. (ln)

Über den Autor: Daniel Weisser ist CTO bei Exxeta.