The Future Is Modular: What a Decade of Running Kubernetes Teaches Us About Platform Engineering

AI generated image for The Future Is Modular: What a Decade of Running Kubernetes Teaches Us About Platform Engineering

Somewhere, right now, a platform team is doing what platform teams do best: opening a spreadsheet, listing “things developers need,” and then quietly realizing that the list contains everything from GPU scheduling and policy-as-code to “a button that makes Kafka happen.”

That moment—equal parts ambition and mild dread—is exactly why modular platform thinking is having a moment. In a recent Giant Swarm post, “The future is modular: what a decade of running Kubernetes taught us about platforms”, Oliver Thylmann makes the case that the era of “buy a bundle and hope for the best” is ending. The argument isn’t that bundles are evil; it’s that they age like milk once an organization has real opinions, real constraints, and real pre-existing tooling. The post is worth reading in full, and this article is an expanded field guide to what “modular” actually means in 2026—and what it costs you in decisions, integration work, and governance if you get it wrong. (Original source: Giant Swarm blog, authored by Oliver Thylmann.)

Let’s unpack what a decade of Kubernetes operations is teaching the industry: why Internal Developer Platforms (IDPs) have become the de facto “experience layer,” why modularity is both the cure and a potential new disease, and why AI infrastructure is turning “platform scope creep” into “platform scope teleportation.”

From “Kubernetes everywhere” to “Kubernetes is everywhere (but not for everyone)”

Kubernetes adoption has crossed the line from trend to default. CNCF’s latest annual cloud native survey (published January 20, 2026) frames Kubernetes as the backbone of production infrastructure and reports that 82% of container users run Kubernetes in production. citeturn1search3turn1search8

And yet—despite Kubernetes becoming the infrastructure substrate—fewer developers are touching it directly. Giant Swarm’s post cites a late-2025 CNCF/SlashData data point: only about 30% of backend developers say they use Kubernetes directly, down from a peak around 36%. That aligns with third-party write-ups referencing SlashData’s “State of Cloud Native Development – Q3 2025” findings. citeturn1search5turn1search7

This isn’t a contradiction. It’s the inevitable result of maturation:

  • Managed services hide the orchestration layer (for better and worse).
  • Internal platforms become the interface developers actually use (portals, templates, paved roads, guardrails).
  • Developer population growth means more folks shipping features without needing to memorize admission webhook failure modes.

The practical implication is the same one Giant Swarm calls out: the “platform layer” is where most of the experience is shaped. If Kubernetes is the operating system, your IDP is the desktop environment—complete with all the controversial design decisions.

The “bundle trap”: when a platform tries to be your whole company

Giant Swarm names a pattern many enterprises recognize immediately: buy a comprehensive platform, use a fraction of it, keep your old tools anyway, and end up paying for overlap and complexity. They call it the bundle trap. citeturn0view0

Historically, bundling made sense. Ten years ago, cloud native was a landscape poster with more logos than a NASCAR. Buying a “complete package” reduced decision fatigue and integration risk. But once teams mature, the story changes:

  • Security already standardized on a specific scanning + policy workflow.
  • Observability already built around Prometheus/Grafana, Datadog, Elastic, or a carefully negotiated “please don’t change vendors” contract.
  • CI/CD already optimized around a developer workflow and compliance controls.

A new platform that insists on replacing those investments isn’t “simplifying”; it’s introducing a second reality. And parallel realities are expensive—not only in license fees but in cognitive load, duplicated dashboards, conflicting policies, and the operational joy of “which system is authoritative?”

Bundling vs. modularity is not a moral debate

It’s tempting to frame this like a software architecture flame war: monoliths bad, microservices good, bundles bad, modular good. Reality is more annoying. Bundles can be great when:

  • You’re early in maturity and need speed-to-baseline.
  • You lack the staffing to curate an ecosystem safely.
  • You want a single throat to choke (or at least a single Slack channel to escalate in).

