Platform Engineering on Kubernetes: What It Actually Is (and How to Build the Platform)

Platform engineering is the most searched-for and most misunderstood term in infrastructure right now. Vendors sell “an Internal Developer Platform in a box,” conference talks promise it will replace DevOps, and half the industry quietly suspects it’s just Kubernetes with a nicer logo.

It isn’t. Strip away the marketing and platform engineering is a genuinely useful, specific idea — and on Kubernetes it has a concrete shape. Here’s what it actually is, what it’s made of, and the honest answer to whether you should build one.

What Platform Engineering Actually Is

Platform engineering is the discipline of building an Internal Developer Platform (IDP) as a product — with your own developers as the customers.

That framing is the whole thing. You’re not assembling infrastructure for its own sake; you’re building a product that other engineers choose to use because it makes shipping software faster and safer than doing it by hand. The platform team runs it like any product: with users, feedback, a roadmap, and a definition of success that is developer adoption, not lines of Terraform.

The mechanism is the golden path (or “paved road”): an opinionated, end-to-end route for a common task — spin up a new service, add a database, ship to production — that does the right thing by default. The easy way becomes the secure, compliant, observable way.

The Problem It Solves: Cognitive Load

Here’s why this exists. To ship one service on modern cloud-native infrastructure, a developer is implicitly asked to understand Kubernetes, Helm or Kustomize, an ingress and networking model, Terraform or another IaC tool, a CI/CD system, secrets management, and a pile of security controls. That’s before writing a line of business logic.

That’s cognitive load, and it doesn’t scale. Every new team either re-learns all of it or copies a half-understood setup from the last team. A platform absorbs that load: the developer works against a clean, self-service interface, and the platform handles the twelve tools underneath.

It’s Not DevOps 2.0 or SRE Rebranded

The most common confusion is that platform engineering replaces DevOps or renames SRE. It does neither — the three are complementary layers.

DevOps is the goal — teams owning their software end to end. SRE keeps it reliable with real engineering rigor. Platform engineering is the product that lets a large organization achieve both without every team reinventing the same infrastructure. You need all three.

The Anatomy of an IDP on Kubernetes

On Kubernetes, an Internal Developer Platform has a recognizable stack. From the infrastructure at the bottom to the developer at the top:

• Cloud infrastructure — the compute, network, and storage foundation. On Google Cloud that’s GKE plus the surrounding primitives.
• Infrastructure automation — Terraform or OpenTofu provisions that foundation (including the cluster itself), Ansible configures what lives outside pods, and an IaC orchestration layer runs both under policy. It gets its own section below, because it’s where most platforms quietly leak toil.
• Orchestration & configuration — Kubernetes as the control plane, with Crossplane to expose infrastructure as APIs, and Helm or Kustomize to template workloads.
• Continuous delivery — GitOps with Argo CD: Git is the source of truth and the cluster continuously reconciles to it.
• Self-service interface — the part developers actually touch: a portal like Backstage, service templates (the golden paths), and a platform CLI or API.

Two things cut across every layer and are not optional:

• Guardrails — policy-as-code with Kyverno or OPA Gatekeeper, RBAC, and security controls that make the paved path compliant automatically.
• Observability — metrics, logs, and traces wired in by default, so every service is observable the moment it’s born.

The layers matter less than the principle: the developer sees only the top, and everything below is the platform’s job.

The Infrastructure Automation Layer: Terraform, OpenTofu and Ansible

Most platform diagrams start at Kubernetes. Real platforms don’t. Before Argo CD can deploy anything, someone has to create the VPC, the IAM bindings, the managed databases — and the GKE cluster itself. And around the cluster there is usually a fleet of things that never run in a pod: bastion and build VMs, legacy services, appliances, OS hardening, monitoring agents.

That’s the infrastructure automation layer, and in 2026 it is almost always two tools.

Provisioning vs configuration

• Terraform or OpenTofu provisions. Declarative, stateful, plan-then-apply: you describe the resources, the tool computes the diff and creates, changes or destroys them. OpenTofu is the open-source fork under the Linux Foundation, created after HashiCorp moved Terraform to the Business Source License in 2023. It is largely drop-in compatible — the same HCL, the same providers — and has added features of its own, such as client-side state encryption. For most teams the choice comes down to licensing and governance, not syntax.
• Ansible configures. Procedural, agentless, over SSH or an API: it installs packages, hardens the OS, rolls out agents and certificates, and talks to network devices. It’s the right tool for everything that exists after a VM boots and outside Kubernetes.
• Where Crossplane fits. Crossplane is great for app-level resources requested from inside a running cluster — “give my service a bucket and a database” as a Kubernetes claim. But it can’t create the cluster it runs on. The usual split: Terraform/OpenTofu owns the foundation, Crossplane serves the developer-facing resources on top.

Where it breaks: two tools, two silos

The tools are fine. The way they’re wired together usually isn’t. A typical setup runs Terraform in one CI pipeline and Ansible from a different job, an AWX server or someone’s laptop, with the inventory handed over by a script — or a copied list of IPs. The symptoms are predictable:

• No end-to-end view. One logical change (“add a node pool and configure its agents”) lives in two systems, and nobody can see whether it fully succeeded.
• Two review and audit trails. Security reviews Terraform plans in one place and Ansible runs in another. Auditors get two stories for one change.
• Ordering by convention. Ansible runs before provisioning finished, or against yesterday’s inventory.
• Silent drift. A console hotfix diverges from state, and nobody notices until the next unrelated apply tries to revert it.
• Self-service turns back into tickets. Nobody trusts the chain to run unattended, so every “new environment” request goes through the platform team by hand.

