A practical look at why internal developer platforms fail at scale, and how Kubernetes, Backstage, GitOps, and Observability — when assembled the right way — can finally work together.
There’s a quiet irony playing out inside engineering organizations right now. The team built to remove friction has become the source of it.
Platform engineering was supposed to solve tool sprawl. Instead, it often created a new problem: the platform team can’t scale fast enough to meet business demand. Developers wait. Releases slip. Engineers burn out.
This isn’t a people problem. It’s an approach problem.
<h2>The Hidden Cost of DIY Platforms</h2>
Every engineering org above a certain size eventually decides to build an Internal Developer Platform (IDP). The reasoning is sound: standardize tooling, reduce cognitive load, give developers a self-service experience.
But the execution is where things unravel. Here’s what typically happens:
→ DIY platforms take months to build and minutes to break → Every new tool added increases cognitive load, not capability → Maintenance consumes the bandwidth meant for innovation → The platform becomes a product — one that nobody signed up to maintain forever
Building an IDP from scratch in 2025 is a bit like writing your own database. Technically possible. Occasionally justified. Almost never the right first move.
<h2>Kubernetes: The Foundation the Industry Chose for a Reason</h2>
Let’s start with the elephant in the room. Kubernetes has a reputation for being complex — and that reputation isn’t entirely undeserved. But it’s also the most battle-tested, production-proven container orchestration platform in the world, and there’s a reason virtually every major cloud provider and enterprise has standardized on it.
Kubernetes isn’t complex because it was poorly designed. It’s complex because it solves genuinely hard problems:
→ Scheduling and running workloads across heterogeneous infrastructure reliably → Self-healing systems that automatically recover from failure → Declarative configuration that makes infrastructure auditable and reproducible → A rich ecosystem of extensions, operators, and tooling built over a decade of community investment → Multi-cloud and hybrid portability that prevents vendor lock-in
The CNCF ecosystem that has grown around Kubernetes is extraordinary. Service meshes, policy engines, secret management, cost optimization, progressive delivery — the community has built mature, production-ready solutions for virtually every platform concern.
Why Kubernetes won Kubernetes didn’t win because it was the simplest option. It won because it was the right abstraction at the right level — flexible enough to run anything, opinionated enough to provide a stable foundation. Over 5 million developers now use it in production. That network effect and community investment is irreplaceable.
The real challenge isn’t Kubernetes itself — it’s that raw Kubernetes requires platform teams to make hundreds of decisions before a single developer can deploy an application. Networking, RBAC, namespacing, resource quotas, ingress controllers, secrets management, CI/CD integration — all of it needs to be configured, secured, and maintained.
The answer isn’t to avoid Kubernetes. It’s to build the right abstractions on top of it.
<h2>Backstage: The Developer Portal That Changed Everything</h2>
Spotify built Backstage to solve a problem that every fast-growing engineering organization eventually hits: as the number of services, teams, and tools grows, developers spend more time navigating complexity than building product.
Backstage’s insight was elegant — give every service, API, pipeline, and piece of documentation a home. A single place where developers can discover what exists, understand who owns it, see its health, and take action on it.
Since Spotify open-sourced it and donated it to the CNCF, Backstage has become the de facto standard for internal developer portals. The reasons are clear:
→ A software catalog that gives every component, API, and resource a consistent identity and owner → TechDocs that brings documentation into the same workflow as the code it describes → A plugin ecosystem with hundreds of community-built integrations covering CI/CD, cloud providers, monitoring, incident management, and more → Scaffolder templates that let platform teams encode golden paths — so developers spin up new services the right way, every time → Search that makes the entire engineering knowledge base discoverable
The Backstage effect Organizations that have fully adopted Backstage report dramatic reductions in onboarding time for new engineers — sometimes from weeks to days. When every service has a home, when runbooks are one click away, and when deployments are self-service, developers spend their time on what matters: building.
But here’s the honest truth about Backstage: it’s a framework, not a finished product. Getting from ‘installed Backstage’ to ‘developers actually love using it’ requires significant investment in catalog population, plugin configuration, and workflow integration. Many teams underestimate this.
This is where having a platform that pre-integrates Backstage — with sensible defaults and pre-built workflows — removes the biggest barrier to adoption.
<h2>The Stack Is There. The Glue Is Missing.</h2>
The cloud-native ecosystem has matured remarkably. Every ingredient for a world-class developer platform already exists:
→ Kubernetes — the production-proven foundation trusted by millions of engineering teams worldwide → Backstage — the CNCF-graduated developer portal that gives every service a home and every developer a front door → GitOps — declarative, auditable, automated delivery pipelines that treat infrastructure as code → Observability — distributed tracing, metrics, and logging that give teams real-time confidence in what they’ve built
These aren’t new ideas. They’re proven. The challenge isn’t picking the right tools — it’s wiring them together reliably, at scale, for every team in the organization. That’s where orgs consistently lose months.
Key insight 80% of every internal developer platform is identical across organizations. The same Kubernetes abstractions. The same Backstage configuration. The same GitOps patterns. The same observability setup. Yet every team rebuilds it from scratch — costing thousands of engineering hours solving problems that are already solved.
<h2>What Good Platform Engineering Actually Looks Like</h2>
The platform teams winning right now aren’t the ones who built everything themselves. They’re the ones who had the wisdom to start with the right abstractions — and spent their energy on the 20% that’s specific to their business.
That means:
→ Giving developers a self-service experience without writing a portal from scratch → Standardizing deployment workflows without reinventing GitOps → Running on Kubernetes with guardrails that make sense for application teams → Shipping observability that surfaces the right signals — not more dashboards to ignore
The goal is to stop configuring and start enabling.
<h2>OpenChoreo: Built for Platform Teams Who Are Done Reinventing the Wheel</h2>
This is exactly the problem OpenChoreo was built to solve.
OpenChoreo is an open-source developer platform that gives platform engineers production-ready abstractions for Kubernetes — with a Backstage-powered developer portal, GitOps workflows, and observability built in. It takes the tools the industry has already standardized on and assembles them with the right defaults, so teams can go from zero to productive without months of configuration work.
It’s the 80% out of the box, so teams can focus on what actually differentiates their business.
What you get:
→ A Backstage-powered portal that gives developers a single pane of glass — without weeks of configuration → GitOps pipelines that work out of the box with the guardrails your teams actually need → Kubernetes abstractions that shield developers from complexity without hiding it from platform engineers → Built-in observability so you know what’s happening across every service, from day one
Less plumbing. More platform. Faster delivery — for everyone.
<h2>The Bottom Line</h2>
Kubernetes is exceptional. Backstage is transformative. GitOps is the right model for modern delivery. Observability is non-negotiable. These tools earned their place at the center of the cloud-native ecosystem — not through marketing, but through real-world proof at scale.
The opportunity in front of platform teams isn’t to replace them or work around them. It’s to assemble them better — with the right abstractions, the right defaults, and the right workflows — so that developers experience the best of what the cloud-native ecosystem has to offer without having to understand every layer of it.
Platform engineering doesn’t have to be a bottleneck. The tools exist. The patterns are proven. What’s been missing is a way to bring them together without months of assembly work.
If your platform team is spending more time on infrastructure plumbing than on enabling your developers — it might be time to reconsider the approach.
🔗 Explore OpenChoreo — open source, built for platform teams: <a href="https://openchoreo.dev/" target="_blank" rel="noopener nofollow">https://openchoreo.dev/</a>
⭐ Star the project on GitHub to help the community grow and keep the momentum going.

The official daily.dev DevOps community. Led by thought leaders and DevOps experts. Join the Squad!

DevOps

Platform teams built to reduce friction often become bottlenecks themselves due to DIY platform approaches that consume engineering bandwidth. The cloud-native ecosystem already has proven tools — Kubernetes, Backstage, GitOps, and observability — but organizations lose months wiring them together. The post argues that 80% of every internal developer platform is identical across organizations, making from-scratch builds wasteful. It introduces OpenChoreo, an open-source developer platform that pre-integrates these tools with sensible defaults, aiming to let platform teams skip the assembly work and focus on business-specific differentiation.

Why Your Platform Team Became the Bottleneck — And How to Fix It