Modularity wins when:

  • You already have working building blocks and don’t want forced replacement.
  • You operate across hybrid/multi-cloud environments and need interoperability.
  • You want cost visibility and the ability to add capabilities only when they prove value.

Giant Swarm’s core thesis is that modern organizations increasingly fit the latter profile. citeturn0view0

What “modular platform” actually means (and what it doesn’t)

“Modular” is an easy word to love because it sounds like LEGO. It also sounds like you can stop thinking about integration. You cannot. The modular platform promise is not “do whatever you want”; it’s “assemble a platform that fits your org without building everything from scratch.”

In practice, modularity tends to show up as:

  • A core Kubernetes foundation (clusters, lifecycle management, upgrades, fleet ops).
  • Optional capability layers you can adopt incrementally (observability, security hardening, connectivity/service mesh, developer portal, policy, AI infrastructure).
  • Well-defined integration points so modules can be swapped without destroying everything.

Giant Swarm positions its approach as curated modules that work together and alongside existing tools—something they argue is materially different from a raw “catalog of open source components.” citeturn0view0turn1search0

The hidden cost: modularity increases up-front choices

Every modular strategy comes with a trade-off Giant Swarm openly acknowledges: you must make more decisions. citeturn0view0

That means answering questions like:

  • Which “golden paths” are mandatory vs optional?
  • Do we standardize on one policy engine (Kyverno, OPA Gatekeeper, Kubernetes Validating Admission Policy), or allow multiple?
  • Do we enforce GitOps everywhere, or allow exceptions for legacy?
  • Where does the developer portal stop and the platform backend begin?

Organizations that do modularity well treat these decisions as product design, not tool selection.

The platform layer is now the developer experience layer

If only ~30% of backend developers use Kubernetes directly, the “real” platform interface is whatever developers actually touch. In 2026, that’s typically an internal developer portal backed by a platform orchestrator, templates, and self-service APIs.

Backstage remains the canonical example. It began as an internal Spotify project (started in 2016, open sourced in 2020), and it’s now a CNCF project used widely to unify tooling and reduce developer context switching. citeturn3search1turn3search2turn3search5

Backstage is also a useful illustration of modularity’s double edge:

  • Modular upside: plugins, integrations, and customization let you fit your org.
  • Modular downside: setup and glue work can become the product.

Spotify itself noted that Backstage has been adopted by thousands of companies, and it has leaned into making an out-of-the-box experience easier through offerings like Spotify Portal. citeturn3search3turn3search8

IDP vs portal vs PaaS: words matter more than we’d like

The term “IDP” is overloaded. CNCF has tried to clarify the distinction between an Internal Developer Platform (the full platform capability set) and an Internal Developer Portal (the UI/interaction layer), and how these relate to PaaS. citeturn3search4

This distinction is critical for modular thinking:

  • A portal without a platform backend is a fancy catalog of links (and possibly a nice place to put your Terraform modules).
  • A platform backend without a portal often devolves into “self-service” that requires a PhD in YAML.
  • A modular platform tries to let you evolve both sides without ripping out everything at once.

Industry context: CNCF’s platform guidance points to “thin layers” and consistency

If you want a neutral “what even is a platform?” definition, CNCF’s Platforms White Paper is one of the better anchors. It describes a platform as an integrated collection of capabilities defined and presented according to the needs of the platform’s users, emphasizing consistent experiences and noting that platform teams shouldn’t necessarily implement everything themselves; they can provide the thinnest reasonable layer that creates consistency across underlying services. citeturn4search1

That sentence—“thinnest reasonable layer”—is basically modularity’s manifesto.

It also reframes the modular debate: you’re not building a mega-product. You’re building a curated experience boundary with stable interfaces and governance.

Why cost visibility keeps showing up in platform conversations

Giant Swarm connects modularity to cost: pay for what you use, avoid shelfware. citeturn0view0

