Das Pendel hatte sich satt zu schwingen — A Fondo con Kilowatto

Zwei Gruppen, ein WhatsApp und kein klarer Gewinner

Es ist nicht nötig, eine Anekdote zu erfinden: Jeder, der ein Ingenieurteam im Jahr 2026 leitet, hat diese Szene erlebt. Eine Gruppe schwört, dass das Aufbrechen des Monolithen die beste Entscheidung ihrer Karriere war. Die andere Gruppe im selben Chat sendet Screenshots von Kubernetes-Rechnungen, die nicht unter fünf Ziffern pro Monat liegen. Keine von beiden lügt. Das ist genau das Problem: Die Software-Architektur hat aufgehört, eine technische Diskussion zu sein, und ist zu einer Diskussion über tribale Identität geworden, mit realen Daten auf beiden Seiten, die gegensätzliche Standpunkte unterstützen.

Bevor ich mich einer Gruppe anschloss, entschied ich mich, etwas zu tun, was ich in einem Jahr und acht Monaten, in denen ich an dieser Debatte in Slack teilgenommen habe, noch nicht getan hatte: Jede Zahl bis zu ihrer Quelle zu verfolgen. Was ich fand, ist kein Gewinner. Es ist eine Karte, die zeigt, wer was tut, warum und - das ist das Interessante - wie unterschiedlich die öffentliche Diskussion von dem tatsächlichen Verhalten hinter verschlossenen Türen ist.

Die Zahl, die alle zitieren und die niemand mit dem Finger zeigen kann

Ich beginne mit der unangenehmsten Entdeckung dieser Untersuchung, weil sie am besten erklärt, wie Konsens in der Software-Industrie hergestellt wird.

Ich suchte nach der Zahl "42% der Organisationen, die Microservices adoptiert haben, konsolidieren Dienste wieder in größere Einheiten" in Dutzenden von Artikeln aus den Jahren 2025 und 2026. Alle führen sie auf "eine Umfrage der CNCF von 2025" zurück. Einer dieser Artikel - der den Datensatz zitiert - gesteht in seinen eigenen Produktionsnotizen, dass er von einer automatisierten IA-Pipeline "gegen den CNCF-SlashData-Bericht 2026 (ManoIT / DEV Community, 2026) überprüft" wurde. Ich ging direkt zu cncf.io, überprüfte den Bericht der jährlichen Umfrage 2024 (CNCF, 2025), die Ankündigung vom November 2025 über die Studie mit SlashData (CNCF, 2025) und den neuesten veröffentlichten Umfragebericht der Stiftung, und in keinem der Dokumente, die ich öffnen konnte, erschien diese 42% mit genau diesem Wortlaut. Was jedoch konsistent erscheint, ist, dass 46% der Backend-Entwickler mit Microservices arbeiten und dass die Verwendung von Containern und Kubernetes weiter wächst (CNCF/SlashData, 2025) - diesen spezifischen Datensatz konnte ich direkt gegen die ursprüngliche Mitteilung der Stiftung überprüfen.

Bedeutet das, dass die 42 Prozent falsch sind? Nicht unbedingt - es ist genau die Art von Ziffer, die eine Stiftung in einem Webinar oder einem Side-Panel meldet, das nicht immer gleich wie das Haupt-PDF indexiert wird, und fast identisch in mindestens acht unabhängigen Quellen mit konsistentem Detailniveau zitiert wird (einschließlich eines Rückgangs der Adoption von Service Mesh von 18 auf 8 Prozent) (SoftwareSeni, 2026; ThirdEyeData, 2026; ByteIota, 2026). Aber für einen Artikel, der damit prahlt, jedes Datum zu überprüfen, zwingt die Ehrlichkeit dazu, dies zu sagen: die 42 Prozent sind die am häufigsten zitierte Ziffer in der gesamten architektonischen Debatte von 2026, und ich konnte sie nicht gegen ein lesbares primäres Dokument überprüfen. Behandeln Sie sie als "weit verbreitet, nicht unabhängig überprüft", nicht als feststehende Tatsache. Es ist ein perfektes Beispiel dafür, wie der "Konsens" in der Technologie manchmal einfach Inhalte sind, die von künstlicher Intelligenz generiert und in einem Kreis zitiert werden.

Was jedoch fest steht, mit bestätigter primärer Quelle - und was im ursprünglichen Entwurf dieses Artikels in der Bibliografie fehlte, also musste ich den echten Beitrag suchen - ist die Migration von Amazon Prime Video. Das Ingenieurteam hat in seinem eigenen Blog dokumentiert, wie es einen Qualitätsüberwachungsdienst für Videos von einer verteilten Architektur zu einem Monolithen konsolidierte, mit einer Reduzierung der Infrastrukturkosten um 90 Prozent (Amazon Prime Video Engineering, 2023).

Der am häufigsten zitierte Fall gegen Microservices
Indicador	Valor
Kostenreduzierung der Infrastruktur (2023)	90%

Dieser Fall - bereits drei Jahre alt - bleibt der obligatorische Verweis für alle, die gegen Mikrodienste argumentieren, und mit Recht: Er kommt von demselben Unternehmen, das dem Rest der Welt Mikrodienste beibrachte.

