The pendulum got tired of swinging I verified the monolith vs. microservices debate of 2026 against 65+ primary sources -- from Shopify and Amazon to the European Union, China, and India. Transcript of the narrated version (23 min). Narrated with a synthetic voice (Larry). The writing is Esteban Rey's — kilowatto.com. --- The pendulum got tired of swinging. I verified the monolith vs. microservices debate of 2026 against 65+ primary sources -- from Shopify and Amazon to the European Union, China, and India. Two sides, a WhatsApp group, and no clear winner. Anyone leading an engineering team in 2026 has likely experienced a situation where one group strongly believes that breaking up the monolith was the best decision of their career, while another group in the same chat shares screenshots of Kubernetes bills exceeding five figures a month. Neither group is lying, which is precisely the issue, as software architecture discussions have become a matter of tribal identity, with real data supporting opposing views on both sides. Before taking a side, I decided to thoroughly examine every statistic, tracing it back to its origin, something I had not done in a year and a half of participating in this Slack debate. What I discovered is not a clear winner, but rather a map of who is doing what, why they are doing it, and notably, how the public discourse differs from the actual behavior that occurs behind closed doors. The statistic everyone cites but can't point to. I'll start with the most uncomfortable finding of this investigation, because it best explains how consensus is manufactured in the software industry. I searched for the statistic 42% of organizations that adopted microservices are consolidating services back into larger units in dozens of articles from 2025 and 2026. All attribute it to a 2025 CNCF survey. One of those articles, which also cites the statistic, confesses in its production notes that it was written by an automated AI pipeline verified against the CNCF x SlashData 2026 report, as stated by ManoIT and DEV Community in 2026. I went straight to cncf.io, reviewed the 2024 annual survey report, published by CNCF in 2025, the November 2025 announcement about the study with SlashData, also published by CNCF in 2025, and the foundation's most recent published survey report, and in none of the documents I could access did that 42% appear with that exact wording. What does appear consistently is that 46% of backend developers work with microservices and that the use of containers and Kubernetes keeps growing, as reported by CNCF and SlashData in 2025, which I confirmed directly against the foundation's original statement. Does that mean the 42% is false? Not necessarily, it's exactly the kind of figure a foundation would report in a webinar or side panel that doesn't always get indexed the same way as the main PDF, and it's cited almost identically in at least eight independent sources with consistent detail, including an 18% to 8% drop in service mesh adoption, as mentioned by SoftwareSeni in 2026, ThirdEyeData in 2026, and ByteIota in 2026. But for an article that boasts about verifying every fact, honesty demands saying this: the 42% is the most-cited figure in the entire 2026 architecture debate, and I couldn't confirm it against a readable primary document. Treat it as widely repeated, not independently verified, not as a done deal. It's a perfect example of how consensus in tech is sometimes just AI-generated content citing itself in a circle. What is solid, with a confirmed primary source, is the migration of Amazon Prime Video. Their engineering team documented on their own blog how they consolidated a video quality monitoring service from a distributed architecture to a monolith, with a 90% reduction in infrastructure costs, as reported by Amazon Prime Video Engineering in 2023. The most-cited case against microservices, which comes from the same company that taught the world about microservices, remains the go-to citation for anyone arguing against microservices, and for good reason. That case, already three years old, is still widely referenced. Shopify: proof that "monolith" isn't synonymous with "small". Shopify disproves the argument that microservices are necessary for scaling with concrete, verifiable numbers on their own engineering blog. The platform operates a single Ruby on Rails application, which they call a "majestic monolith", organized internally into components with strict boundaries imposed by a tool they developed, Packwerk. During Black Friday traffic peaks, the infrastructure handles tens of terabytes of data per minute, with the database layer partitioned by store, or shop_id, instead of fragmenting the application code into separate services. According to Kovyrin, in TechWorld with Milan, 2025, this approach allows for efficient handling of high traffic. The distinction between this approach and microservices matters, as Shopify avoided distribution, not modularity. Their components are separated by code boundaries, or bounded contexts, in Domain-Driven Design language, but they run in the same process, without network calls between them. This is the definition of a "modular monolith", identified in almost all literature from 2025-2026 as a third way between classic monolith and microservices. Research by Al-Qora'n and Al-Said Ahmad, published in 2025, supports this approach, and a systematic literature review published in the Future Internet journal found only 15 peer-reviewed primary studies on the topic between 2020 and May 2025, indicating that industry practice is ahead of formal research. Radar 1 — What the big software houses actually do. With this on the table, let's look at the six companies that originated this question — SAP, Oracle, Microsoft, Apple, Anthropic, and OpenAI — and a dozen more that are frequently cited in the technical literature of 2025-2026. SAP is perhaps the most honest case of the bunch: their own technical community describes the core of S/4HANA as a massive modular monolith that's undergoing gradual decomposition into native cloud architectures, with no promised completion date, as stated by the SAP Community in 2025. It's not digital transformation marketing: it's a 50-year-old company admitting that breaking up an ERP monolith takes more than a decade. Oracle runs two parallel discourses. Fusion Applications was born in 2011 on a classic service-oriented architecture, and since then the Project Spectra has been moving functionality towards microservices in containers on managed Kubernetes, using the Helidon framework, as described by the Oracle Cloud Blog in 2023 — but Oracle's own blog describes the process as something that happens behind the scenes, without the customer noticing, precisely because a total rewrite is unviable for software that runs payroll and financial statements for thousands of companies. Microsoft doesn't have a single statement on the topic, but its behavior can be inferred from third-party technical literature. The dominant pattern for enterprise .NET in 2025-2026 is the same as in the rest of the industry — starting with a modular monolith and extracting microservices only when there's real evidence of need, as noted by Murmu Software in 2026. Its own internal AI practice, the orchestrator with isolated sub-agents, confirms this philosophy. Apple doesn't publish its backend architecture, but within its own developer ecosystem, the dominant pattern for large iOS apps is the modular monolith via Swift Package Manager, not microservices: separating into internal frameworks without fragmenting the build and deployment process, as described by Tariq in 2025. This is the same pattern Shopify uses in its backend, applied to the client. Anthropic and OpenAI are the most interesting case on this radar because they don't compete in ERP or e-commerce: they compete in how AI agents are orchestrated, and their architecture is the product. Anthropic documents on its own engineering blog that its agents run as a single loop with bounded tools and sub-agents under a central orchestrator, not as a peer-to-peer mesh of microservices. OpenAI abandoned its experimental Swarm framework in 2024 for the Agents SDK in 2025, but kept the same minimalist design principle: an agent that decides when to transfer control to another, without a complex central coordinator or mesh communication, as noted by Tao An in 2026. For this radar, I chose six axes that the research itself identified as the most revealing: architectural independence from legacy, deployment speed, assumed operational complexity, native integration of AI/agents, maintenance cost per feature, and maturity of boundary governance, which is how seriously they take Conway's Law. I compared four representative profiles — SAP, which is a legacy ERP in transition, Shopify, which is a native modular monolith, Oracle, which is a hybrid SOA, and Anthropic/OpenAI, which is native AI, orchestrator plus sub-agents — because trying to graph 24 companies in a single radar would have been illegible. The rest of the corporate landscape, including Microsoft, Apple, Amazon, Google, Meta, Netflix, IBM, Salesforce, Stripe, and others that appear in 2025-2026 literature, is discussed in the body of the text and in the methodology, not in the radar's axes. Radar 2 — The other side: who keeps open source alive. The details about who keeps open source going are found in the article. A user's question prompted this piece, asking what the maintainers of Linux Foundation, MySQL, MariaDB, PostgreSQL, Proxmox, and 30 other high-impact projects do. The open-source world has been discussing this topic for decades, long before "microservices" became a corporate buzzword. The foundational case is the Linux kernel. In 1992, Andrew Tanenbaum publicly wrote to Linus Torvalds, stating that writing a monolithic kernel at that time was "a giant step backward to the 70s" and that microkernels had already won the academic debate. Torvalds responded, saying that microkernels "push the problem to the communication space, which is a bigger problem than the one they claim to solve". Thirty-four years later, Linux, which is monolithic, runs on the vast majority of servers on the planet, while GNU Hurd, a microkernel, remains an academic project. This is ironic because the infrastructure that makes it possible to run microservices, such as containers, Kubernetes, and the entire cloud, is built on a kernel that won its own war by being monolithic. PostgreSQL, MySQL, and MariaDB follow the same logic in the data layer, being monolithic processes by design. The community actively discusses whether breaking down a database into data microservices makes sense or simply reintroduces network complexity where there used to be a function call. The dominant answer in 2025-2026 is to keep the database monolithic and put application microservices around it, not inside. Proxmox is an example of the "other style" of open source, a small Austrian company maintaining an all-in-one platform that is deliberately simple compared to the native Kubernetes alternative, KubeVirt. This follows the same pattern in infrastructure software that André Staltz described as the "monolithic school" of open source, which includes projects like WordPress, Django, or Linux itself, solving a big problem as a cohesive block. In contrast, the "modular school" releases a utility per package. Even years later, this remains a useful mental framework to explain why projects like Gogs and Kubernetes represent opposing philosophies within the same open source movement. For this analysis, five axes were used: declared monolithic philosophy, maintainer team size, internal modularity without networking, adoption scale, and foundation governance dependence. Linux, PostgreSQL, Kubernetes, and Proxmox were compared, as they are the four most cited reference points in the technical literature reviewed. This comparison is part of a broader landscape of 20+ projects, including MySQL, MariaDB, Caddy, SigNoz, Gogs, Nginx, Envoy, Terraform, Ansible, Jenkins, Prometheus, Grafana, Elasticsearch, Redis, Kafka, Django, WordPress, GitLab, Nextcloud, and Home Assistant, among others, which are documented in the methodology. Radar 3 — Governments: four philosophies, one scaling problem. This is where the original question gets more interesting, because governments aren't competing for market speed, they're competing for sovereignty, interoperability, and not collapsing under their own scale. The United States is experiencing the worst of both worlds, according to figures from the Government Accountability Office, the federal government spends over $100 billion annually on technology, and about 80% of that amount goes towards keeping legacy systems running, not building anything new. It's the state-level version, on a massive scale, of the same problem any CTO faces with their ten-year-old monolith, technical debt is paid in budget, not architectural elegance. The European Union has taken the opposite stance explicitly and in documentation, GovStack, the initiative founded by the ITU, Estonia, Germany, and DIAL, with funding from the EU's Global Gateway, has an official training session literally titled "Avoiding the Monolith: Integrating Microservices for Frictionless Digital Transformation". Its technical specification defines building blocks, such as digital identity, data exchange, and workflow orchestration, as interoperable modules that can be composed of domain microservices. This is, in essence, an explicit institutional bet on the microservices side of the debate, with the argument of European digital sovereignty, or EuroStack, pushing in the same direction. India built, without ever using the term microservices in public discourse, the largest example of layered architecture on the planet, India Stack. Aadhaar, which has 1.4 billion people enrolled, UPI, which had 22.35 billion transactions in a single month of April 2026, more than Visa processes globally in a day, and DigiLocker operate as independent layers connected by open APIs, not as a single monolithic government system. Academic research on public digital infrastructure confirms that these architectures explicitly use microservices with standardized APIs as the dominant technical pattern. This is the largest proven case on the planet for the microservices side of the debate, with the nuance that the Supreme Court of India, in 2018, limited the private use of Aadhaar for privacy reasons, showing that the modular architecture was also, in part, a response to a legal problem, not just a technical one. China is betting on a centralized government cloud infrastructure with 100% coverage in county-level or higher administrations, as part of its China Digital strategy. Unlike the European model of interoperable building blocks between sovereign countries, centralization is explicitly the strategic goal here, the Chinese digital government market is projected to be over 200 billion yuan by 2026, with 73% going to government cloud infrastructure. Architecturally, it's the opposite of the European model, although it shares the use of microservices as an internal technical implementation pattern. Japan and South Korea don't have a documented or distinctive architectural stance in the literature, both generally follow the pattern of gradual modernization towards the cloud that dominates the rest of the developed OECD economies, without a manifesto equivalent to GovStack or India Stack. The five axes of this radar are cloud infrastructure maturity, declared modularity or interoperability, proven transaction scale, state sovereignty and control over private providers, and complexity and maturity of internal systems. The United States, the European Union, China, and India were compared with equal weight, as defined in the scope. What universities say (and what they still don't know). I searched for recent academic research in universities in the United States, the European Union, China, India, Japan, and Korea, and the most honest finding is this: academia is behind the industry, not ahead. The first formal systematic literature review on modular monoliths in the cloud, published in October 2025 in the Future Internet journal, found only 15 peer-reviewed primary studies between 2020 and May 2025, and its main conclusion is that there isn't even a consensus on a clear definition of the term, according to Al-Qora'n and Al-Said Ahmad in 2025. A second study from 2026, with a multivocal literature review of 67 sources between 2022 and 2026, reaches a similar conclusion about the lack of solid empirical bases for decisions that the industry is already making for millions of dollars, as reported on ResearchGate in 2026. The Tsinghua Science and Technology journal published research in 2026 on microservice architectures for industrial automation with real-time requirements, specifically focusing on Industry 4.0, as researched by Martínez et al. in 2026. In the literature from Indian, European, and US institutions, the pattern repeats: dozens of papers discuss how to migrate from monolith to microservices, including topics such as automatic boundary identification with AI, dependency graphs, and machine learning. However, very little research answers when it's convenient to do so, and almost no rigorous and reproducible comparison of real costs at an enterprise scale exists. A 2025 paper on arXiv, directly titled "Microservices Are Dying", proposes abandoning the microservice unit in favor of universal module interfaces, which suggests that even within the most enthusiastic technical community, the vocabulary itself is starting to feel insufficient. The twist nobody saw coming: AI that orchestrates AI chose the modular monolith. This is, for me, the most interesting finding of the entire research, and it directly answers the question I asked myself at the beginning: does generative AI push towards more distribution or more consolidation? In 2025, the AI agent industry had its own binary debate: mesh architectures, which involve multiple agents talking to each other without a central coordinator, versus a single agent with tools. Cognition, the company behind Devin, published a strong stance in June 2025, stating "Don't build multi-agent systems". By 2026, that polarized debate collapsed into a single pattern that Anthropic, OpenAI, and Cognition itself adopted independently: an orchestrating agent that possesses the complete context and dispatches ephemeral sub-agents for isolated tasks, each with its own fresh context window, without point-to-point channels between them and without shared mutable state. Notably, there are no point-to-point channels between these sub-agents. This approach is not a microservices mesh architecture, but rather almost a textbook definition of a modular monolith: a central process with total authority, modules invoked on demand, clear boundaries, and communication that never leaves the orchestrator's control. Anthropic documents that its code agents run exactly like this: a single agent loop with a broad catalog of tools, not a mesh of independent services. OpenAI took the same path from Swarm, which is discontinued, to its current SDK with explicit handoffs, and no mesh coordinator. In December 2025, the Agent2Agent protocol joined MCP under a new Linux Foundation dedicated to AI and agents, known as AAIF. The coordination infrastructure is being standardized, but the pattern being standardized is hierarchical, not flat mesh. If the question is "does AI push towards monoliths or microservices?", the answer that real-world AI builders' behavior indicates, rather than their marketing talk, is: towards a modular monolith with disposable subagents, not a distributed mesh of autonomous microservices. The details of how we arrived at the modular monolith with sub-agents are explained in the article. If you're starting a project in 2026, here's what I'd do. There's no one-size-fits-all answer, but there is a consistent pattern in every serious source I reviewed, from the Amazon Prime Video case to the academic systematic literature review. Start with a modular monolith, not a flat monolith or microservices, and define clear domain boundaries, using Domain-Driven Design, from the first commit, even if everything runs in a single process. Extracting a well-defined module to an independent service later is cheap, whereas undoing a poorly defined microservices mesh is extremely expensive. Extract a service only when you have real evidence, not intuition, such as a genuine need for independent scaling, regulatory requirements for physical isolation, like PCI in payments, or a truly incompatible tech stack, like Python for ML, or Go for the core. Team size matters more than product size, and the threshold that keeps coming up in 2025-2026 literature, teams of 50 or more engineers with clear organizational boundaries, is the point where microservices start to justify their coordination cost, as Conway's Law applied in reverse suggests. If you're integrating AI agents into your architecture, the pattern that Anthropic and OpenAI validated in production, a central orchestrator with ephemeral, isolated subagents, is currently the option with the most real-world evidence behind it, not the peer-to-peer agent mesh that was discussed in 2024.