Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

news.ycombinator.com

Post reply on HN
Print view View original

281–290 of 433 posts

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

#281

Post by engineerDave »

caymanjim wrote: post #14

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…

Agreed. Kube makes the scaling out easier not the bootstrapping. An important difference.

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

#282

Post by throwaway894345 »

tbrownaw wrote: post #279
throwaway894345 wrote: post #237

Earlier quoted context omitted.

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

Applying a full manifest is "this is your state now". Applying a patch is "make these changes to your existing state". That dependency on existing state is a difference, and it seems to map reasonably well to what declarative/imperative seem to usually be used to mean in this context.

1. A strategic merge patch says "this is your state now" (the only difference is the scope of the state in question, with a full manifest including a bunch of extraneous stuff)

2. "make these changes to your existing state" is still declarative

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

#283

Post by frazbin »

epivosism wrote: post #193
throwaway894345 wrote: post #122

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 >()…

correct! Here's why: Kubernetes is an operating system (a workload/IO manager) and its lineage is 16 years old. So it's like Unix around 1979, or Windows/DOS around ~1996. Imagine it's 1996 and you can pick between Windows NT (representing 16 years of MS development) or System 360 (~40 years out from IBMs first transistorized designs).

What I'm trying to say is that as an operating system, Kubernetes is now a young adult, and historically speaking, operating systems at this level of maturity have been adopted and ridden for decades, with much success. But, ya know, if you chose OS/360 in 1996 you would have a point.

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

#284

Post by peppermint_tea »

throwaway2037 wrote: post #241
epivosism wrote: post #193

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 >()…

About quoting rules: We desperately needs static analysis or IDEs (Emacs plugins, whatever) that "explain" exactly what quotes do in a particular context. When I returned to C++ recently, I was blown away by Clang-Tidy (JetBrains CLion integration). Literally: Clang-Tidy seems to "know what you really want" and give intelligent suggestions. For someone whom is a very average C++ programmer, it instantly leveled me up…

apt-get install shellcheck

or

https://www.shellcheck.net/

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

#285

Post by edude03 »

jrx wrote: post #266
sgarland wrote: post #136

Earlier quoted context omitted.

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…

Fluxcd, or argo CD if you want a nice UI

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

#288

Post by throwaway894345 »

xbar wrote: post #267
throwaway894345 wrote: post #212

Earlier quoted context omitted.

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?

Yes.

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

#289

Post by jupp0r »

jmillikin wrote: post #6

> 1) internal users: mainly developers by providing CI/CD > 2) external users: end users > > Nowadays we call people that do 1) DevOps and people that do > 2) SREs (so one could argue that the role of sys admins just > got more specialized). Both are called sysadmins. SRE is a specialized software engineering role -- you'd hire SREs if you wanted to create something like Kubernetes in-house, or do extensive customiza…

SREs don't normally write Kubernetes alternatives. They are the people who operate/write automation that interacts with/advise teams how to run their software on/ Kubernetes to solve business problems like ensuring availability.

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

#290

Post by oznog »

Clouds have multiple conflicts of interest in favor of:

1. Dethroning sysadmins introducing devops in the middle ("devs" capable of deploying in the cloud but unable to control the OS).

2. Increase CPU and other resource consumption (promoting heavy frameworks, unable to pass the Doherty threshold in 2022).

For clouds, increasing complexity and costs almost always expands the business.

Post reply on HN