What job interviews taught me about Kubernetes • Hacker News Board

Re: What job interviews taught me about Kubernetes

#51

Post by emodendroket » Mon, Jun 15, 2026, 11:55 PM UTC

mikeocool wrote: post #14

I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a p…

> I think there is a real hole in the market for a simple solution that lets you deploy some containers to some instances in a declarative fashion without all of that complexity and does decent LTS versions. I imagine there’s something out there that does this, but k8s has really sucked up all the oxygen.

I mean, it's CDK and whatever equivalents other providers have, isn't it? If you fully embrace all the stuff they give you then it's straightforward to declare everything and it all works together. The downside is the vendor lock-in but unless you actively deploy to multiple environments, which most people don't, you're probably locked in in various ways without knowing about it.

Re: What job interviews taught me about Kubernetes

#52

Post by stego-tech » Mon, Jun 15, 2026, 11:57 PM UTC

OP gets it.

Right now, I’m one dinosaur managing a startup’s tech portfolio. Everything lives in my head first, then in my break-glass vault for addressing the bus problem. Our public cloud footprint is a single KMS for backups. We have no VMs, everything is a cloud service.

The literal fucking second we have real infrastructure requirements for compute, it’s right to GCE. No ifs, ands, or buts. Here’s our Git Repo, here’s the managed K8s control plane, make it work.

If (or when) we need on-prem compute, we add them to the K8s control plane as worker nodes and taint accordingly.

It’s just so much more interchangeable, even if the learning curve for non-SDEs can be a little steeper than VMs.

Re: What job interviews taught me about Kubernetes

#53

Post by clickety_clack » Tue, Jun 16, 2026, 12:22 AM UTC

Esophagus4 wrote: post #9

clickety_clack wrote: post #6

Adopting k8s when you hire your _second_ engineer (first after the CTO)? That’s a red flag that the CTO’s priorities are wrong and he’s just enjoying tinkering with his infra instead of solving the users’ problems.

I thought that was the point of the article, right? That the tech benefits may not be there, but they’re using it for the non-tech benefits

From the article:

> My personal threshold would be the moment the CTO isn't the only engineer anymore. As soon as a second person shows up, the problems K8s solves become real.

Re: What job interviews taught me about Kubernetes

#54

Post by peterldowns » Tue, Jun 16, 2026, 12:23 AM UTC

stevenaenns wrote: post #31

mikeocool wrote: post #14

I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a p…

to what extent would AWS EKS auto mode solve those problems?

"completely" in my experience

Re: What job interviews taught me about Kubernetes

#55

Post by Thaxll » Tue, Jun 16, 2026, 12:24 AM UTC

mikeocool wrote: post #14

I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a p…

k8s is not a pain, I would never return to something like Pupet / Ansible / etc ... to deploy bare ec2 instances, it's just re-inventing the wheel badly.

Just use ECS / Fargate with an ALB in front if you need a simpler use case.

Re: What job interviews taught me about Kubernetes

#56

Post by FpUser » Tue, Jun 16, 2026, 12:25 AM UTC

I call BS on that. I serve SMB clients and many are happy like a clams with monoliths deployed using those proverbial bash scripts that also does lots of other things. Understanding scripts in the age of AI is trivial for newcomers. I for example fed my own uber script to AI as an experiment and it has produced all encompassing nice documentation with examples and tests.

Re: What job interviews taught me about Kubernetes

#57

Post by makeitdouble » Tue, Jun 16, 2026, 12:27 AM UTC

himata4113 wrote: post #43

mikeocool wrote: post #14

I made this decision at a startup (albeit when the eng team was ~30 people, and we had a monolith with ~10 supporting services). I wouldn’t do it again, even for the reasons stated in the article. The uniformity is nice, we were moving from apps running directly ec2 instances provisioned with ansible. Each time we spun up a new service it was a process to get the ec2 instances provisioned just so. But k8s is such a p…

I don't know... running a startup sized kubernetes is relatively easy and pain free these days (k3s). Especially when it comes to scaling up. CNPG is an absolute monster (in a good way). cert-manager is easier than the docker alternative, calico has never failed me (except in bgp mode which has some footguns like not being able to come back from a dead state since it has a chicken and an egg problem unless you point…

I think parent would wish for something close to what heroku represented (what would it be ?)

K8s is easier at smaller scales (I understand k3s as a packaged version ?), but you still need one or two people in your team to properly understands all of the concepts and inner workings of k8s, and be able to neck deep into if/when shit hits the fan.

For a small team that's a lot of commitment for something that is usually not their bread and butter and wish they could build once and only slightly tweak every year or so.

Re: What job interviews taught me about Kubernetes

#58

Post by simoncion » Tue, Jun 16, 2026, 12:32 AM UTC

sshine wrote: post #27

SamuelAdams wrote: post #16

This seems to be less about K8’s and more about the infra as code movement. It doesn’t matter if you use K8, CDK, or terraform - you get the same benefits the OP stated across the board. It is nice to be able to have a consistent deployment pattern, with traceability, rollback support, and production approval checks. It’s nice to not have some archaic something stuck in someone’s head. It’s also nice to be able to se…

> less about K8’s and more about the infra as code movement. It doesn’t matter if you use K8, CDK, or terraform - you get the same benefits the OP stated I’d like to gently push back on that. ;-D Terraform, when committed to git, provides organisational memory. But less so uniformity, since all providers are different (and you should expect different things when applying). No tracing besides git. And tfstate is hard…

> And tfstate is hard to share between developers...

Really? For years and years we put our tfstate files into private S3 buckets at $DAYJOB and it seemed to work just fine. We didn't even take pains to ensure that everyone was on the very same version of the Terraform CLI. What problems did you guys run into?

Re: What job interviews taught me about Kubernetes

#59

Post by mianos » Tue, Jun 16, 2026, 12:33 AM UTC

This is exactly why I call it 'resume++'. You have to use it to attract talent. People want to use it to expand their employment pool. This is not justification to using it.

To use it is a whole different question, and not in any way related to job interviews. I have worked in places that are crazy for not using it and others where using it was even crazier.

Re: What job interviews taught me about Kubernetes

#60

Post by siliconc0w » Tue, Jun 16, 2026, 12:33 AM UTC

I had a similar experience after a recent job search and started working on a 'kube-lite' that just uses object storage for coordination and normal cloud primitives like auto-scale groups (skiff.pages.dev).

I ended up in a different non-SRE role but if you're interested in working on it, please let me know and I'd love to walk you through it.