Building an internal developer platform (IDP) is more than installing Backstage and calling it done. As organizations mature their platform engineering practices, they discover that the real challenge lies in the messy middle - the orchestration layer between your developer portal and your infrastructure. This post explores the architectural decisions every platform team faces and introduces a control plane approach that scales with your needs.

Main insights

• Backstage excels as a developer experience layer but becomes brittle when it doubles as the central orchestration engine for all platform capabilities.
• A dedicated control plane sitting between your portal and infrastructure tools provides cleaner separation of concerns and long-term architectural flexibility.
• The control plane pattern - exemplified by projects like Open Coro - lets you swap frontend experiences and backend tools without rebuilding everything from scratch.
• Platform abstractions must balance developer simplicity with enough flexibility to handle real-world edge cases.

Kelsey Hightower, a distinguished engineer known for his foundational work with Kubernetes and cloud-native computing, joined Samira Jayasekara and Lakmal Warusawithana, both VPs, distinguished engineers from the WSO2 team, to share hard-won lessons from building production IDPs. Their collective experience spans early custom portals through to modern control plane architectures.

You can watch the full discussion here if you missed it.

The evolution of internal developer platforms

Most platform engineering journeys follow a familiar arc. You start by giving developers access to raw infrastructure - VMware consoles, Kubernetes clusters, cloud consoles. But unmediated access creates chaos: configuration drift, security gaps, and systems that nobody can diagnose at 3 AM.

The natural response is building a portal. Before Backstage became mainstream, teams built custom Ruby on Rails interfaces or similar solutions to provide a service catalog, basic workflows, and a friendlier face on infrastructure. Backstage formalized this pattern and gave teams a shared framework instead of starting from scratch every time.

As Samira explained, "Backstage is designed as an internal developer portal framework. It has the right abstractions and building blocks to design that portal." The framework provides a plugin system, a software catalog, and templates for common workflows. You can integrate your existing tools - GitHub Actions, Kubernetes, observability platforms - through annotations and plugins.

But here is where things get complicated. As developers request more capabilities, you add more integrations. Each new tool means more glue code in Backstage. The portal that started as a simple catalog becomes a complex orchestration engine. Samira described this accumulation as "the messy middle" - a growing tangle of integration code that makes your platform brittle and difficult to evolve.

The control plane architecture

The solution is rethinking where different responsibilities live in your platform. Rather than making Backstage the center of everything, you introduce a control plane layer that owns orchestration and abstractions.

In this model, Backstage moves to the developer experience layer. It becomes one of several possible interfaces to your platform - alongside CLIs, AI agents, or other tooling. The control plane sits in the middle, exposing stable APIs that any experience layer can consume. Behind the control plane, you organize infrastructure into separate planes: data planes for workloads, observability planes for monitoring, and workflow planes for CI/CD.

Kelsey articulated why this separation matters: "If we realize that a control plane can be stable regardless of the surface people use to interact, then the middle can evolve at our own pace. As trends change, you don't have to go back and rewrite everything."

This is a critical architectural insight. Decoupling the experience layer from the orchestration layer means that when the next generation of developer tooling arrives - whether that is an AI-native interface or something nobody has built yet - you are not locked into a full platform rewrite.

Designing platform abstractions

The hardest part of building a control plane is designing the right abstractions. You need concepts that make sense to developers without exposing every infrastructure detail, while still providing enough flexibility to handle edge cases without forcing developers to break out of the platform entirely.

The WSO2 team learned this through years of iteration. They started with custom abstractions, then adopted Kubernetes Custom Resource Definitions (CRDs) and controllers. As Lakmal explained, "We realized that without reinventing the wheel we can use existing frameworks like Crossplane or CRD. We make the platform intent into declarative definitions and Kubernetes control loops make sure it's reconciled into the actual state."

Their Open Coro project demonstrates this approach in practice. Instead of requiring developers to understand Kubernetes primitives, Open Coro defines higher-level concepts like projects, components, and endpoints. A developer declares what they need - "I need a service that depends on a database and exposes port 8080 publicly" - and the control plane translates that intent into Kubernetes deployments, services, network policies, and whatever else is required. The developer never touches kubectl or writes Kubernetes manifests directly.

This abstraction layer solves several problems that plague Backstage-only implementations:

• Debugging beyond the happy path: When something breaks, developers can still investigate effectively because the control plane provides filtered access to logs, events, and terminal access - without requiring direct cluster access.
• Centralized abstractions: Your platform's data model lives in the control plane, not scattered across Backstage plugins and configuration files.
• Multi-environment support: You can support multiple clusters and environments without complex Backstage configuration sprawl.

The build vs. adopt decision

Every platform team faces this question: build your own control plane or adopt an existing solution? There is no universal answer, but the control plane pattern gives you a useful framework for thinking it through.

Building your own gives you complete control over abstractions and workflows, tailored to your organization's specific needs. The trade-off is significant engineering investment - you must design CRDs, write controllers, handle edge cases, and maintain everything as requirements evolve.

Adopting a framework like Crossplane gives you a head start on controller infrastructure so you can focus on defining abstractions through compositions. You still need to understand Crossplane's model deeply and may encounter limitations with complex orchestration scenarios.

Using a complete platform like Open Coro means abstractions, controllers, and integrations are available out of the box. The trade-off is accepting opinionated defaults about how platforms work. However, as Lakmal demonstrated, these platforms are designed to be extensible - platform engineers can define custom component types, swap backend tools through modules, and adapt the platform to their organization's needs.

The right choice depends on your team's size, expertise, and requirements. A smaller team can benefit from adopting a complete solution and customizing it incrementally. A large organization with highly specific requirements might build their own control plane using frameworks like Crossplane as the foundation. Either way, the key is understanding the total cost of ownership before you commit.

Kelsey framed the long-term stakes clearly: "One day someone's going to build something that's going to disrupt or replace Backstage. If we invest in a control plane and decouple ourselves from the left and right side of this equation, then the middle can evolve at our own pace."

​

If you enjoyed this, check out more great insights and events from our Platform Engineering Community.

​

Key takeaways

• Separate experience from orchestration: Moving Backstage to the experience layer and introducing a dedicated control plane creates cleaner boundaries. This separation lets you evolve your developer interface and your infrastructure tooling independently, reducing the risk that a change in one breaks the other.
• Design abstractions that balance simplicity and flexibility: Your platform's abstractions must hide complexity for common cases while providing escape hatches for edge cases. Invest time in understanding your organization's vocabulary and workflows before encoding them in CRDs or APIs - getting this wrong is expensive to undo.
• Plan for evolution, not perfection: No platform architecture is permanent. Whether you build or adopt, choose an approach that lets you swap components as tools and requirements change. A well-designed control plane makes this possible without rewriting everything from scratch.
• Evaluate total cost of ownership honestly: Building a control plane from scratch gives you control but requires sustained engineering investment. Adopting existing frameworks or platforms reduces initial effort but introduces customization overhead. Assess your team's capacity and expertise realistically before deciding which path fits your organization.