Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs? • Hacker News Board

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#431

Post by bg24 » Sat, Jun 11, 2022, 7:57 PM UTC

It is a people problem. In a typical enterprise with multiple teams involved in every small thing, it is expected to see teams having their agenda and justifying their place/time. Kubernetes is an elegant platform to do just that, because it is so extensible.

As part of my job, I see thousands of small and medium businesses happily embracing kubernetes. They do not have separate devops or security or infra folks. A few engineers do it all. Yes, there are challenges with so many moving parts and rapid releases with breaking APIs. But expect that to be fixed in coming years.

Why so many DevOps jobs? Are you noticing the jobs being eliminated, or are you just seeing more DevOps jobs being created?

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#432

Post by bg24 » Sat, Jun 11, 2022, 7:59 PM UTC

jmillikin wrote: post #33

binarymax wrote: post #29

Kubernetes is a Google scale solution. Lots of teams said “hey if Google does it then it must be good!”…but forgot that they didn’t have the scale. It caught on so much that for whatever reason it’s now the horrendous default. I’ve worked on at least 3 consulting projects that incorporated K8s and it slowed everything down and took way too much time, and we got nothing in return - because those projects only needed s…

Kubernetes can't (currently) scale to Google sizes. It's designed for small- or medium-sized businesses, which might have 50,000 VMs or fewer. There are entire SaaS industries that could fit into a single Google/Facebook/Amazon datacenter.

Your scale (50,000 VMs) is way too high for small and medium sized business :-)

Is my observation correct that unicorns start to see that scale?

Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?

#433

Post by nokya » Mon, Jun 13, 2022, 3:17 PM UTC

deathanatos wrote: post #338

rahkiin wrote: post #144

Earlier quoted context omitted.

60 containers sounds like an architecture problem, not a Kubernetes problem. Kubernetes does not stop you from running 1 container in 1 pod receiving ingress and talking to a database.

Presuming too (it's hard to tell) that they mean 60 different types of containers. One of my clusters currently has ~311 containers, but that's mostly due to replication. If I count actually different containers (like, unique PodSpecs, or so), that count drops to ≈30. Even that is "high", and from an architectural standpoint, it isn't really a number I'd use. E.g., we have a simple daemon, but it also has a cronjob a…

Thank you for your comment. It's a mix of both what you described: different types of containers + what I have flagged as "utility containers" (stuff they just installed because it serves a purpose very well).

The problem I see with this approach is that it has become very difficult to evaluate system-wide topics such as accessibility (or security, or performance) as we constantly deal with a very diverse technological stack and increasingly complex attack surface.

In my opinion, this makes finding competent people who can actually evaluate or assess work almost impossible, unless you hire a Lemming who will run some third-party scanner he found on GitHub: if the scanner doesn't say something is awful or critical, then almost everyone at the table is instantly convinced the system is perfectly robust.

I try to warn my clients by asking them if they think that a judge will be satisfied if they answer "we ran the scanner the other day and the scanner said it was all good" after a customer sues them for failing to comply with a disabilities act.