Kubernetes Is a Platform for Building Platforms, Not Running Apps

The Abstraction Gap

Kubernetes gives you primitives: pods, services, ingresses, config maps. But no developer wants to think in primitives. They want to think in applications: deploy this code, connect it to that database, give it a URL.

The gap between Kubernetes primitives and developer experience is where platform engineering lives. And most organizations are filling it with a patchwork of YAML templates, bash scripts, and tribal knowledge.

What a Good Platform Looks Like

The best internal platforms share three properties:

• Self-service: Developers can deploy without filing tickets
• Guardrails, not gates: Sensible defaults that can be overridden, not approval workflows
• Observable: Every deployment is traceable from commit to production

The Golden Path

Spotify coined this term for a well-paved route through the platform. Not the only route — just the easiest one. If 80% of services follow the golden path, you can invest your platform team is time in the 20% that genuinely need something custom.

Build vs Buy

You do not need to build everything from scratch. The ecosystem has matured:

• ArgoCD or Flux for GitOps deployments
• Crossplane for infrastructure provisioning
• Backstage for developer portal
• OpenTelemetry for unified observability

The platform team is job is to compose these tools into a coherent experience, not to reinvent them.

When Kubernetes Is Wrong

If you have fewer than 10 services, a small team, and no compliance requirements — use a PaaS. Railway, Render, Fly.io, or even plain EC2 instances with a deploy script. Kubernetes is overhead that only pays off at scale.