FinOps data helps explain why that resonates right now. The FinOps Foundation has repeatedly reported that reducing waste is a top priority for practitioners—surfacing as the highest key priority in its survey insights. citeturn2search0

And the FinOps scope is expanding beyond raw public cloud compute. Forbes covered how the FinOps Foundation has broadened attention into “Cloud+” costs that include SaaS, licenses, and hybrid environments—exactly the territory where platform bundles can hide waste. citeturn2search5

Modularity doesn’t magically fix cloud waste. But it can reduce a specific kind of platform waste: paying for capabilities you never adopt because they conflict with existing systems or don’t match your maturity.

Modular platforms and FinOps: the emerging overlap

The overlap is not just “cost allocation.” It’s about platform choices changing how spend happens:

  • Self-service templates can enforce right-sizing defaults.
  • Policy-as-code can prevent cost-footguns (like unrestricted GPU node pools).
  • Standard observability can make unit economics visible (per team, per service, per model).

In other words: modularity should make cost governance composable, not bolted on.

The hard part: modularity can create a patchwork nobody owns

Giant Swarm is candid about modularity’s failure mode: a loosely connected patchwork of tools that “nobody fully understands.” citeturn0view0

This happens when:

  • Teams choose modules independently without an architectural “platform contract.”
  • Integration points are undocumented or rely on tribal knowledge.
  • Ownership is unclear (platform team vs app teams vs security vs SRE).
  • Upgrades break the glue (version skew becomes the unofficial fifth DORA metric).

The solution is not to abandon modularity; it’s to treat integration as a first-class product requirement, with compatibility guarantees and lifecycle management. That’s exactly why curated stacks and reference implementations exist.

Modularity in practice: the “capability ladder” approach

One of the more pragmatic interpretations of modularity is what I’d call the capability ladder: start with the minimum foundation, then add capabilities only when a real constraint appears.

Giant Swarm describes this in simple terms: start with managed Kubernetes, add observability when monitoring becomes the bottleneck, add security hardening when compliance arrives, and so on. citeturn0view0

That sounds obvious, but it’s a meaningful shift from the classic “platform big bang” where an org spends 9–18 months building an everything-platform and then discovers developers still copy-paste Helm charts from 2019.

A simple modular roadmap (that won’t survive contact with reality)

If you want a sane starting point, a modular platform roadmap often looks like:

  • Kubernetes operations module: cluster lifecycle, patching, upgrades, multi-cluster fleet management.
  • Delivery module: GitOps CD (Argo CD is a common standard; Argo is a CNCF graduated project). citeturn5search6
  • Observability module: metrics/logs/traces standards, alerting, SLOs.
  • Security & governance module: policy-as-code, admission control, image verification, secrets management.
  • Developer experience module: portal + templates + service catalog.
  • AI infrastructure module (optional but trending): GPU scheduling, model serving, cost tracking for inference/training.

The trick is that you can’t just “install” these. You must define the contracts between them: identity, networking, policy boundaries, and shared metadata (service ownership, tags, cost centers, etc.).

Policy-as-code: the modular guardrail that keeps modules from fighting

Modularity without governance becomes chaos with nicer packaging. Policy-as-code is one of the most important control surfaces for keeping modular platforms coherent.

Two widely used approaches in Kubernetes ecosystems are:

  • OPA Gatekeeper, which manages Kubernetes admission policies (written in Rego) using custom resources. citeturn5search0
  • Kyverno, a Kubernetes-native policy engine that uses Kubernetes resources and can validate/mutate/generate resources, with strong “shift-left” options via CLI scanning. Kyverno is a CNCF incubating project. citeturn5search2turn5search3

Policy engines are not just for security compliance. They’re also platform product tools: they encode what “good” looks like, enforce it consistently, and make paved roads the easiest roads.

Why Kubernetes admission policies are getting more attention

