Kubernetes at a startup: what we needed, what we didn't
Every CTO feels the pull — the conference talks, the job postings, the suspicion that real companies run Kubernetes. Here's why we waited, and why we finally moved.
Every CTO of a certain era has felt the pull: the conference talks, the job postings, the quiet suspicion that real companies run Kubernetes and you're still babysitting EC2 instances like it's 2017. We finally adopted it — later than fashionable, and I think that timing was exactly right.
Why we waited
For years, our honest answer to "why not Kubernetes?" was that our problems were smaller than its solutions. A dozen services, predictable traffic patterns, and an autoscaling group did the job. Kubernetes doesn't remove operational complexity — it trades your current complexity for a different, deeper kind. You should only take that trade when your current kind is actually hurting.
What finally tipped us
- Deployment drift — a growing pile of per-service deploy scripts, each slightly different, each understood by one person.
- Density — we were paying for a lot of idle headroom across separate instance groups that pods could share.
- Hiring reality — like it or not, the operational vocabulary of the industry had become pods, services and ingresses.
We went managed from day one — EKS, nothing self-hosted. Running your own control plane as a startup is a hobby disguised as engineering.
Kubernetes is a power tool. The question is never "is it good?" — it's "is my workload worth the sharpening?"
Honest scorecard, one year in
Deploys are uniform and self-healing works — a node died on a Sunday last month and nobody's weekend noticed. But the YAML tax is real, the learning curve cost us a quarter of reduced velocity, and debugging networking issues now requires archaeology through three layers of abstraction. Worth it at our current scale; would have been madness three years earlier. Adopt boring, adopt late, adopt managed.