Live data from Hacker News

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

news.ycombinator.com

261–270 of 433 posts

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

#261

Earlier quoted context omitted.

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.

> small- or medium-sized businesses, which might have 50,000 VMs or fewer Holy shit, is this considered small to medium enterprise now?

a single cluster supports approx 5,000 nodes, 110 pods per node~

The estimated maximum single cluster is 300,000 containers.

That's pretty medium, I've ran more than a million processes before, and nomad has 1million containers as its challenge https://www.hashicorp.com/c1m

borg can handle this easily.

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

#265

Earlier quoted context omitted.

Given that Kubernetes' docs[0] discuss using imperative commands, I think it's a fairly reasonable way to describe it. [0] https://kubernetes.io/docs/tasks/manage-kubernetes-objects/i...

Why is applying a full manifest “declarative” but applying a patch is “imperative”? That’s clearly an error.

Then open a PR.

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

#266

Earlier quoted context omitted.

You're not dumb, you're just new to it, and it's fundamentally hard stuff anyways, and if you can find a higher-level abstraction that lets you get work done faster, then all the better. However, the question is comparing Kubernetes to traditional VM-based infrastructure (especially with pet nodes) whereas you're comparing Kubernetes to a higher-level abstraction. For what it's worth, deploying in Kubernetes is prett…

Please, do not manage deployments with imperative kubectl commands, I beg of you.

The question is: what tool to use? I'm a solo developer running a very small kube cluster for my hobby project. I very much wanted to have a declarative version controlled state of my cluster. Every time I try googling solutions I get flooded with some enterprise Saas offerings that do nothing I want.

I managed my stateful sets/services for a while with terraform, but my experience was absolutely terrible and I have stopped that eventually. I now use "kubectl patch" and "kubectl apply" with handwritten yaml, but the workflow feels very clunky.

Intuitively it seems obvious to me that there must be a tool helping with that, but for some reason I was absolutely not able to find anything that would be even a little bit helpful. I am considering writing a couple python scripts that will automate it.

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

#267

Earlier quoted context omitted.

The same problems any imperative management within declarative config causes -- drift. If the tool you're using supports declarative configuration, all changes should be made exclusively via the declarative interface to prevent that drift. In this example, the new image should be added to the original manifest itself, not via a CLI update.

It depends on how you manage your changes. A lot of people don't have their infra-as-code manage the deployment's image field--rather, that's updated by the application's CD pipeline. There's no drift to worry about.

So upon deploy the CD pipeline calls kubectl with the proper deployment image and that's ok?

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

#268
post #38

Earlier quoted context omitted.

Asking as someone who has only tipped his toes into devops lately and is looking to learn K8, what is considered a reasonable "lightweight" alternative to Kubernetes these days?

HashiCorp Nomad is a good alternative.

I've started running Nomad in my homelab, and it is a great piece of software. Although I feel like the question is sort of flawed, if you want to learn Kubernetes, you are going to need to run Kubernetes - or one of the downsized versions of it.

If you want to learn about containers, distributed workloads, etc, then Nomad is a great option that is easy to learn/adopt piecemeal.

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

#269

The premise of your question is invalid. Have you ever tried setting up a Kubernetes cluster and deploying apps in it? Kubernetes doesn't save work, it adds work. In return, you get a lot of benefits, but it wasn't designed to reduce human work, nor was it designed to eliminate devops jobs. It was designed for scalability and availability more than anything. Most people using Kubernetes should be using something simp…

I don't know my dude, all 3 major clouds offer "canned" k8s services that you can set up in a ridiculously short amount of time with Terraform and your CI platform of choice. I agree with some other comments in this thread about a general fervor in the Enterprise space to "modernize" needlessly. This conversation usually lands on the company copying what everyone else is doing or what Gartner tells them to do. Cue "D…

You mean like AWS' EKS? That spares you kubeadm stuff in setup. Arguably complicated upgrade, because you're less familiar with what you have/need/rely on (their own upgrade docs point you to upstream changelogs/release notes etc.). You're still left with a kubernetes cluster to deploy stuff to, decide how stuff scales, etc., which is a lot of what is generally meant by 'DevOps' anyway?

The lower level infrastructure/platform/kubeadm type stuff isn't really 'Dev' related at all.

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

#270
The thing you're noticing is the usual thing that happens when new labor saving technology is invented:

1. What people expect: less work needs to be done to get what you had before.

2. What people don't expect: more is expected because what used to be hard is now simple

So while it may have taken a few weeks to set up a pet server before and as a stretch goal you may have made your app resilient to failures with backoff retry loops etc. Now that's a trivial feature of the infrastructure, and you get monitoring with a quick helm deploy. The problems haven't disappeared, you're just operating on a different level of problems now. Now you have to worry about cascading failures, optimizing autoscaling to save money. You are optimizing your node groups to ensure your workloads have enough slack per machine to handle bursts of activity, but not so much slack that most of your capacity is wasted idling.

Meanwhile, your developers are building applications that are more complex because the capabilities are greater. They have worker queues that are designed to run on cheap spot instances. Your CI pipelines now do automatic rollouts, whereas before you used to hold back releases for 3 months because deploying was such a pain.

Fundamentally, what happens when your tools get better is you realize how badly things were being done before and your ambition increases.

Post reply on HN