Kubernetes itself has been evolving policy primitives. For example, Kubernetes Validating Admission Policy (CEL-based) moved from alpha to beta and then GA, reducing reliance on external webhooks for some policy use cases. Gatekeeper’s documentation explicitly discusses integration with Validating Admission Policy and notes the reliability/latency benefits of in-tree admission control. citeturn5search9

In modular platforms, this matters because you want guardrails that don’t become yet another fragile dependency.

GitOps as a modular platform backbone

One reason GitOps keeps winning mindshare is that it provides a unifying “control plane” pattern for modularity: the desired state is versioned, reviewed, and rolled out consistently. Argo’s graduation in CNCF underscores how mainstream this has become. citeturn5search6

In a modular world, GitOps helps answer the question: “Who changed the platform?” with something better than “I think it was a Jira ticket.” It also standardizes module lifecycle management (install, configure, upgrade, rollback), which is the unglamorous difference between “platform” and “pile of tools.”

Infrastructure control planes: modularity for cloud resources, not just clusters

Modularity isn’t only about Kubernetes add-ons. It’s also about how teams provision and govern the cloud resources that sit outside the cluster: buckets, databases, queues, IAM roles, and the other thousand things your app needs “real quick.”

Crossplane is one prominent control plane approach: it extends Kubernetes with APIs/controllers that manage external infrastructure, designed to integrate with GitOps and to bake policy into higher-level compositions. citeturn4search4turn4search5

This is a big deal for modular platforms because it means you can make infrastructure provisioning a module with a stable developer interface. Developers request “a database” (via a platform-defined resource), and the platform ensures encryption, tagging, backups, regions, and quotas are applied consistently.

Modularity is interface design

If you’re building an internal platform and not thinking about API design, you’re going to reinvent it accidentally. Control planes (Crossplane, Terraform controllers, service catalogs, portal templates) are all interface systems. Modularity is how you prevent every team from inventing their own interface layer and calling it “flexibility.”

AI infrastructure: the new module everyone argues about in budget meetings

Giant Swarm’s post includes a telling observation: AI workloads have shifted from experiments to production systems, and AI infrastructure requirements are real—GPU scheduling, cost governance, model serving, and end-to-end observability. citeturn0view0

The timing is not accidental. CNCF’s Annual Cloud Native Survey explicitly positions cloud native as the infrastructure of AI’s future, and CNCF leadership has highlighted Kubernetes’ role in scaling inference workloads (with one CNCF post noting that 66% of AI adopters are using Kubernetes to scale inference). citeturn1search8

The Certified Kubernetes AI Conformance Program: standardization arrives (finally)

In late 2025, CNCF announced the launch of the Certified Kubernetes AI Conformance Program to define community-led standards for running AI workloads reliably on Kubernetes. The announcement notes it was launched at KubeCon + CloudNativeCon North America (Atlanta) on November 11, 2025, building on the model of Kubernetes conformance to improve portability and reduce fragmentation. citeturn4search2

Giant Swarm states it is among the first CNCF-certified AI platforms through this program. citeturn0view0turn1search0

Why should you care? Because AI infrastructure is a prime candidate for modular adoption:

  • Some organizations need it now (productized inference, RAG systems, internal copilots).
  • Some will need it later (once data governance and risk teams stop sweating).
  • Some might never need it (or will outsource it entirely).

Bundling AI infrastructure into every platform contract is a great way to pay for someone else’s GPU ambitions. Modular capability makes it “add-on when needed,” ideally on standardized foundations.

Expert perspectives: choice and modularity are becoming expectations, not perks

Giant Swarm cites a KubeCon 2025 remark by Cycloid founder Benjamin Brial: businesses increasingly expect IDPs to offer choice and modularity, not just one stack. citeturn0view0

That expectation matches what we see in adjacent ecosystem conversations, like “Backstage isn’t your whole platform,” and the repeated emphasis that portals alone don’t make an IDP. Platform engineering as a discipline is increasingly about composing experiences, not building one giant golden hammer.

