Two sides, a WhatsApp group, and no clear winner
No need to invent an anecdote: anyone leading an engineering team in 2026 has lived through this scene. One group swears that breaking up the monolith was the best decision of their career. The other group, in the same chat, sends screenshots of Kubernetes bills that don't go below five figures a month. Neither is lying. That's exactly the problem: software architecture stopped being a technical discussion and became a tribal identity debate, with real data on both sides supporting opposing views.
Before joining a side, I decided to do what I hadn't done in a year and a half of being in this Slack debate: chase every statistic down to its origin. What I found isn't a winner. It's a map of who's doing what, why, and — this is the interesting part — how different the public discourse is from the actual behavior 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" (ManoIT / DEV Community, 2026). I went straight to cncf.io, reviewed the 2024 annual survey report (CNCF, 2025), the November 2025 announcement about the study with SlashData (CNCF, 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 (CNCF/SlashData, 2025) — I confirmed this specific statistic 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) (SoftwareSeni, 2026; ThirdEyeData, 2026; ByteIota, 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 — and was missing from the original draft of this piece, so I went to find the real post — 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 (Amazon Prime Video Engineering, 2023).
The most-cited case against microservices
Amazon Prime Video's infrastructure cost reduction after consolidating its video monitoring service into a monolith.
90%
Infrastructure cost reduction (2023)
Ver los datos
| Indicador | Valor |
|---|---|
| Infrastructure cost reduction (2023) | 90% |
That case — already three years old — remains the go-to citation for anyone arguing against microservices, and for good reason: it comes from the same company that taught the world about microservices.
Shopify: proof that "monolith" isn't synonymous with "small"
If the argument for microservices was always "you won't scale without them," Shopify disproves it with concrete, verifiable numbers on their own engineering blog. The platform operates what they call a "majestic monolith": a single Ruby on Rails application, organized internally into components with strict boundaries imposed by a tool they developed for that purpose, Packwerk (Shopify Engineering, s.f.). During Black Friday traffic peaks, the infrastructure handles tens of terabytes of data per minute, with the database layer partitioned by store (shop_id) instead of fragmenting the application code into separate services (Kovyrin, en TechWorld with Milan, 2025).
The distinction matters: Shopify didn't avoid modularity, they avoided distribution. Their components are separated by code boundaries (bounded contexts, in Domain-Driven Design language), but they run in the same process, without network calls between them. That's exactly the definition of "modular monolith" that almost all the literature from 2025-2026 identifies as the real, non-binary third way between classic monolith and microservices (Al-Qora'n & Al-Said Ahmad, 2025) — the first academic systematic literature review on the topic, published in the Future Internet journal, found only 15 peer-reviewed primary studies between 2020 and May 2025, which says something important: industry practice is years ahead of the formal research that supports it.
Radar 1 — What the big software houses actually do
Radar 1 — What the big software houses actually do
Editorial scores 0-10 assigned based on quoted statements in the text for each company, not a formal survey. Each axis is oriented so that a higher value is always "better" on that axis.
- SAP (legacy ERP in transition)
- Shopify (native modular monolith)
- Oracle (hybrid SOA)
- Anthropic / OpenAI (native AI)
Ver los datos
| Eje | SAP (legacy ERP in transition) | Shopify (native modular monolith) | Oracle (hybrid SOA) | Anthropic / OpenAI (native AI) |
|---|---|---|---|---|
| Legacy independence | 2 | 8 | 4 | 9 |
| Deployment speed | 3 | 7 | 4 | 9 |
| Operational simplicity | 4 | 7 | 3 | 8 |
| Native AI/agent integration | 3 | 5 | 3 | 10 |
| Cost efficiency per feature | 3 | 8 | 4 | 7 |
| Boundary governance maturity | 6 | 9 | 5 | 8 |
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 (SAP Community, 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 (SOA) (Oracle, Wikipedia, s.f.), and since then the "Project Spectra" has been moving functionality towards microservices in containers on managed Kubernetes (OKE), using the Helidon framework (Oracle Cloud Blog, 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.
<strong>Microsoft</strong> 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 (Murmu Software, 2026). Its own internal AI practice (the "orchestrator with isolated sub-agents" I describe below) confirms this philosophy.
<strong>Apple</strong> 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 (Tariq, 2025). This is the same pattern Shopify uses in its backend, applied to the client.
<strong>Anthropic and OpenAI</strong> 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 (Anthropic Engineering). OpenAI abandoned its experimental Swarm framework (2024) for the Agents SDK (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 (OpenAI Swarm repo; Tao An, 2026). I'll come back to this in the AI section because it's, to me, the most revealing finding of the entire investigation.
For this radar, I chose six axes that the research itself identified as the most revealing: <strong>architectural independence from legacy</strong>, <strong>deployment speed</strong>, <strong>assumed operational complexity</strong>, <strong>native integration of AI/agents</strong>, <strong>maintenance cost per feature</strong>, and <strong>maturity of boundary governance</strong> (how seriously they take Conway's Law). I compared four representative profiles — SAP (legacy ERP in transition), Shopify (native modular monolith), Oracle (hybrid SOA), and Anthropic/OpenAI (native AI, orchestrator + sub-agents) — because trying to graph 24 companies in a single radar would have been illegible. The rest of the corporate landscape — 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
Radar 2 — The other side: who keeps open source going
Editorial scores 0-10 derived from quoted statements about each project, not a formal survey.
- Linux (kernel)
- PostgreSQL
- Kubernetes
- Proxmox
Ver los datos
| Eje | Linux (kernel) | PostgreSQL | Kubernetes | Proxmox |
|---|---|---|---|---|
| Declared monolithic philosophy | 10 | 8 | 1 | 9 |
| Reduced maintenance team | 3 | 5 | 1 | 9 |
| Internal modularity without network | 8 | 7 | 2 | 7 |
| Adoption scale | 10 | 8 | 9 | 5 |
| Independence from a foundation | 6 | 7 | 2 | 9 |
Here, the user's question that originated this piece was spot on: what do the maintainers of Linux Foundation, MySQL, MariaDB, PostgreSQL, Proxmox, and 30 other high-impact projects do? The short answer: the open-source world has been having this discussion for <em>decades</em>, long before "microservices" was a corporate buzzword.
The foundational case is the <strong>Linux kernel</strong>. In 1992, Andrew Tanenbaum publicly wrote to Linus Torvalds 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 (Tanenbaum-Torvalds debate, Wikipedia, 1992). Torvalds responded, with his characteristic tone, that microkernels "push the problem to the communication space, which is a bigger problem than the one they claim to solve" (Torvalds, sobre el debate micro vs. monolítico). Thirty-four years later, Linux — monolithic — runs on the vast majority of servers on the planet, and GNU Hurd — microkernel — remains an academic project. The irony is evident: the infrastructure that makes it possible to run microservices (containers, Kubernetes, the entire cloud) is built on a kernel that won its own war by being monolithic.
<strong>PostgreSQL, MySQL, and MariaDB</strong> live by the same logic in the data layer: they're monolithic processes (or nearly so) by design, and the community actively discusses whether "breaking down" a database into data microservices makes sense or is simply reintroducing network complexity where there used to be a function call (Reintech, 2026). The dominant answer in 2025-2026: keep the database monolithic and put application microservices around it, not inside.
<strong>Proxmox</strong> is the most straightforward example of the "other style" of open source: a small Austrian company without the backing of a foundation like CNCF or a multi-vendor government, maintaining an all-in-one platform (hypervisor + LXC containers + storage + networking) that's deliberately simple compared to the native Kubernetes alternative, KubeVirt (Kubermatic, 2026). It's the same pattern in infrastructure software that André Staltz described years ago as the "monolithic school" of open source: projects like WordPress, Django, or Linux itself, which solve a big problem as a cohesive block, versus the "modular school" that releases a utility per package (Staltz, 2018). Even years later, it's still the most useful mental framework I've found to explain why Gogs (a single binary, a single maintainer) and Kubernetes (hundreds of coordinated pieces) represent opposing philosophies within the same open source movement (Laoutaris, 2025).
For this analysis, I used five axes: <strong>declared monolithic philosophy</strong>, <strong>maintainer team size</strong>, <strong>internal modularity without networking</strong>, <strong>adoption scale</strong>, and <strong>foundation governance dependence</strong>. I compared Linux (kernel), PostgreSQL, Kubernetes, and Proxmox — the four most cited reference points in the technical literature I reviewed, within the 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) that are documented in the methodology.
Radar 3 — Governments: four philosophies, one scaling problem
Radar 3 — Governments: four philosophies, one scaling problem
Editorial scores 0-10 derived from quoted statements about each government block, not a formal survey.
- United States
- European Union
- China
- India
Ver los datos
| Eje | United States | European Union | China | India |
|---|---|---|---|---|
| Cloud infrastructure maturity | 5 | 7 | 8 | 7 |
| Declared modularity/interoperability | 3 | 10 | 4 | 8 |
| Proven transaction scale | 6 | 5 | 7 | 10 |
| Sovereignty over private providers | 4 | 8 | 10 | 6 |
| Internal systems maturity | 3 | 6 | 7 | 8 |
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 <strong>United States</strong> is experiencing the worst of both worlds: according to figures from the Government Accountability Office (GAO), 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 (GAO, 2025). 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 <strong>European Union</strong> 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 <em>"Avoiding the Monolith: Integrating Microservices for Frictionless Digital Transformation"</em> (ITU Academy / GovStack, 2025). Its technical specification defines "building blocks" (digital identity, data exchange, workflow orchestration) as interoperable modules that can be composed of domain microservices (GovStack Specification, s.f.). It's, in the vocabulary of this article, an explicit institutional bet on the microservices side of the debate, with the argument of European digital sovereignty (EuroStack) pushing in the same direction (Bertelsmann Stiftung, 2026).
<strong>India</strong> built, without ever using the term "microservices" in public discourse, the largest example of layered architecture on the planet: India Stack. Aadhaar (biometric identity, 1.4 billion people enrolled), UPI (instant payments, 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 (Policy Circle, 2026; corroborated independently by a comunicado del gobierno de India). Academic research on public digital infrastructure confirms that these architectures explicitly use microservices with standardized APIs as the dominant technical pattern (arXiv 2503.08725, 2025). It's 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.
<strong>China</strong> is betting on a centralized "government cloud" (政务云) infrastructure with 100% coverage in county-level or higher administrations, as part of its "China Digital" strategy (National Data Administration / Digital China Wins the Future, 2026). 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 (IDC, vía Huawei Cloud, 2026). Architecturally, it's the opposite of the European model, although it shares the use of microservices as an internal technical implementation pattern.
How much of the tech budget goes into maintaining what already exists
Percentage of tech spending dedicated to maintaining existing systems/infrastructure instead of building something new.
Ver los datos
| Concepto | Valor (%) |
|---|---|
| United States — % of $100,000M+ annual spend on maintaining legacy systems | 80% |
| China — % of ~200,000M yuan projected in government cloud infrastructure | 73% |
Four governments, four architectural stances
Summary of stance and key metric cited for each government block.
| Government | Architectural stance | Key metric cited |
|---|---|---|
| United States | Fragmented / legacy | ~80% of $100,000M+ annual spend on maintaining legacy systems |
| European Union | Microservices / explicit building blocks | GovStack + EuroStack, digital sovereignty |
| India | Layered architecture (India Stack) | 22,350M UPI transactions in April 2026 |
| China | Centralized government cloud | 100% coverage in counties+, ~200,000M yuan projected |
Ver los datos
| Government | Architectural stance | Key metric cited |
|---|---|---|
| United States | Fragmented / legacy | ~80% of $100,000M+ annual spend on maintaining legacy systems |
| European Union | Microservices / explicit building blocks | GovStack + EuroStack, digital sovereignty |
| India | Layered architecture (India Stack) | 22,350M UPI transactions in April 2026 |
| China | Centralized government cloud | 100% coverage in counties+, ~200,000M yuan projected |
Japan and South Korea don't have a documented or distinctive architectural stance in the literature I reviewed — 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: <strong>cloud infrastructure maturity</strong>, <strong>declared modularity/interoperability</strong>, <strong>proven transaction scale</strong>, <strong>state sovereignty and control over private providers</strong>, and <strong>complexity and maturity of internal systems</strong> (the axis you specifically asked me to prioritize). I compared the United States, the European Union, China, and India 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 <em>systematic literature review</em> on modular monoliths in the cloud — published in October 2025 in the <em>Future Internet</em> 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 (Al-Qora'n & Al-Said Ahmad, 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 (ResearchGate, 2026).
The <em>Tsinghua Science and Technology</em> journal published research in 2026 on microservice architectures for industrial automation with real-time requirements (Martínez et al., 2026) — a specific technical angle (Industry 4.0), not a Chinese institutional stance on the general debate. In the literature from Indian, European, and US institutions, the pattern repeats: dozens of papers on <em>how</em> to migrate from monolith to microservices (automatic boundary identification with AI, dependency graphs, machine learning), but very little research that answers <em>when</em> it's convenient to do so, and almost no rigorous and reproducible comparison of real costs at an enterprise scale. A 2025 paper on arXiv directly titled <em>"Microservices Are Dying"</em> proposes abandoning the "microservice" unit in favor of universal module interfaces — a sign that even within the most enthusiastic technical community with distribution, the vocabulary itself is starting to feel insufficient (arXiv 2511.04548, 2025).
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 (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: "Don't build multi-agent systems" (Cognition, 2025, vía FlowHunt, 2026). 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 (FlowHunt, 2026).
Read that again: **no point-to-point channel between them**. That's not a microservices mesh architecture - it's 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 itself 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 (Anthropic Engineering). OpenAI took the same path from Swarm (discontinued) to its current SDK with explicit handoffs, no mesh coordinator.
In December 2025, the Agent2Agent (A2A) protocol joined MCP under a new Linux Foundation dedicated to AI and agents (AAIF) (Linux Foundation, dic. 2025) - 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 throws up - not their marketing talk - is: towards a modular monolith with disposable subagents, not a distributed mesh of autonomous microservices.
How we arrived at the modular monolith with sub-agents
Timeline of milestones cited in this research on AI agent architecture.
- 1992Tanenbaum tells Torvalds that a monolithic kernel is a step back — Torvalds responds that microkernels just move the problem to communication.
- 2023Amazon Prime Video consolidates its monitoring service into a monolith and reduces infrastructure costs 90%.
- 2025Cognition (Devin) publishes "Don't build multi-agent systems".
- 2025AAIF is founded under Linux Foundation, with MCP and Agent2Agent as anchor projects.
- 2026CNCF and SlashData report 46% of backend developers using microservices, amid consolidation debate.
Ver los datos
| Año | Hecho |
|---|---|
| 1992 | Tanenbaum tells Torvalds that a monolithic kernel is a step back — Torvalds responds that microkernels just move the problem to communication. |
| 2023 | Amazon Prime Video consolidates its monitoring service into a monolith and reduces infrastructure costs 90%. |
| 2025 | Cognition (Devin) publishes "Don't build multi-agent systems". |
| 2025 | AAIF is founded under Linux Foundation, with MCP and Agent2Agent as anchor projects. |
| 2026 | CNCF and SlashData report 46% of backend developers using microservices, amid consolidation debate. |
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:
1. **Start with a modular monolith, not a flat monolith or microservices**. Define clear domain boundaries (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; undoing a poorly defined microservices mesh is extremely expensive.
2. **Extract a service only when you have real evidence**, not intuition: genuine need for independent scaling, regulatory requirements for physical isolation (like PCI in payments), or a truly incompatible tech stack (Python for ML, Go for the core).
3. **Team size matters more than product size**. 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 (Conway's Law applied in reverse).
4. **If you're integrating AI agents into your architecture**, the pattern that Anthropic and OpenAI validated in production - 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.
The final stop sign of this research
Confidence distribution of the 39 pinpoint citations in the text.
- Green — primary or corroborated — 56%
- Yellow — single secondary source — 41%
- Red — unverifiable, visible for transparency — 3%
Ver los datos
| Segmento | Valor |
|---|---|
| Green — primary or corroborated | 22 |
| Yellow — single secondary source | 16 |
| Red — unverifiable, visible for transparency | 1 |
Does the answer change if the decision is no longer made by a human?
This is my real question, the one that led me to this entire investigation: in two or three years, when an AI agent proposes the initial architecture for your next project - and it's already happening, with tools suggesting folder structures and module boundaries - will it still recommend "start simple, distribute only with evidence"? Or will the ease with which AI generates and maintains distributed code (more services, more YAML, more configuration) tip the balance back towards complexity, simply because it's no longer a human who has to maintain it?
What have you seen: do your code copilots push you towards more simplicity or more moving parts?
Esteban Rey
X: @Kilowatto
LinkedIn: https://www.linkedin.com/in/kilowatto
Wikidata: https://www.wikidata.org/wiki/Q140672978
Metodología de esta investigación
This investigation was developed under the "in-depth research + counterpoint/replica" variant: there's a dominant stance (microservices as the inevitable destination of modern architecture, consolidated between 2015 and 2022) that in 2024-2026 faces a documented counterpoint with real-world cases (Amazon Prime Video, Shopify, the consolidation reported by CNCF, the Linux kernel since 1992). This variant was chosen over the "background/context + current events" alternative because the topic has two active and verifiable sides today, not a recent event that requires extensive historical background - by explicit instruction of the scope, the timeframe was limited to 2024-2026, with only two brief historical references (the Tanenbaum-Torvalds debate of 1992 and the Amazon Prime Video case of 2023) due to their direct relevance as technical precedents actively cited in 2026.
We explored different angles of research: in favor of microservices (enterprise adoption, scaling cases, India's DPI), against/consolidation (CNCF, reversal cases, operational costs), neutral/market (market research reports, adoption figures), technical (kernel architecture, databases, IA agent orchestration), regulatory/governmental (US, EU, China, India), and academic (systematic literature reviews, university papers 2025-2026). We consulted over 65 different sources during the original research, exceeding the minimum of 50 required; of those, 39 were directly cited and referenced in the body of this version — the rest informed the general landscape without supporting a specific, attributable fact.
The most significant finding from the fact-checking process was methodological: the figure "42% of organizations consolidating microservices (CNCF, 2025)" — the most cited in the entire debate — couldn't be confirmed against a publicly available primary document from CNCF, despite multiple attempts to track it down directly on cncf.io. We're keeping it in the text with an explicit confidence marker and context about its probable origin (content generated by an automated IA pipeline, cited in a chain), rather than omitting it or presenting it as a confirmed fact, because its circulation itself is relevant data on how technical consensus is formed in 2026.
The three radar charts use comparative data derived directly from the findings of this research, not free estimates; each axis is based on at least one source cited in the body of the text or in this section.
Additional verification was done on the original draft: we found and added the real primary source from the Amazon Prime Video engineering blog, which was missing from the initial bibliography; we resolved the "ManoIT, 2026" citation against its actual article on DEV Community, confirming it's content produced by an automated pipeline; we reinforced the UPI transaction figure for April 2026 with a direct statement from the Indian government, upgrading it from yellow to green; we replaced an Anthropic citation pointing to a post on security containment — not agent architecture — with one that directly describes the design of a single agent with subagents; and we replaced the secondary reference to US federal spending with the primary GAO report. None of the findings contradicted the original conclusions of the text.
Fuentes
- ManoIT / DEV Community, 2026
- CNCF, Encuesta Anual 2024
- CNCF y SlashData, nov. 2025
- SoftwareSeni, 2026
- ThirdEyeData, 2026
- ByteIota, 2026
- Amazon Prime Video Engineering, 2023
- Shopify Engineering, s.f.
- Kovyrin, en TechWorld with Milan, 2025
- Al-Qora'n & Al-Said Ahmad, 2025 (Future Internet)
- SAP Community, 2025
- Oracle Fusion Applications, Wikipedia
- Oracle Cloud Blog, 2023
- Murmu Software Infotech, 2026
- Abdullah Tariq, 2025
- Anthropic Engineering
- OpenAI Swarm (repositorio)
- Tao An, 2026
- Debate Tanenbaum-Torvalds, Wikipedia, 1992
- Torvalds, sobre el debate micro vs. monolítico
- Baeldung on Linux, 2024
- Reintech, 2026
- Kubermatic, 2026
- André Staltz, 2018
- Laoutaris, 2025
- GAO, 2025
- ITU Academy / GovStack, 2025
- GovStack Specification, s.f.
- Bertelsmann Stiftung, 2026
- Policy Circle, 2026
- Gobierno de India (PIB), 2026
- arXiv 2503.08725, 2025
- Digital China Wins the Future, 2026
- IDC, vía Huawei Cloud, 2026
- ResearchGate, 2026
- Martínez et al., 2026 (Tsinghua Science and Technology)
- arXiv 2511.04548, 2025
- FlowHunt, 2026
- Linux Foundation, dic. 2025
Frequently asked questions
What percentage of organizations are consolidating microservices according to the CNCF survey?
The cited figure is 42%, but it couldn't be verified against a primary readable document, so it should be treated as 'widely repeated, not independently verified'.
What did Amazon Prime Video do with its software architecture?
Amazon Prime Video consolidated a video quality monitoring service from a distributed architecture to a monolith, achieving a 90% reduction in infrastructure costs.
How is Shopify's software architecture structured?
Shopify operates a 'majestic monolith', a single Ruby on Rails application with internal components organized using the Packwerk tool, without breaking the code into separate services.
What type of software architecture does SAP use?
SAP describes its S/4HANA core as a 'massive modular monolith' that's being gradually broken down into cloud-native architectures.
What's the software design philosophy of Anthropic and OpenAI?
Anthropic and OpenAI use an architecture pattern that involves a central orchestrator with bounded sub-agents, rather than a peer-to-peer mesh of microservices.
What percentage of backend developers work with microservices according to the CNCF survey?
46% of backend developers work with microservices, according to the CNCF survey.
What's a modular monolith in the context of software architecture?
A modular monolith refers to a software architecture where components are separated by code boundaries, but run in the same process, without network calls between them.
Larry
Comentarios
Sé el primero en comentar.