For most of my career, infrastructure meant machines, networks, and the APIs that provisioned them. Kubernetes changed the unit of compute. Internal developer platforms are changing the unit of work.
The CNCF Platforms White Paper defined a platform as “a foundation of self-service APIs, tools, services, knowledge and support which arranges them as a compelling internal product.” That sentence is doing a lot of work. The product is not the portal. The product is the API that turns intent into a running, observable, policy-compliant system.
A portal is not a platform
Backstage, Port, Cortex — these are catalogs and UIs. They matter. Discovery is a real problem. But clicking “create service” in a catalog that opens a ticket is not a platform. The platform is what happens after the click: namespace, identity, network policy, database, secrets, CI, SLO, pager, and the GitOps path that keeps all of it from drifting.
If that path is a wiki and a Terraform repo the developer is expected to copy, you have infrastructure. You do not have a platform. You have transferred cognitive load, which is the opposite of the job. Gartner’s prediction that most large engineering organizations would have platform teams by 2026 was about this shift, not about standing up another portal.
The useful mental model is layered:
- Interface — portal, CLI, API. Humans and agents both enter here.
- Orchestration — an API that accepts intent (“a service with Postgres, a cache, and a public route”) and expands it.
- Control plane — Kubernetes plus something that extends the same spec/status model to cloud resources. Crossplane is the clearest example: managed resources, compositions, XRDs. Desired state in
spec, actual state instatus, controllers reconcile. - Policy — RBAC, admission, OPA/Kyverno. Enforced on every apply, not in a weekly review.
- Delivery — GitOps as the reconciliation of application desired state, not a snowflake pipeline per team.
- Evidence — telemetry, SLOs, ownership, change history. The platform that cannot explain what it just shipped is incomplete.
Infrastructure as code still exists at layers three and five. It is no longer the developer-facing contract. The developer-facing contract is the composition: a kind: Microservice that hides the RDS instance, the security group, the ServiceMonitor, and the NetworkPolicy.
Why this is infrastructure, not developer-experience theater
Three properties of real infrastructure:
It is the runtime contract. When checkout is down, the question is not “which Terraform state file.” It is “which platform API produced this, and what is its current status.” If ownership, SLOs, and dependencies are not on that object, the incident starts with archaeology. A composition that does not emit a ServiceMonitor, a PodMonitor, or a consistent service resource attribute has created an observability hole that no dashboard will fix.
It has a blast radius. A bad composition ships to every team that uses it. That is the same reason we care about AMI pipelines and cluster upgrades. Platform errors are infrastructure errors. Version the XRD. Canary the composition. Make rollback of the platform itself a tested path, not a hope that nobody applied the change in prod yet.
Agents can use it, or they cannot. This is the part that changed. AI-assisted development made git push cheap. Everything after that — provision, policy, deploy, observe — is still a maze of consoles. Agents do not fill gaps by asking in Slack. They need discoverable APIs, schema, and status. A Crossplane XRD is a schema. A runbook in Confluence is not.
CNCF’s argument for API-first infrastructure is correct, and it is not really about Crossplane. It is about whether intent has a deterministic place to land. Controllers should do the mechanical work. Policy should constrain it. Humans and agents should declare desired state and then watch status. Without that, every agent becomes a fragile orchestrator of kubectl, cloud CLIs, and tickets — the same toil we already failed to scale with humans.
Golden paths are type systems
A paved road that is optional will be bypassed under deadline. A composition that is the only way to get a production database is a type system: you can only construct a valid service through the API.
That sounds restrictive. It is the point. High-cardinality labels, missing traceparent, no ServiceMonitor, a LoadBalancer per service instead of an ingress contract — these are type errors. If the platform lets them through, you will spend SRE time on them forever. No conversational observability layer will save you, because the data was never correlated. Exemplars cannot join a metric that was never emitted. An incident agent cannot name an owner that was never recorded.
The spec should be small, opinionated, and complete: identity, network, data, observability, and the SLO. Incomplete abstractions leak, and the leak is always into the on-call rotation. Score and similar workload specs try to make that contract portable. I care less about the specific spec than about whether applying it produces the same evidence in every environment: the same labels, the same traces, the same pager binding.
Policy belongs at admission, not in a checklist. If Kyverno or OPA can reject a Deployment that lacks a service label or a resource limit, the agent cannot ship the broken form either. That is how you get safety without a review queue that cannot keep up with generation speed.
Measure the platform like a product
DORA keeps finding that high-quality internal platforms correlate with better delivery, with a caveat: they can also slightly increase instability through risk compensation — people ship more because the path feels safe. That is not an argument against platforms. It is an argument for coupling the platform to progressive delivery and to the SLO, not just to deploy buttons. A paved path that only makes kubectl apply faster is an instability amplifier.
The metrics I would actually watch:
- Time from empty repo to a service that has an SLO, a pager, traces, and a rollback.
- Percentage of production services created through the composition, not around it. Shadow infrastructure is the real adoption metric.
- Lead time and change-failure rate for the platform itself. The platform is a service. Treat it like one.
- Cardinality and query cost of services on the path versus off it. If the golden path produces unqueryable metrics, it is not golden.
- Error-budget burn attributable to platform changes versus product changes. If you cannot split those, you cannot tell whether the infrastructure layer is earning its keep.
Developer platforms are the new infrastructure layer because they are now the thing everything else assumes: the place identity is minted, policy is enforced, telemetry is guaranteed, and both humans and agents express intent. If you still think of the platform as a developer portal with a nice catalog, you are one layer too high. The agents will notice before the executives do.