Backstage Solved the Portal Problem—Not the Platform Problem
Backstage didn't fix your developer experience. It just made the mess easier to find.
You've got a shiny new portal. Catalogs. Templates. Docs. Everyone's thrilled—until someone asks, "Is my service even running?" And you realize you've built a really nice library card catalog for a factory that's still running on duct tape and whispered instructions.
Backstage solved the portal problem. Not the platform problem.
A portal organizes catalogs, documentation, and templates. A platform owns deployments, environments, policies, and runtime operations. Backstage gives you the front door. The real platform begins behind it—and most teams never build it.
I've seen this play out a hundred times. Teams adopt Backstage because it's the CNCF Incubation project with 33.9k GitHub stars. It's the "obvious" choice. They map components, spin up TechDocs, and call it a day. Then the feature requests roll in:
"I see my component in the catalog, but is it actually running?"
"I need logs, metrics, and traces for this service."
"Can I create a new component from here?"
So you glue on a Kubernetes plugin. You hook up Grafana. You build a template that scaffolds a repo, a Helm chart, and a CI pipeline. And suddenly, you've got a Frankenstein's monster of point-to-point integrations. Every upgrade breaks something. Every new team wants a custom trait. You're not building a platform—you're maintaining a pile of duct tape.
This isn't failure. It's the natural consequence of treating a portal as a platform.
The real work—the messy, architectural work—happens beneath the portal. We need a control plane. And no, it's not just another plugin.
It's the compiler between what developers say and what Kubernetes does.
The Difference Between a Portal and a Platform
Let's be clear: a portal is informational. A platform is operational.
A portal answers: "Where do I find the API docs?"
A platform answers: "How do I deploy this safely to staging?"
Backstage gives you the first. It assumes the second already exists. It doesn't care if your deployments are orchestrated by a bash script in a Jenkins job or a GitOps repo guarded by a tribal elder with a password written on a sticky note.
That's the gap. And from a security & compliance standpoint, that gap is where incidents are born.
The "messy middle"—as Sameera Jayasoma at WSO2 calls it—is where your platform dies. It's the space between your catalog and your clusters. Where every new capability requires custom wiring. Where a change to your CI pipeline breaks the Backstage entity provider. Where a new team's "unique" security policy isn't enforced because it's buried in a Helm chart no one remembers.
You wouldn't design a production system with this many point-to-point dependencies. Why accept it for your platform?
The answer: because you haven't built the layer beneath.
Here's what that actually looks like in practice. You've got Backstage scanning source repos to populate the catalog. Developers maintain entity files alongside their code. Fine. Then someone asks for Kubernetes visibility, so you wire up the K8s plugin and link components to manifests. Now developers can see pod status, deployment state, replica counts.
Then someone asks for observability. You integrate your logging stack or developers context-switch to Grafana, Datadog, whatever you're running. More wiring.
Then someone asks for self-service scaffolding. You build Backstage templates that scaffold repos with the right structure, entities, Helm charts, and CI pipelines. Now you're maintaining golden paths in templates—separately from the runtime configuration that actually enforces them.
Each request is reasonable and achievable. But they add up. Eventually you end up with a platform held together by point-to-point connections. Every new capability requires new wiring. Every upgrade risks breaking something. You spend more time maintaining integrations than building features.
The difference between a pile of integrations and a platform is architecture. Get the system design right, and new capabilities slot in cleanly. Get it wrong, and every feature request becomes a maintenance burden.
The Control Plane: Where Abstractions Become Real
The missing layer is the control plane.
It sits between Backstage and your Kubernetes clusters. It doesn't run workloads. It doesn't show dashboards. It doesn't even know what a pod is.
It knows abstractions.
Developer abstractions: Project, Component, Endpoint, Resource, Dependency.
Platform abstractions: Namespace, Environment, Pipeline, Component Type, Trait.
And it translates between them.
When a developer declares a dependency on a database, the control plane doesn't just record it. It injects the connection string. It configures the network policy so the component can reach it—and only it. It enforces that the database is provisioned, not just referenced.
When a team deploys to "prod," the control plane doesn't just label a namespace. It applies the prod-specific resource limits, the audit logging rules, the secrets rotation schedule. It compiles the intent into Kubernetes manifests—and then watches.
Because reconciliation is non-negotiable.
If someone manually scales a deployment? The control plane reverts it. If a config map drifts? It rolls it back. The abstraction is the source of truth. Not the cluster. Not the Git repo. The intent.
This is where security & compliance actually gets enforced—not documented in a wiki, not hoped for in a Helm chart, but compiled into infrastructure and reconciled continuously. Your security policies become first-class platform primitives, not afterthoughts bolted onto a portal.
This is the difference between a pile of integrations and a platform. You don't just connect tools. You compile them into a coherent system.
And yes—it's programmable. You can define component types. You can compose traits. You can let teams extend it.
But you guard the invariants. No one gets to disable the security policy. No one gets to bypass the audit trail. Extensibility without guardrails isn't flexibility. It's chaos.
The Data Plane: Keep It Simple
The data plane? It's just Kubernetes.
Pods. Deployments. Services. Ingresses.
It doesn't know what a "Component" is. It doesn't care about "environments." It just runs what the control plane tells it to run.
That's the point.
The intelligence lives in the control plane. The execution lives in the data plane. Keep it stupid. Keep it reliable.
Your control plane can evolve. Your data plane should be boring.
This separation matters for security too. When your data plane is dumb and your control plane is smart, you get clear audit boundaries. You know exactly what the control plane compiled and applied. You can trace every running workload back to a declared abstraction. That's the foundation of any serious compliance posture—whether you're dealing with SOC 2, ISO 27001, or internal security & compliance center Office 365 policies.
The data plane enforces the semantics of your abstractions: project isolation, traffic policies, security boundaries. These aren't just configurations; the platform guarantees them.
AI Agents: First-Class Citizens of the Platform
Here's where it gets interesting.
Once you have a control plane with unified abstractions and observable state, AI becomes a force multiplier—not a buzzword.
SRE agents can correlate logs, metrics, and traces across components and environments. They don't need to guess which pod belongs to which service. They know. Because the control plane told them.
FinOps agents can tell you which component is burning $800/month in idle resources. Not because it scraped a billing API. Because it knows the component's deployment history, its autoscaling policy, and its runtime utilization.
Architect agents can simulate the impact of a migration before you commit. They know your dependency graph. They know your isolation boundaries.
These aren't magic. They're just well-informed.
Good abstractions make everything easier. Even AI.
And from a security perspective, this is where the real payoff lands. SRE agents that can analyze logs, metrics, and traces to surface likely root causes—instead of developers digging through dashboards at 2 AM. FinOps agents that help teams understand and optimize resource costs across environments. Architect agents that assist with dependency analysis, capacity planning, and migration impact assessment.
These agents work because they have access to the control plane's unified view. They see abstractions, runtime state, and observability data in one place—the same connected story developers see in the portal.
The pattern holds. Good abstractions make everything easier, including AI.
OpenChoreo: The Pattern, Not the Product
You don't need OpenChoreo.
But you should study it.
It's an open-source implementation of exactly this: a Backstage-powered portal, a control plane that compiles abstractions, a data plane that runs Kubernetes, and observability wired directly to components. It was recently accepted into the CNCF as a sandbox project.
It's not the answer. It's the pattern.
You can use it whole. Or you can steal the architecture. Build your own control plane. Write your own traits. Define your own component types.
The tools change. The pattern doesn't.
OpenChoreo separates concerns across five planes:
Experience plane: Where developers, platform engineers, and SREs interact with the platform via the Backstage-powered portal, CLI, GitOps, or AI agents.
Control plane: The brain that translates high-level abstractions (components, APIs, environments, pipelines) into Kubernetes manifests. Programmable through component types and traits. Continuously reconciles runtime state back into those abstractions.
Data plane: Where workloads run. Enforces the semantics of your abstractions—project isolation, traffic policies, security boundaries.
Observability plane: Feeds metrics, logs, and traces back through the same abstractions developers already understand, requiring no translation.
Workflow plane (optional): Handles builds using Cloud Native Buildpacks and Argo Workflows by default.
These planes work together but remain separate concerns. You can reason about each independently, evolve them at different rates, and deploy them flexibly: a single cluster with namespace isolation for dev/test, fully separated multi-cluster setups for production, or hybrid topologies that colocate planes like Control and CI for cost efficiency.
OpenChoreo is also being built to treat AI agents as first-class participants. External agents can interact with the platform via MCP servers, agent skills, or the CLI to generate and edit component configurations, reason about releases and environments, and more. The built-in SRE Agent is a first example—analyzing logs, metrics, and traces from deployments and using LLMs to surface likely root causes and actionable insights.
The Real Platform Begins Behind It
Backstage gave you the front door.
It solved the discovery problem.
It didn't solve the execution problem.
The real platform begins behind it.
It's the control plane that turns your templates into enforceable policies. It's the reconciliation loop that ensures what's declared matches what's running. It's the unified view that lets a developer see their component's status, logs, dependencies, and costs—all in one place.
Without it, you've got a beautiful catalog… and a broken platform.
The pattern that works is portal, control plane, data plane:
- A portal that gives developers ready access to catalogs, documentation, and templates.
- A control plane that compiles platform abstractions, reconciles drift, and aggregates runtime state.
- A data plane that runs workloads and enforces guarantees.
Whether you build this yourself or adopt something like OpenChoreo, the architecture matters more than the tools. Get the layers right, and new capabilities slot in cleanly. Get them wrong, and every feature request becomes a project.
Backstage gives you the front door. The real platform begins behind it.