General
Share and discuss tech, products, business, startups, or product recommendations
Start new thread

When does Kubernetes actually become worth it for a startup?

by
•

I’ve been thinking about where the line actually is with Kubernetes. When you’re a small team, something like Render, Railway, Fly, or a managed cloud setup can take you pretty far. You push code, it runs, and nobody has to become the accidental infrastructure person.

Then the product grows. You have more services, workers, cron jobs, environments, traffic that doesn’t behave nicely, maybe different scaling requirements. At some point someone says, “We should probably move to Kubernetes before this becomes a mess.” But moving early can create a completely different mess.

Now someone needs to understand the cluster, networking, autoscaling, deployments, observability, upgrades, Helm/YAML, and what happens when something breaks at 2 AM. On a five-person engineering team, that can very quickly become one person’s unofficial full-time job. Waiting too long doesn’t sound great either. If you eventually need Kubernetes, migrating when the existing infrastructure is already struggling is probably the worst possible time to do it.

So I’m curious what the actual trigger has been for teams here.

Was it traffic? Number of services? Cloud cost? Needing more control over deployments? Hiring a platform/DevOps person? Or did you get quite far without Kubernetes and realise you never actually needed it?

And for teams that moved, would you make the same decision at the same stage again?

26 views

Add a comment

Replies

Best

for us it wasn't traffic or service count, it was on-call. we were on a managed platform and it was fine performance-wise, but every incident meant waking up the same one or two people because they were the only ones who understood how the platform-specific config actually worked. Kubernetes isn't simpler, but the knowledge is at least standard and hireable - anyone with real k8s experience can read our manifests, whereas platform-specific tricks live in one person's head. that's the trigger I'd watch for: not "are we big enough" but "is our operational knowledge dangerously concentrated."

 Did the move actually spread on-call knowledge across more people, or did Kubernetes just replace platform-specific knowledge with a different set of things only a couple of people understood? I would be curious whether the bus-factor problem improved after the migration, not just whether the stack became more standard.

honestly, mixed. more people could technically read the manifests than could ever decode the old platform's config, but "could read it" and "would actually be the one paged at 2am and know what to do" turned out to be different things for the first few months - we still defaulted to the same two people out of habit. it only actually spread once we forced rotation onto the on-call schedule and made someone write runbooks as they learned. the migration removed the technical bottleneck; it took a deliberate process change on top to fix the bus-factor part. standardizing the stack was necessary but not sufficient on its own.

 That makes sense. The migration solved the “only two people can understand this” problem, but not the “only two people are trusted to act” problem. The rotation and runbooks were what changed the second one. Knowing that now, would you still move to Kubernetes at the same stage, or would you try the process changes first and migrate later?

 honestly, process first. if I could redo it, I'd force the on-call rotation and require runbooks on the old platform before ever touching Kubernetes. that would have told us in a month whether the real problem was people or infrastructure, instead of us assuming the migration would fix it and then still needing the process change afterward anyway. the stack change ended up being necessary but the trigger for it should have been "we tried spreading the knowledge and it didn't stick" rather than "the platform is getting complicated."