Giant Swarm has been running production Kubernetes for enterprises for over ten years. If there's one thing that experience has taught us, it's that no two organizations need the same platform. They share common problems, but the starting points, constraints, and existing investments are always unique. A platform that ignores all of that isn't simplifying things. It's adding a new layer of complexity.
That conviction is what led us to evolve Giant Swarm into a modular platform. Not because bundled platforms are inherently bad. When the cloud native landscape was younger and more chaotic, buying a comprehensive package was a reasonable bet. Plenty of organizations made real progress that way. But as teams matured, they developed strong opinions about their tooling, built real knowledge around specific technologies, and invested in observability, CI/CD, and security stacks that worked for them. For many, the all-in-one platform became a constraint rather than an accelerator, because it assumed none of that existing work mattered.
We see this often enough to have a name for it: the bundle trap. You pay for a comprehensive platform, use a fraction of it, and run parallel tools to cover the gaps.
The numbers tell a consistent story. The CNCF 2024 Annual Survey shows 80% of organizations now running Kubernetes in production, with 93% using, piloting, or evaluating it. Yet the CNCF/SlashData report from late 2025 found only 30% of backend developers say they use Kubernetes directly, down from a peak of 36%. There are multiple reasons for this, including the growth of the developer population and the rise of managed services that abstract Kubernetes away. But one implication is clear: the platform layer that sits between developers and infrastructure is where most of the experience is shaped. That's exactly the layer where we think the one-size-fits-all model breaks down.
The case for modularity
Giant Swarm now offers a modular, pick-and-choose model for platform capabilities. This is what we've built toward over the past decade, and I want to explain why, including the parts that are hard.
The core case is straightforward. A manufacturing company running edge workloads across dozens of factory sites has almost nothing in common with a financial services firm consolidating onto a multi-cloud Kubernetes setup. Forcing both onto the same bundled platform means one of them, usually both, ends up working around the product rather than with it. A modular approach lets you start with what you actually need, keep what already works, and add capabilities when there's a real reason to.
It also makes cost visible. You know what you're paying for and why, instead of negotiating a bundle price that includes things you'll never touch. Cloud waste more broadly is a well-documented problem: the State of FinOps 2025 report, representing organizations with over $69 billion in combined cloud spend, found that half of all FinOps practitioners rank waste reduction as their top priority. Platform licensing isn't the same thing as cloud infrastructure waste, but the underlying dynamic is similar: paying for capacity and capabilities you don't use. Modularity is one way to address that.
But modularity has real trade-offs. You make more decisions upfront. You need to think about how components integrate. And there's a version of modularity that creates a different kind of mess: a patchwork of loosely connected tools that nobody fully understands.
This is exactly the problem we've spent years solving. Our modules are built to work together and to work alongside your existing tools, because we've done the integration and curation work across more than 150 production clusters. That's different from handing you a catalogue of open source components and wishing you luck. And it's different from a monolithic bundle that assumes it knows better than you do.
What this looks like in practice
Benjamin Brial, founder of Cycloid, said something at KubeCon 2025 that resonated with me: "We're seeing more businesses expect the Internal Developer Platform to offer choice and modularity, not just one stack." That matches what we see across our customer base.
In practice, modularity means a team can start with managed Kubernetes for a handful of clusters, add observability when monitoring becomes a bottleneck, and bring in security hardening when new compliance requirements arrive. Each step proves its value before the next one starts. Nobody is forced to adopt capabilities they don't need, and nobody is paying for shelf-ware.
This applies to newer domains too. AI workloads have moved from experiments to production systems over the past year, and the infrastructure requirements are real: GPU scheduling, cost governance, model serving, observability across inference pipelines. Giant Swarm is one of the first CNCF-certified AI platforms through the Kubernetes AI Conformance Program, which means our AI infrastructure follows open, community-defined standards. But the structural point matters more than the certification: AI infrastructure is exactly the kind of capability that some organizations need now and others won't need for a year or two. It should be something you add when it makes sense, on a foundation that's already working. Not something bundled into every contract or left out entirely.
How we see it fitting together
15.6 million developers now work with cloud native tools. Hybrid and multi-cloud are becoming structural choices, not exceptions. In our experience, the organizations that get the most from their platform investments are the ones that shaped the platform around how they actually work, rather than adapting their work to fit a vendor's idea of a reference architecture.
The DIY path is always an option. But after watching teams attempt it for over a decade, I can say that the integration and operational work is genuinely hard, and it consumes exactly the kind of senior engineering time that's hardest to replace. We've done that curation and integration work across Kubernetes, observability, security, networking, AI, and developer experience, based on more than ten years of operating these systems in production. That doesn't mean it works out of the box with zero effort on your side. There's always assessment, configuration, and integration with what you already have. But it means your team isn't starting from scratch, and the foundational decisions have already been tested at scale.
The era of buying a platform and hoping it covers everything is ending. What's replacing it is more honest: you choose the capabilities you need, you keep what works, and you build on a foundation that adapts as you do. That's what we're building at Giant Swarm.
If you're navigating these trade-offs, or if you see it differently, I'd like to hear from you.
