Platform Engineering 02 - Anatomy of an Internal Developer Platform
Not Just a Portal
In the previous post, we defined platform engineering and the concept of an Internal Developer Platform. So what does an IDP actually look like on the inside?
An IDP is not a single tool. It is a stack of capabilities organized into layers, each of which is referred to as a plane. Deploying a portal alone does not make an IDP complete — it is only when all five planes are connected and working together that the platform begins to function as a cohesive whole.
The Five Planes
┌─────────────────────────────────────────┐
│ Developer Interface Plane │ ← portal, CLI, API
├─────────────────────────────────────────┤
│ Integration & Delivery Plane │ ← CI/CD, GitOps, artifacts
├─────────────────────────────────────────┤
│ Resource Management Plane │ ← compute, databases, queues
├─────────────────────────────────────────┤
│ Security & Governance Plane │ ← RBAC, policies, compliance
├─────────────────────────────────────────┤
│ Observability Plane │ ← logs, metrics, traces
└─────────────────────────────────────────┘What Each Plane Does
The Developer Interface Plane is the part that developers actually interact with. Portals like Backstage, CLIs, and APIs belong here — it is where services are created, deployment statuses are checked, and documentation is found. If this plane is poorly built, nothing else matters, because even the most capable backend infrastructure fails to reach the developers it was meant to serve.
The Integration and Delivery Plane handles the journey from code to production. CI pipelines, artifact registries, deployment orchestration, and GitOps controllers are its components. The ideal state is one where a developer pushes code and everything that follows happens automatically.
The Resource Management Plane is responsible for provisioning infrastructure. Databases, message queues, storage buckets, and compute clusters are its domain. When a developer makes a request through the interface, this plane creates the actual resources behind the scenes.
The Security and Governance Plane is where organizational rules are enforced. RBAC, network policies, secret management, and compliance verification all happen here. The purpose of this plane is to maintain security standards without sacrificing development velocity.
The Observability Plane is the final piece that completes the feedback loop. Logs, metrics, traces, dashboards, and alerts all live here. Without this plane, developers have no way of knowing the state of the services they deployed — they would be deploying into what is effectively a black box.
How the Planes Connect
Consider what happens when a developer clicks "Create new service" in the portal. That single click scaffolds a repository, wires up a CI pipeline, provisions a database and namespace, applies RBAC and network policies, and configures logging and metrics collection. All five planes move in response to one action. The developer performed a single click, but behind the scenes the entire platform collaborated to assemble a complete service environment.
Build vs Buy
No organization builds all of this from scratch. The real decision lies in determining where to draw the line between building in-house and adopting external solutions.
| Approach | Good For | Watch Out For |
|---|---|---|
| Build | Unique workflows, tight integration with existing systems | High maintenance cost, slow to start |
| Buy (SaaS) | Fast start, managed upgrades | Vendor lock-in, limited customization |
| Compose (open-source + glue) | Flexibility, community support | Integration burden, version management |
Most teams ultimately arrive at a hybrid approach. They purchase existing products for commodity areas like CI and monitoring, build in-house for areas with organization-specific requirements like developer portals and internal APIs, and compose the rest from open-source components. The important thing is to resist the temptation to complete everything at once. It is far more effective to pick the highest-friction workflow, solve it, and expand incrementally from there.
Two Traps to Avoid
The first trap is a portal with nothing behind it. The UI may look polished, but if there is no actual capability to provision infrastructure, the result is raised expectations followed by disappointment.
The second trap is powerful infrastructure with no usable interface. No matter how sophisticated the automation, if developers have no way to access it, it goes unused. The organization inevitably falls back to filing tickets and waiting for someone to handle them — the very workflow the platform was supposed to eliminate.
Both sides must be in place for the platform to hold any real value. The five-plane architecture serves as a map that shows what has been built, what needs to come next, and where the gaps remain.
In the next post, we'll look at developer experience — the metric that should guide every platform decision.