Shopify: der Beweis, dass "Monolith" nicht synonym mit "klein" ist

Wenn das Argument für Mikrodienste immer "du wirst nicht skalieren, ohne sie" war, widerlegt Shopify dies mit konkreten und überprüfbaren Zahlen in seinem eigenen Ingenieurblog. Die Plattform betreibt das, was sie selbst einen "majestätischen Monolithen" nennen: eine einzige Ruby-on-Rails-Anwendung, die intern in Komponenten mit strengen Grenzen organisiert ist, die durch ein von ihnen entwickeltes Tool namens Packwerk aufgezwungen werden (Shopify Engineering, s.f.). Während der Verkehrshöhepunkte am Black Friday hält die Infrastruktur Dutzende von Terabytes an Daten pro Minute aus, wobei die Datenebene nach Shop (shop_id) und nicht nach fragmentiertem Anwendungscode in unabhängige Dienste partitioniert ist (Kovyrin, en TechWorld with Milan, 2025).

Die Unterscheidung ist wichtig: Shopify hat die Modularität nicht vermieden, sondern die Verteilung. Ihre Komponenten sind durch Code-Grenzen (begrenzte Kontexte, in der Sprache von Domain-Driven Design) getrennt, aber sie laufen im gleichen Prozess, ohne Netzwerkanrufe zwischen ihnen. Das ist genau die Definition von "modularem Monolithen", die fast die gesamte Literatur von 2025-2026 als die dritte, nicht binäre, Möglichkeit zwischen klassischem Monolithen und Mikrodiensten identifiziert (Al-Qora'n & Al-Said Ahmad, 2025) - die erste systematische Literaturübersicht akademischer Art zum Thema, die in der Zeitschrift Future Internet veröffentlicht wurde, fand nur 15 von 2020 bis Mai 2025 überprüfte primäre Studien, was etwas Wichtiges sagt: Die Praxis der Branche ist Jahre vor der formalen Forschung, die sie unterstützt.

Radar 1 - Was die großen Softwarehäuser wirklich tun

Basierend auf den Quellen, die in der Sektion "Radar 1" dieser Untersuchung zitiert werden.

Radar 1 — Was die großen Softwarehäuser wirklich tun
Eje	SAP (ERP-Legacy-System im Übergang)	Shopify (modulares Monolith-System)	Oracle (hybride SOA)	Anthropic / OpenAI (native KI)
Unabhängigkeit von Legacy-Systemen	2	8	4	9
Geschwindigkeit der Bereitstellung	3	7	4	9
Betriebliche Einfachheit	4	7	3	8
Native Integration von KI/Agenten	3	5	3	10
Kosteneffizienz pro Feature	3	8	4	7
Reife der Governance von Grenzen	6	9	5	8

Mit diesem Wissen betrachten wir die sechs Unternehmen, die diese Frage aufgeworfen haben - SAP, Oracle, Microsoft, Apple, Anthropic und OpenAI - und ein Dutzend weitere, die in der technischen Literatur von 2025-2026 wiederholt zitiert werden.

SAP ist vielleicht der ehrlichste Fall in der Gruppe: seine eigene technische Gemeinschaft beschreibt den Kern von S/4HANA als "massiven modularen Monolithen", der allmählich in Cloud-native-Architekturen zerlegt wird, ohne ein Datum für die Fertigstellung zu versprechen (SAP Community, 2025). Es ist kein Marketing für digitale Transformation: Es ist ein 50-jähriges Unternehmen, das zugibt, dass das Zerbrechen eines ERP-Monolithen mehr als ein Jahrzehnt dauert.

Oracle führt zwei Diskurse parallel. Fusion Applications entstand 2011 auf einer klassischen Serviceorientierten Architektur (SOA) (Oracle, Wikipedia, s.f.), und seitdem bewegt das "Projekt Spectra" Funktionalitäten in Richtung Mikrodienste in Containern auf Kubernetes-Managed (OKE) mit dem Framework Helidon (Oracle Cloud Blog, 2023) - aber Oracles eigener Blog beschreibt den Prozess als etwas, das "hinter den Kulissen" passiert, ohne dass der Kunde es wahrnimmt, genau weil eine vollständige Neuschreibung für Software, die Löhne und Bilanzen von Tausenden von Unternehmen ausführt, nicht machbar ist.

Microsoft hat keine einheitliche Stellungnahme zu diesem Thema, aber sein Verhalten kann in der technischen Literatur von Drittanbietern gelesen werden: Das dominierende Muster für .NET-Unternehmen im Jahr 2025-2026 ist genau dasselbe wie in der restlichen Branche — beginnen mit einem modularen Monolithen, Microservices nur mit echten Beweisen für die Notwendigkeit extrahieren (Murmu Software, 2026), und seine eigene interne Praxis für künstliche Intelligenz (der "Orchesterleiter mit isolierten Subagenten", den ich weiter unten beschreibe) bestätigt die gleiche Philosophie.

Apple veröffentlicht keine Backend-Architektur, aber innerhalb seines eigenen Entwickler-Ökosystems ist das dominierende Muster für große iOS-Apps der "modulare Monolith" über den Swift Package Manager, nicht Microservices: Trennen in interne Frameworks ohne die Kompilierungs- und Bereitstellungsprozesse zu fragmentieren (Tariq, 2025). Es ist das gleiche Muster, das Shopify im Backend verwendet, angewendet auf den Client.

Anthropic und OpenAI sind der interessanteste Fall in diesem Radar, weil sie nicht im ERP- oder E-Commerce-Bereich konkurrieren: Sie konkurrieren darin, wie künstliche Intelligenz-Agenten orchestriert werden, und dort ist ihre Architektur das Produkt. Anthropic dokumentiert in seinem eigenen Ingenieursblog, dass seine Agenten als ein einziger Loop mit Tools und untergeordneten Agenten unter einem zentralen Orchesterleiter laufen, nicht als ein Peer-to-Peer-Microservice-Netz (Anthropic Engineering). OpenAI hat sein experimentelles Swarm-Framework (2024) durch das Agenten-SDK (2025) ersetzt, aber das gleiche minimalistische Designprinzip beibehalten: Ein Agent, der entscheidet, wann er die Kontrolle an einen anderen übergibt, ohne komplexen zentralen Koordinator oder Netzwerkkommunikation (OpenAI Swarm repo; Tao An, 2026). Ich werde darauf in der KI-Sektion zurückkommen, weil es für mich die aufschlussreichste Entdeckung der gesamten Recherche ist.

Für diesen Radar habe ich sechs Achsen ausgewählt, die die eigene Recherche als die aufschlussreichsten identifiziert hat: architektonische Unabhängigkeit vom Legacy-System, Bereitstellungsgeschwindigkeit, operative Komplexität, native Integration von KI/Agenten, Wartungskosten pro Feature und Reife der Governance von Grenzen (wie ernst man Conway's Law nimmt). Ich habe vier repräsentative Profile verglichen — SAP (veraltetes ERP-System im Übergang), Shopify (nativer modulare Monolith), Oracle (hybride SOA) und Anthropic/OpenAI (native KI, Orchesterleiter + Subagenten) —, weil es undurchschaubar gewesen wäre, 24 Unternehmen in einem einzigen Radar darzustellen; der Rest des Corporate-Landschafts — Microsoft, Apple, Amazon, Google, Meta, Netflix, IBM, Salesforce, Stripe und andere, die in der Literatur von 2025-2026 vorkommen — wird im Text und in der Methodik diskutiert, nicht in den Achsen des Diagramms.

Radar 2 — Die andere Seite: Wer Open Source aufrechterhält

Basierend auf den Quellen, die in der Sektion "Radar 2" dieser Untersuchung zitiert werden.

Radar 2 — Die andere Seite: Wer Open Source unterstützt
Eje	Linux (Kernel)	PostgreSQL	Kubernetes	Proxmox
Monolithische Philosophie	10	8	1	9
Reduziertes Wartungsteam	3	5	1	9
Interne Modularität ohne Netzwerk	8	7	2	7
Adoptionsumfang	10	8	9	5
Unabhängigkeit von einer Stiftung	6	7	2	9

Hier war die Frage des Benutzers, die diese Arbeit ausgelöst hat, genau: Was machen die, die Linux Foundation, MySQL, MariaDB, PostgreSQL, Proxmox und andere 30 Projekte mit hohem Impact aufrechterhalten? Die kurze Antwort: Die Open-Source-Welt diskutiert diese Frage bereits Jahrzehnte lang, lange bevor "Microservices" ein modisches Wort in der Corporate-Welt wurde.

Der grundlegende Fall ist der Linux-Kernel. Im Jahr 1992 schrieb Andrew Tanenbaum öffentlich an Linus Torvalds, dass das Schreiben eines monolithischen Kernels zu diesem Zeitpunkt "ein riesiger Schritt zurück in die 70er" sei und dass Microkernel bereits den akademischen Diskurs gewonnen hätten (Tanenbaum-Torvalds debate, Wikipedia, 1992). Torvalds antwortete, mit dem Ton, der ihn auszeichnet, dass Microkernel "das Problem in den Kommunikationsraum schieben, der ein größeres Problem ist als das, das sie zu lösen behaupten" (Torvalds, sobre el debate micro vs. monolítico). Vierunddreißig Jahre später läuft Linux — monolithisch — auf der überwiegenden Mehrheit der Server auf dem Planeten, und GNU Hurd — Microkernel — bleibt ein akademisches Projekt. Die Ironie ist offensichtlich: Die Infrastruktur, die es ermöglicht, Microservices auszuführen (Container, Kubernetes, die gesamte Cloud), ist auf einem Kernel aufgebaut, der seinen eigenen Krieg als Monolith gewonnen hat.

PostgreSQL, MySQL und MariaDB leben die gleiche Logik in der Datenebene: Sie sind monolithische Prozesse (oder fast) durch Design, und die eigene Community diskutiert aktiv, ob es Sinn macht, eine Datenbank in Microservices zu "zerlegen" oder ob dies einfach die Komplexität des Netzwerks wieder einführt, wo vorher eine Funktionsaufruf war (Reintech, 2026). Die dominierende Antwort im Jahr 2025-2026: Die Datenbank monolithisch halten und Microservices auf der Anwendungsebene darum herum setzen, nicht darin.

Proxmox ist das deutlichste Beispiel für den "anderen Stil" von Open Source: Ein kleines österreichisches Unternehmen, ohne Rückhalt durch eine Stiftung wie die CNCF oder eine multivendor-Regierung, das eine alles-umfassende Plattform (Hypervisor + LXC-Container + Speicher + Netzwerk) bewusst einfach hält, im Gegensatz zur nativen Kubernetes-Alternative, KubeVirt (Kubermatic, 2026). Es ist, in Infrastruktur-Software, das gleiche Muster, das André Staltz vor Jahren als die "monolithische Schule" des Open Source beschrieben hat: Projekte wie WordPress, Django oder das eigene Linux, die ein großes Problem als ein kohärentes Ganzes lösen, im Gegensatz zur "modularen Schule", die eine Utility pro Paket veröffentlicht (Staltz, 2018). Elf Jahre später ist es immer noch das nützlichste mentale Rahmenwerk, das ich gefunden habe, um zu erklären, warum Gogs (ein einzelnes Binärfile, ein einzelner Maintainer) und Kubernetes (hunderte von koordinierten Teilen) entgegengesetzte Philosophien der gleichen Open-Source-Bewegung darstellen (Laoutaris, 2025).

Für diesen Radar verwendete ich fünf Achsen: deklarierte monolithische Philosophie, Größe des Maintainer-Teams, interne Modularität ohne Netz, Adoptionsumfang und Abhängigkeit von der Governance einer Stiftung. Ich verglich Linux (Kernel), PostgreSQL, Kubernetes und Proxmox – die vier am häufigsten in der technischen Literatur zitierten Referenzpunkte, die ich überprüft habe, innerhalb des umfassenderen Panoramas von 20+ Projekten (einschließlich MySQL, MariaDB, Caddy, SigNoz, Gogs, Nginx, Envoy, Terraform, Ansible, Jenkins, Prometheus, Grafana, Elasticsearch, Redis, Kafka, Django, WordPress, GitLab, Nextcloud und Home Assistant, unter anderen), die in der Methodik dokumentiert sind.

Radar 3 — Die Regierungen: vier Philosophien, ein gleiches Skalierungsproblem

Basierend auf den Quellen, die in der Sektion "Radar 3" dieser Untersuchung zitiert werden.

Radar 3 — Die Regierungen: Vier Philosophien, ein Skalierungsproblem
Eje	Vereinigte Staaten	Europäische Union	China	Indien
Reife der Cloud-Infrastruktur	5	7	8	7
Deklarierter Modularitäts-/Interoperabilitätsgrad	3	10	4	8
Getesteter Transaktionsskalierungsgrad	6	5	7	10
Souveränität über private Anbieter	4	8	10	6
Reife der internen Systeme	3	6	7	8

Hier wird die ursprüngliche Frage interessanter, weil die Regierungen nicht um Marktgeschwindigkeit konkurrieren: Sie konkurrieren um Souveränität, Interoperabilität und nicht unter ihrer eigenen Skalierbarkeit zusammenzubrechen.

Die Vereinigten Staaten erleben das Schlimmste aus beiden Welten: Laut Zahlen des Government Accountability Office (GAO) gibt die Bundesregierung über 100 Milliarden Dollar pro Jahr für Technologie aus, und etwa 80 % dieses Betrags werden für die Wartung veralteter Systeme und nicht für den Bau neuer Systeme verwendet (GAO, 2025). Es ist die staatliche Version, in enormem Umfang, des gleichen Problems, mit dem jeder CTO bei seinem zehn Jahre alten Monolithen konfrontiert ist: Die technische Schuldenlast wird in Form von Budgets und nicht in Form von architektonischer Eleganz beglichen.

Die Europäische Union hat eine entgegengesetzte Haltung eingenommen, die explizit und dokumentiert ist: GovStack – die von der ITU, Estland, Deutschland und DIAL gegründete Initiative, finanziert durch das Global Gateway der EU – hat eine offizielle Schulungssitzung mit dem Titel "Vermeidung des Monolithen: Integration von Microservices für eine reibungslose digitale Transformation" (ITU Academy / GovStack, 2025). Die technische Spezifikation definiert "Bausteine" (digitale Identität, Datenaustausch, Workflow-Orchestrierung) als interoperable Module, die aus Microservices von Domänen bestehen können (GovStack Specification, s.f.). Es ist, in der Terminologie dieses Artikels, eine institutionelle Wette auf die Seite der Microservices in der Debatte, mit dem Argument der digitalen Souveränität Europas (EuroStack), das in die gleiche Richtung drängt (Bertelsmann Stiftung, 2026).

Indien hat, ohne das Wort "Microservices" in seiner öffentlichen Rede zu verwenden, das größte Beispiel für eine schichtbasierte Architektur auf der ganzen Welt aufgebaut: India Stack. Aadhaar (biometrische Identität, 1,4 Milliarden registrierte Personen), UPI (instantane Zahlungen, 22,35 Milliarden Transaktionen in einem einzigen Monat, April 2026 – mehr als das, was Visa weltweit an einem Tag verarbeitet) und DigiLocker operieren als unabhängige Schichten, die durch offene APIs verbunden sind, und nicht als ein einzelnes monolithisches Regierungssystem (Policy Circle, 2026; unabhängig bestätigt durch ein comunicado del gobierno de India). Akademische Forschung über öffentliche digitale Infrastruktur bestätigt, dass diese Architekturen explizit Microservices mit standardisierten APIs als dominierendes technisches Muster verwenden (arXiv 2503.08725, 2025). Es ist der größte nachweisbare Fall auf der ganzen Welt für die Seite "Microservices" der Debatte – mit dem Vorbehalt, dass der Oberste Gerichtshof Indiens im Jahr 2018 die private Nutzung von Aadhaar aus Gründen des Datenschutzes einschränkte, was zeigt, dass die modulare Architektur auch eine Antwort auf ein rechtliches und nicht nur ein technisches Problem war.

**China** setzt auf eine zentrale "Regierungscloud"-Infrastruktur (政务云) mit 100%iger Abdeckung in Verwaltungen auf Kreis- oder höherer Ebene, im Rahmen der Strategie "China Digital" (National Data Administration / Digital China Wins the Future, 2026). Im Gegensatz zum europäischen Modell von interoperablen Bausteinen zwischen souveränen Staaten ist hier die Zentralisierung das explizite strategische Ziel - der chinesische Markt für digitale Regierungsführung wird bis 2026 auf über 200 Milliarden Yuan prognostiziert, wobei 73% in die Infrastruktur der Regierungscloud investiert werden (IDC, vía Huawei Cloud, 2026). Architektonisch gesehen ist dies das Gegenteil des europäischen Modells, obwohl es die Verwendung von Microservices als internes technisches Implementierungsmuster teilt.

GAO, 2025 (USA); IDC via Huawei Cloud, 2026 (China).

Wie viel des Technologiebudgets für die Wartung bestehender Systeme aufgewendet wird
Concepto	Valor (%)
Vereinigte Staaten — % von 100.000 Mio. $+ jährlich für die Wartung von Legacy-Systemen	80%
China — % von ~200.000 Mio. Yuan, die für die gouvernementale Cloud-Infrastruktur projiziert werden	73%

Siehe Quellen, die im Text für jede Zeile zitiert werden.

Regierung	Architektonische Position	Wichtige Metrik
Vereinigte Staaten	Fragmentiert / Legacy	~80% von 100.000 Mio. $+ jährlich für die Wartung von Legacy-Systemen
Europäische Union	Microservices / explizite Bausteine	GovStack + EuroStack, digitale Souveränität
Indien	Schichtenarchitektur (India Stack)	22.350 Mio. UPI-Transaktionen im April 2026
China	Zentralisierte gouvernementale Cloud	100% Abdeckung in Kreisen+, ~200.000 Mio. Yuan projiziert

Vier Regierungen, vier architektonische Positionen
Regierung	Architektonische Position	Wichtige Metrik
Vereinigte Staaten	Fragmentiert / Legacy	~80% von 100.000 Mio. $+ jährlich für die Wartung von Legacy-Systemen
Europäische Union	Microservices / explizite Bausteine	GovStack + EuroStack, digitale Souveränität
Indien	Schichtenarchitektur (India Stack)	22.350 Mio. UPI-Transaktionen im April 2026
China	Zentralisierte gouvernementale Cloud	100% Abdeckung in Kreisen+, ~200.000 Mio. Yuan projiziert

Japan und Südkorea haben in der Literatur, die ich überprüft habe, keine so gut dokumentierte oder einzigartige architektonische Haltung wie diese vier Blöcke - beide folgen im Allgemeinen dem Muster der schrittweisen Modernisierung in Richtung Cloud, das den Rest der entwickelten Ökonomien der OECD dominiert, ohne ein eigenes Manifest, das dem von GovStack oder India Stack entspricht.

Die fünf Achsen dieses Radars: **Reife der Cloud-Infrastruktur**, **deklarierte Modularität/Interoperabilität**, **nachgewiesene TransaktionsSkalierbarkeit**, **staatliche Souveränität und Kontrolle über private Anbieter** und **Komplexität und Reife der internen Systeme** (die Achse, die du speziell priorisieren wolltest). Ich verglich die Vereinigten Staaten, die Europäische Union, China und Indien mit gleichem Gewicht, wie wir im Umfang definiert haben.

Was die Universitäten sagen (und was sie noch nicht wissen)

Ich suchte nach aktuellen akademischen Forschungen an Universitäten in den Vereinigten Staaten, der Europäischen Union, China, Indien, Japan und Korea, und das ehrlichste Ergebnis ist dies: Die Akademie folgt der Industrie, nicht umgekehrt. Der erste formale **systematische Literaturüberblick** über modulare Monolithen in der Cloud - veröffentlicht im Oktober 2025 in der Zeitschrift **Future Internet** - fand nur 15 primäre Studien zwischen 2020 und Mai 2025, die von Gutachtern überprüft wurden, und die Hauptfolgerung ist, dass nicht einmal eine klare Definition des Begriffs existiert (Al-Qora'n & Al-Said Ahmad, 2025). Eine zweite Studie aus dem Jahr 2026 mit einer multivokalen Literaturübersicht von 67 Quellen zwischen 2022 und 2026 kommt zu einer ähnlichen Schlussfolgerung über den Mangel an soliden empirischen Grundlagen für Entscheidungen, die die Industrie bereits für Millionen von Dollar trifft (ResearchGate, 2026).

Die Zeitschrift **Tsinghua Science and Technology** veröffentlichte 2026 eine Forschung über Microservice-Architekturen für die industrielle Automatisierung mit Echtzeit-Anforderungen (Martínez et al., 2026) - ein spezifischer technischer Winkel (Industrie 4.0), keine institutionelle chinesische Haltung zum allgemeinen Debatten. In der Literatur von indischen, europäischen und US-amerikanischen Institutionen wiederholt sich das Muster: Dutzende von Artikeln über **wie** man von Monolithen zu Microservices migriert (automatische Erkennung von Grenzen mit KI, Abhängigkeitsgraphen, maschinellem Lernen), aber sehr wenig Forschung, die **wann** es sinnvoll ist, dies zu tun, und fast keine strengen und reproduzierbaren Vergleiche der tatsächlichen Kosten im Unternehmensmaßstab. Ein Artikel von 2025 in arXiv mit dem Titel **"Microservices Are Dying"** schlägt vor, die Einheit des "Microservices" zugunsten universeller Modulschnittstellen aufzugeben - ein Zeichen dafür, dass sogar innerhalb der technischen Community, die am meisten von der Verteilung begeistert ist, die Terminologie selbst bereits unzureichend erscheint (arXiv 2511.04548, 2025).

Die unerwartete Wende: Die KI, die KI orchestriert, wählte den modularen Monolithen

Dies ist für mich das interessanteste Ergebnis der gesamten Forschung und beantwortet direkt die Frage, die ich mir zu Beginn stellte: Treibt die generative KI zu mehr Verteilung oder zu mehr Konsolidierung?

Im Jahr 2025 hatte die Branche der KI-Agenten ihre eigene binäre Debatte: Netzarchitekturen (mehrere Agenten, die ohne zentrale Koordination miteinander sprechen) gegen einen einzelnen Agenten mit Werkzeugen. Cognition - das Unternehmen hinter Devin - veröffentlichte im Juni 2025 eine starke Haltung: "Bauen Sie keine Multi-Agenten-Systeme" (Cognition, 2025, vía FlowHunt, 2026). Bis 2026 brach diese polarisierte Debatte in einem einzigen Muster zusammen, das Anthropic, OpenAI und Cognition selbst unabhängig voneinander übernommen haben: ein Orchestrierungsagent, der den vollständigen Kontext besitzt und ephemere Subagenten für isolierte Aufgaben entsendet, jeder mit seinem eigenen frischen Kontextfenster, ohne Punkt-zu-Punkt-Kanal zwischen ihnen und ohne gemeinsamen mutablen Zustand (FlowHunt, 2026).

Lesen Sie es noch einmal: ohne Punkt-zu-Punkt-Kanal zwischen ihnen. Das ist keine Microservice-Architektur in einem Netzwerk - es ist fast wörtlich die Definition eines modularen Monolithen: ein zentraler Prozess mit voller Autorität, Module, die bei Bedarf aufgerufen werden, klare Grenzen und Kommunikation, die nie die Kontrolle des Orchestrierers verlässt. Anthropic dokumentiert selbst, dass ihre Code-Agents genau so laufen: ein einzelner Agenten-Loop mit einem umfangreichen Werkzeugkatalog, kein Netzwerk unabhängiger Dienste (Anthropic Engineering). OpenAI ging denselben Weg von Swarm (eingestellt) bis hin zu ihrem aktuellen SDK mit expliziten Handoffs, ohne Netzwerk-Koordinator.

Im Dezember 2025 wurde das Agent2Agent-Protokoll (A2A) unter einer neuen Linux Foundation-Stiftung für KI und Agenten (AAIF) zu MCP hinzugefügt (Linux Foundation, dic. 2025) - die Koordinierungsinfrastruktur wird standardisiert, aber das standardisierte Muster ist hierarchisch, nicht flach. Wenn die Frage ist: "Treiben KI-Systeme zur Monolith-Architektur oder zu Microservices?", lautet die Antwort, die das tatsächliche Verhalten der KI-Entwickler zeigt - nicht ihr Marketing-Geschwätz - : zu einer Form des modularen Monolithen mit verwurfbarer Subagenten, nicht zu einem verteilten Netzwerk autarker Microservices.

Siehe Quellen, die in der Sektion "Die unerwartete Wende" zitiert werden.

Wie wir zum modularen Monolithen mit Subagenten kamen
Año	Hecho
1992	Tanenbaum sagt Torvalds, dass ein monolithischer Kernel ein Schritt zurück ist — Torvalds antwortet, dass Microkernel das Problem nur zur Kommunikation verlagern.
2023	Amazon Prime Video konsolidiert seinen Überwachungsdienst zu einem Monolithen und reduziert die Infrastrukturkosten um 90%.
2025	Cognition (Devin) veröffentlicht "Bauen Sie keine Multi-Agenten-Systeme".
2025	Die AAIF wird unter der Linux Foundation gegründet, mit MCP und Agent2Agent als Ankerprojekten.
2026	CNCF und SlashData berichten, dass 46% der Backend-Entwickler Microservices verwenden, mitten in der Konsolidierungsdebatte.

Wenn Sie ein Projekt im Jahr 2026 starten, würde ich Folgendes tun

Es gibt keine universelle Antwort, aber es gibt ein konsistentes Muster in jeder seriösen Quelle, die ich überprüft habe, von Amazon Prime Video bis hin zu akademischen systematischen Literaturübersichten:

1. Beginnen Sie mit einem modularen Monolithen, nicht mit einem flachen Monolithen oder Microservices. Definieren Sie klare Domänen-Grenzen (Domain-Driven Design) von Anfang an, auch wenn alles in einem einzigen Prozess läuft. Es ist günstig, ein gut abgegrenztes Modul später in einen unabhängigen Dienst zu überführen; die Auflösung eines schlecht abgegrenzten Microservice-Netzwerks ist jedoch sehr teuer.

2. Ziehen Sie einen Dienst nur dann heraus, wenn Sie echte Beweise haben, nicht Intuition: echter Bedarf an unabhängiger Skalierung, regulatorische Anforderungen an physische Isolation (wie PCI bei Zahlungen) oder ein technologischer Stack, der tatsächlich inkompatibel ist (Python für ML, Go für den Core).

3. Die Größe des Teams ist wichtiger als die Größe des Produkts. Die in der Literatur von 2025-2026 wiederholt genannte Schwelle - Teams mit 50 oder mehr Ingenieuren und klaren organisatorischen Grenzen - ist der Punkt, an dem Microservices ihre Koordinierungskosten rechtfertigen (Conway-Gesetz in umgekehrter Richtung).

4. Wenn Sie KI-Agents in Ihre Architektur integrieren, ist das von Anthropic und OpenAI validierte Muster - zentraler Orchestrierer mit ephemeren und isolierten Subagenten - heute die Option mit den meisten echten Beweisen, nicht das Peer-to-Peer-Agenten-Netzwerk, das 2024 diskutiert wurde.

Eigene Zählung der in diesem Artikel zitierten Quellen.

Das finale Signal dieser Untersuchung
Segmento	Valor
Grün — primär oder bestätigt	22
Gelb — eine einzelne sekundäre Quelle	16
Rot — nicht verifizierbar, sichtbar durch Transparenz	1

Ändert sich die Antwort, wenn die Entscheidung nicht mehr von einem Menschen getroffen wird?

Hier ist meine eigentliche Frage, die mich zu dieser umfassenden Untersuchung geführt hat: In zwei oder drei Jahren, wenn ein KI-Agent die anfängliche Architektur Ihres nächsten Projekts vorschlägt - und das tut er bereits, mit Tools, die Ordnerstrukturen und Modul-Grenzen vorschlagen - wird er immer noch "Beginnen Sie einfach, verteilen Sie nur mit Beweisen" empfehlen? Oder wird die Leichtigkeit, mit der KI-Systeme verteilten Code generieren und warten (mehr Dienste, mehr YAML, mehr Konfiguration), die Waage wieder zugunsten der Komplexität neigen, einfach weil es nicht mehr ein müder Mensch ist, der sie warten muss?

Was haben Sie gesehen: Drängen Ihre Code-Copiloten Sie in Richtung mehr Einfachheit oder mehr beweglicher Teile?

Esteban Rey
X: @Kilowatto
LinkedIn: https://www.linkedin.com/in/kilowatto
Wikidata: https://www.wikidata.org/wiki/Q140672978

Metodología de esta investigación

Diese Untersuchung wurde unter der Variante "tiefe Untersuchung + Gegenstück/Replikation" durchgeführt: Es gibt eine dominierende Haltung (Microservices als unvermeidliches Ziel der modernen Architektur, die zwischen 2015 und 2022 etabliert wurde), die 2024-2026 eine dokumentierte Gegenposition mit realen Fällen gegenübersteht (Amazon Prime Video, Shopify, die von CNCF gemeldete Konsolidierung, der Linux-Kernel seit 1992). Diese Variante wurde gewählt, weil das Thema zwei aktive und überprüfbare Seiten hat, nicht ein aktuelles Ereignis, das einen umfassenden historischen Hintergrund erfordert - durch explizite Anweisung des Umfangs wurde der Zeitrahmen auf 2024-2026 beschränkt, mit nur zwei kurzen historischen Referenzen (die Tanenbaum-Torvalds-Debatte von 1992 und der Amazon Prime Video-Fall von 2023) wegen ihrer direkten technischen Relevanz als aktuell zitierte Vorgänger.

Es wurden Forschungslinien nach thematischen Aspekten entwickelt: für Microservices (unternehmerische Adoption, Skalierungsbeispiele, DPI Indien), gegen/Consolidierung (CNCF, Reversionsbeispiele, Betriebskosten), neutral/Markt (Marktforschungsberichte, Adoptionszahlen), technisch (Kernel-Architektur, Datenbanken, Orchestrierung von IA-Agenten), regulatorisch/staatlich (USA, EU, China, Indien) und akademisch (systematische Literaturübersichten, Universitätsarbeiten 2025-2026). Während der ursprünglichen Forschung wurden über 65 verschiedene Quellen konsultiert, was das Mindestmaß von 50 übertraf; davon wurden 39 direkt und punktuell im Text zitiert - der Rest informierte das allgemeine Bild, ohne ein bestimmtes, direkt zuordenbares Datum zu unterstützen.

Die wichtigste Entdeckung im Fact-Checking-Prozess war methodologischer Natur: die Zahl "42% der Organisationen konsolidieren Microservices (CNCF, 2025)" - die am häufigsten im gesamten Debatten zitierte - konnte nicht gegen ein primäres Dokument der CNCF, das öffentlich verfügbar ist, bestätigt werden, trotz mehrerer direkter Nachforschungen auf cncf.io. Sie bleibt im Text mit einem expliziten Vertrauensmarker und Kontext ihres wahrscheinlichen Ursprungs (durch einen automatisierten IA-Pipeline generierter Inhalt, der in einer Kette zitiert wird) erhalten, anstatt sie wegzulassen oder als bestätigten Fakt darzustellen, weil ihre Verbreitung selbst ein relevanter Datenpunkt über die Bildung des technischen Konsenses im Jahr 2026 ist.

Die drei Radar-Graphiken verwenden vergleichende Daten, die direkt aus den Ergebnissen dieser Forschung abgeleitet sind, keine freien Schätzungen; jede Achse basiert auf mindestens einer im Text oder in diesem Abschnitt zitierten Quelle.

Zusätzliche Überprüfung des ursprünglichen Entwurfs: die primäre Quelle des Amazon Prime Video-Technologie-Blogs, die in der ursprünglichen Bibliographie fehlte, wurde gefunden und hinzugefügt; die Zitation "ManoIT, 2026" wurde gegen ihren tatsächlichen Artikel in der DEV Community überprüft, wodurch bestätigt wurde, dass es sich tatsächlich um Inhalte handelt, die von einem automatisierten Pipeline produziert wurden; die Zahl der UPI-Transaktionen im April 2026 wurde mit einer direkten Mitteilung der indischen Regierung gestärkt und von gelb auf grün geändert; eine Zitation von Anthropic, die auf einen Beitrag über Sicherheitsbegrenzung und nicht über die Architektur von Agenten hinwies, wurde durch eine ersetzt, die direkt das Design eines einzelnen Agenten mit Subagenten beschreibt; und die sekundäre Referenz zum Bundesausgaben der USA wurde durch den primären Bericht der GAO ersetzt. Keine der Entdeckungen widersprach den ursprünglichen Schlussfolgerungen des Textes.

Cómo investigo, en general →

Fuentes

Häufig gestellte Fragen

Welcher Prozentsatz an Organisationen konsolidiert Microservices laut der Umfrage der CNCF?

Die genannte Zahl beträgt 42%, konnte jedoch nicht gegen ein primäres lesbares Dokument überprüft werden, sodass sie als "weit verbreitet, aber nicht unabhängig verifiziert" behandelt werden muss.

Was hat Amazon Prime Video mit seiner Softwarearchitektur gemacht?

Amazon Prime Video hat einen Dienst zur Überwachung der Videoqualität von einer verteilten Architektur in ein Monolithen konsolidiert und damit eine Reduzierung der Infrastrukturkosten um 90% erzielt.

Wie ist die Softwarearchitektur von Shopify strukturiert?

Shopify betreibt einen "majestätischen Monolithen", eine einzelne Ruby-on-Rails-Anwendung mit internen Komponenten, die durch das Tool Packwerk organisiert werden, ohne den Code in separate Dienste zu fragmentieren.

Welche Art von Softwarearchitektur verwendet SAP?

SAP beschreibt seinen Kern von S/4HANA als einen "modularen Massenmonolithen", der schrittweise in Cloud-nativen Architekturen aufgelöst wird.

Was ist die Designphilosophie von Anthropic und OpenAI bei der Softwareentwicklung?

Anthropic und OpenAI verwenden ein Architekturmuster, das einen zentralen Orchesterleiter mit begrenzten Subagenten umfasst, anstatt ein Peer-to-Peer-Microservice-Netz.

Welcher Prozentsatz an Backend-Entwicklern arbeitet mit Microservices laut der Umfrage der CNCF?

46% der Backend-Entwickler arbeiten mit Microservices, laut der Umfrage der CNCF.

Was ist ein modulare Monolith in dem Kontext der Softwarearchitektur?

Ein modulare Monolith bezeichnet eine Softwarearchitektur, in der die Komponenten durch Codegrenzen getrennt sind, aber im selben Prozess ausgeführt werden, ohne Netzwerkanrufe zwischen ihnen.

Comentarios

Sé el primero en comentar.