Implications for platform teams: product thinking or pain

If modularity is the destination, platform teams need to evolve from “operators of clusters” to “product teams for internal customers.” That’s not motivational-poster language; it’s operational reality.

In practical terms, platform-as-a-product means:

  • Clear user personas (backend developers, data/ML, security engineers, SREs).
  • Service-level objectives for the platform itself (upgrade windows, mean time to recover, provisioning times).
  • Documentation and discoverability as first-class features (portals, catalogs, templates).
  • Roadmaps and deprecation policies so modules don’t become permanent liabilities.

CNCF’s Platform Engineering Maturity Model reinforces that platforms are not just tooling—they include people, process, policies, and outcomes. citeturn3search9

What to measure: outcomes, not installation counts

Most platform initiatives fail quietly by measuring the wrong things. “We installed X” is not a metric; it’s a confession. Better indicators include:

  • Time-to-first-deploy for a new service using paved paths.
  • Percentage of workloads compliant with baseline policies without manual tickets.
  • Reduction in incident frequency tied to standardized rollout patterns.
  • Developer satisfaction (and yes, you can measure it without making everyone fill out a 40-question survey).

If you need an external north star, DORA-style delivery performance metrics are commonly used in the industry, even if organizations interpret them differently. The point isn’t to obsess over “elite”; it’s to connect platform modules to measurable delivery improvements.

Implications for buyers: avoid buying a new lock-in while fleeing the old one

Modularity can reduce vendor lock-in, but it can also repackage lock-in. A modular platform that only swaps modules inside one vendor’s ecosystem isn’t really modular—it’s “choose your own bundle.”

Here are practical procurement questions that separate true modularity from marketing modularity:

  • Can modules be adopted independently? Or do you need the whole stack contractually/technically?
  • Are interfaces open and portable? (APIs, CRDs, GitOps workflows, conformance programs.)
  • What happens if you leave? Are you left with upstream OSS components you can operate, or proprietary glue you can’t replace?
  • How are upgrades handled across modules? Version skew is the enemy of modularity.

CNCF’s Kubernetes conformance work exists precisely because interoperability is a prerequisite for meaningful choice. The Certified Kubernetes Software Conformance program frames conformance as enabling interoperability and flexibility across installations. citeturn4search0

So… is the future actually modular?

Yes—with a very important footnote: modular platforms will win not because they’re fashionable, but because they reflect how enterprises actually operate in 2026.

Organizations have legacy tools, compliance constraints, multi-cloud realities, and teams with strong opinions. The idea that one vendor bundle will perfectly match all of that is increasingly unrealistic. Giant Swarm’s “bundle trap” framing is a concise way to describe the mismatch, and their conclusion—that the “buy a platform and hope it covers everything” era is ending—fits the broader industry signals: Kubernetes is ubiquitous, developers want abstraction and self-service, and AI is adding entirely new workload classes that should be adoptable on demand. citeturn0view0turn1search8

But modularity isn’t a free lunch. It forces early architectural choices, requires disciplined integration work, and demands governance and product management. If you don’t invest in those, you don’t get a modular platform. You get a tool museum with excellent intentions.

Practical takeaways (for the people who have to make this real)

  • Start with contracts. Define the platform interfaces (APIs, templates, identity, policy boundaries) before you pick modules.
  • Adopt capabilities incrementally. Treat modules like features: ship, measure, iterate.
  • Standardize governance. Use policy-as-code and GitOps to keep modularity coherent.
  • Design for AI without forcing it. AI infrastructure should be an add-on capability, ideally aligned with emerging conformance standards.
  • Measure outcomes. If the platform doesn’t reduce cognitive load or time-to-delivery, it’s not a platform; it’s a side quest.

Sources

Bas Dorland, Technology Journalist & Founder of dorland.org