Platform Engineering on Kubernetes
A pragmatic approach to building an internal developer platform on Kubernetes without collapsing under the weight of its own abstractions.
Every team that runs Kubernetes long enough arrives at the same question: how do we let developers ship without making them learn the entire cluster API? The answer is a platform — but a platform is a product, and most of them fail.
Platforms are products
The single biggest mistake I see is building a platform for developers instead of with them. An internal platform without a roadmap, a feedback loop, and treated users is just a pile of YAML with a README.
- Treat your application teams as customers.
- Measure onboarding time and iterate on it.
- Say no to features that only one team will use.
The thin platform
I prefer a deliberately thin platform: a golden-path template, opinionated CI, and a small set of reconciling controllers. The goal is to remove boilerplate, not to hide Kubernetes behind an abstraction that breaks the moment someone needs to do something the platform authors didn't anticipate.
# A developer should never have to write this from scratch.
apiVersion: apps.example.com/v1
kind: WebService
metadata:
name: checkout-api
spec:
image: registry/checkout-api:1.4.2
replicas: 3
expose: true
A custom resource plus a controller gives you a clean contract: developers declare what, the platform reconciles how.
Don't abstract what you can't observe
The day your platform hides a deployment failure behind a generic error is the day teams start bypassing it. Observability into the platform itself — not just the apps — is non-negotiable.
Know when to stop
A good platform engineer's most valuable skill is restraint. Every abstraction is a future maintenance liability. Ship the smallest platform that unblocks the next three teams, then stop and listen.