That last one is the platform-engineering failure in miniature: a golden path on top, toil underneath.

What an IaC orchestration layer adds

The fix is not replacing Terraform or Ansible. It’s putting one orchestration layer between Git and both tools, so they run as a single governed workflow:

• Governed runs — plan on every pull request, apply only from the main branch, approvals for risky changes, locks so two applies never race.
• Policy-as-code on the plan — the same idea as Kyverno in the cluster, applied one layer down: reject a public bucket, require labels, demand a second approver when a plan destroys a database.
• Dependencies and hand-off — the provisioning stack’s outputs (IPs, endpoints, cluster names) feed the configuration stack automatically, in the right order.
• Drift detection — scheduled plans compare reality with the declared state and alert, or reconcile.
• Self-service with RBAC — the portal triggers a templated stack; the platform team owns the guardrails, not every individual run.
• One audit trail — who changed what, which policy approved it, what it applied.

A plan policy is small. Here is a generic OPA/Rego rule (Rego v1 syntax) that runs against the JSON output of terraform show -json — with conftest in CI, or in any orchestrator that evaluates OPA:

package main

deny contains msg if {
  rc := input.resource_changes[_]
  rc.type == "google_storage_bucket_iam_member"
  rc.change.after.member == "allUsers"
  msg := sprintf("%s makes a bucket public", [rc.address])
}

Your options

You can build this layer yourself or buy it. The honest comparison:

Scalr and env0 are also in this space. If your estate is small and Terraform-only, a well-built CI pipeline with conftest is a perfectly good answer; the case for a dedicated orchestrator grows with the number of stacks, teams and tools.

Sponsored · Spacelift

If you’d rather not maintain that orchestration layer yourself, Spacelift can serve as the Terraform/OpenTofu orchestration backend of the platform: governed runs, policy and drift handling in one place. Its distinctive piece is that Terraform/OpenTofu and Ansible stacks run in the same workflow. Stack dependencies form a graph, and outputs of the provisioning stack are passed to the Ansible stack, so configuration runs only after the infrastructure it targets exists — one run history and one audit trail instead of two. Plan, approval and trigger policies are written in OPA/Rego; drift detection runs on a schedule and can reconcile automatically. For self-service, a Backstage integration lets developers trigger stacks from the portal they already use.

How it fits the rest of the platform

The orchestration layer doesn’t take over anyone else’s job:

• Backstage stays the portal. A template either opens a pull request against an IaC repo or triggers a stack through the orchestrator’s API.
• Argo CD stays continuous delivery for workloads inside the cluster.
• Kubernetes and Crossplane keep handling in-cluster and app-level resources.

The rule of thumb: if it exists before the cluster or outside it, it belongs to the IaC layer; if it runs inside the cluster, it belongs to GitOps.

The Golden Path in Motion

Concretely, here’s what a golden path replaces. Without a platform, launching a service means a developer hand-writes Kubernetes manifests, wires a pipeline, requests secrets, asks networking for an ingress, and books a security review — often across days and several tickets.

With a platform, the developer runs one action — “create service” from a template in the portal — and the platform scaffolds the repo, wires CI (build, test, scan), commits the GitOps config, deploys through Argo CD to GKE, and attaches guardrails and observability automatically. No tickets, no ops bottleneck. That’s the entire value proposition: self-service, with the safe defaults already baked in.

Do You Actually Need a Platform?

This is where honesty matters, because building a platform nobody adopts is one of the most expensive mistakes in infrastructure. More platform is not automatically better.

• Small team, a handful of services? You don’t need a platform. Good templates, a solid README, and a clean CI pipeline will beat a bespoke platform you don’t have the people to maintain.
• Multiple teams re-solving the same infra problems, cognitive load slowing delivery, and enough scale to staff a platform team? Now a platform pays for itself — build the IDP, and run it as a product.

The trigger is proven, recurring pain, not the trend. If you can’t name the specific toil the platform removes and the teams who’ll adopt it on day one, you’re building tech for its own sake — exactly the failure mode in the comparison table.

Tools and the Google Cloud Mapping

The 2026 platform-engineering toolkit on Kubernetes is largely CNCF-native: Backstage for the portal, Crossplane for infrastructure-as-APIs, Argo CD for GitOps delivery, Kyverno or OPA Gatekeeper for policy, and Kubernetes underneath it all. Below the cluster, Terraform or OpenTofu plus Ansible form the infrastructure automation layer, run through an IaC orchestrator.

On Google Cloud the layers map to managed pieces: GKE for the cluster, Config Connector (or Config Controller) to manage GCP resources as Kubernetes objects, Infrastructure Manager for managed Terraform runs, Cloud Deploy for delivery pipelines, and Cloud Build or Artifact Registry for the supply chain — all of which slot cleanly under the same self-service interface.

The Honest Verdict

Platform engineering is not Kubernetes with a nicer logo, and it’s not a replacement for DevOps or SRE. It’s the discipline of building an Internal Developer Platform as a product: golden paths that make the easy way the safe way, a self-service interface over the infrastructure, a governed automation layer underneath it, and guardrails and observability baked into every layer.

Build it to remove real, recurring cognitive load — and measure it the only way that matters: whether your developers actually choose to use it. A platform nobody adopts is just more infrastructure to maintain. A platform they love is the fastest paved road to production you can give them.

Related reading: GitOps with Argo CD is the delivery layer of an IDP, and secure-by-default GKE is the guardrails layer done right.