Live data from Hacker News

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

news.ycombinator.com

201–210 of 433 posts

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

#201

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…

You wrote: > This a stretch, but to me Kubernetes is like the C programming language for infra. If you look at the entire software stack today, drill down (all the turtles), and you will eventually find C (everything goes back to libc or a C/C++ kernel). I assume any commercial (or non-!) "higher-level abstraction" for infra is already (or will be soon) built on top of Kubernetes. I am OK with it. I write this post a…

Kubernetes may eventually underpin lots of higher level infrastructure, but most stuff currently isn't running atop Kubernetes. None of the higher level container-as-a-service offerings by the major cloud providers run on Kubernetes, for example. Nor does Heroku. And moreover a lot of people are still working with lower-level abstractions (VMs and auto-scaling groups) or no abstractions at all (pet servers).

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

#202
post #96

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…

It's a good point: tools made by giants for giants, such as Kubernetes, Bazel, etc, may not make sense for a smaller operation. But what would you suggest in lieu of Kubernetes? What would save work for a shop which is not yet a giant but has already overgrown the capabilities of 2-3 manually managed boxes / instances? I can think of several options. Management by Ansible / Saltstack / Chef can easily become a rabbit…

If you only limit yourself to a subset of kubernetes's features, it's actually really great for small operations.

I run a small cluster for my side projects consisting of 3 nodes. 1 node is dedicated to run database containers and control plane node (it's also a worker node but strictly for database statefulsets only), and the other 2 as worker nodes, but one of them also run an NFS server that mounted as persistent volumes so every worker nodes can have access to it.

Self-healing? Internet-scale? I have on interest for them on my small cluster. I just want my apps to not go down while I'm updating them without writing complicated blue-green deployment scripts, ability to move around pods to other nodes when one got overloaded, and ability to add or remove nodes when needed without starting again from scratch. I basically treat it like docker-compose on steroid. So far it works really well.

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

#203

Earlier quoted context omitted.

> 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 don't agree. I spun up a Kubernetes cluster in Azure, which was indeed easy. But then I had to figure out how to write the correct deployment scripts to deploy my docker containers to it, and how to configure all the security stuff. After more than a week of tryin…

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…

Don’t do that, use

    kubectl set image deployment/foo main=main:new-image
instead

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

#204

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…

As an outsider, that command looks really easy to mess up. * shell interactions with quotes * double quotes * interpolating into image namespace with no autocomplete * easy to forget an argument * do you get autocomplete against the deployment name? Comparison: C# declaration of a complex type - it's less complex than the `kubectl` command above, but IDEs offer way more support to get it right. * var x = new List >()…

1. You’ll use `kubectl set image deployment/gitlab gitlab=gitlab/gitlab-ce:14.9.2-ce.0` in production instead

2. kubernetes will abort the change if it doesn’t syntax check or the types don’t match.

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

#205

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…

As an outsider, that command looks really easy to mess up. * shell interactions with quotes * double quotes * interpolating into image namespace with no autocomplete * easy to forget an argument * do you get autocomplete against the deployment name? Comparison: C# declaration of a complex type - it's less complex than the `kubectl` command above, but IDEs offer way more support to get it right. * var x = new List >()…

You put it in a bash script that gets called from CI and move on with life. No one is typing this into their terminal every time they want to do a deploy.

> I think this is behind the feeling that the k8s system is not ready yet.

Whether you patch the deployment image from bash or from C# doesn't indict the k8s ecosystem.

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

#206
Starting from "if Kubernetes is the solution," you aren't going to be able to get to the answer, because:

1. Kubernetes isn't the solution 2. Kubernetes is expensive and extremely maintenance prone 3. Most of the companies I've seen switch to Kube I've seen switch away afterwards

Every time I've seen someone bring up Kubernetes as a solution, everyone at the table with first hand experience has immediately said no, loudly

Remember, there was a time at which someone wouldn't have been laughed out of the room for suggesting Meteor stack, and right now people are taking GraphQL seriously

Kube doesn't make sense until you have hundreds of servers, and devops makes sense at server #2

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

#207

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 mean, obviously it was designed to reduce human work. A tool that adds work wouldn't be very useful, would it?

Today, we see someone who believes that just because a tool's goal is to reduce complexity, that's what it accomplished

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

#208

Earlier quoted context omitted.

As an outsider, that command looks really easy to mess up. * shell interactions with quotes * double quotes * interpolating into image namespace with no autocomplete * easy to forget an argument * do you get autocomplete against the deployment name? Comparison: C# declaration of a complex type - it's less complex than the `kubectl` command above, but IDEs offer way more support to get it right. * var x = new List >()…

1. You’ll use `kubectl set image deployment/gitlab gitlab=gitlab/gitlab-ce:14.9.2-ce.0` in production instead 2. kubernetes will abort the change if it doesn’t syntax check or the types don’t match.

Hah, I didn't even know about `set image`.

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

#209

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…

Don’t do that, use kubectl set image deployment/foo main=main:new-image instead

TIL. Thanks for the advice.

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

#210
The easiest answer to your post is that you are looking at evidence which doesn't necessarily mean what you think it means.

If k8s is as amazing and time saving as you would imagine, you'd expect many companies to want to adopt it, so you'd expect there to be lots of job postings!

It's like saying "if computers are such time savers, why do so many companies hire people that have knowledge in computers". It's because this is a good tool that companies want to hire people with knowledge in that tool!

Post reply on HN