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

251–260 of 433 posts

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

#251

Post by Art9681 »

To put it simply, anything that increases efficiency most likely increases the desire to scale. There is a ton of demand because everyone wants to scale to billions of users. Kubernetes is one way to get there until the next thing comes along.

Also, there is more demand than supply. Everyone wants to do Kubernetes and DevOps pipelines but the amount of folks experienced in those fields is small compared with demand.

It requires knowledge in many domains because it abstracts the entire data center. So you can’t just take a mid level sysadmin or developer and expect them to jump right in.

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

#252

Post by throwaway894345 »

jen20 wrote: post #187
alias_neo wrote: post #173

Earlier quoted context omitted.

The declarative approach is a more sustainable way to run Kubernetes. If you define some desired state in manifests and apply them to a cluster, they can be applied again to new clusters or the same one and Kubernetes will attempt to maintain the desired state. This state can be version controlled, written in stone, whatever you prefer and it can always be attained. When administrators start issuing imperative comman…

I find this to be a common misconception, stemming from a misunderstanding of what "declarative" means (especially common when people are discussing tools like Terraform). Firstly as you point out, there is a record of the state Kubernetes is being asked to maintain: it's in the API server as the spec of each resource. Secondly, using `kubectl` "patch" in the manner described is not making changes to the cluster stat…

> Fundamentally, the argument seems to come down to "you don't have a record of what you once asked the API server to do", and that's fair enough - you don't. But that has nothing to do with imperative or declarative models.

You do actually have this record. First of all, because k8s has an audit log, and secondly because deployments maintain a revision history (so you can always rollback--kubectl even supports this via `kubectl rollback undo`).

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

#253

Post by eeZah7Ux »

MrBuddyCasino wrote: post #4

> "If this old way of doing things is so error-prone, and it's easier to use declarative solutions like Kubernetes, why does the solution seem to need sooo much work that the role of DevOps seems to dominate IT related job boards? Shouldn't Kubernetes reduce the workload and need less men power?" Because we're living in the stone age of DevOps. Feedback cycles take ages, languages are not typed and error prone, pipel…

dagger.io: "Developed in the open by the creators of Docker"

Hard pass.

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

#254

Post by aidenn0 »

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…

What is this "something simpler"?

I have to manage like half a dozen docker images. K8s seems like a massive overkill, but managing by hand is rather error-prone.

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

#255

Post by rustyminnow »

krapp wrote: post #246
rustyminnow wrote: post #235

Earlier quoted context omitted.

Technically YAML is a superset of JSON - all valid JSON is valid YAML. So you could write all your configs in JSON and they'd work just fine.

This discussion from a couple of weeks ago suggests it isn't that simple: not all valid JSON is always valid YAML if your definition of superset requires that JSON would be parsed the same with a YAML parser as with a JSON parser. If you're going to use JSON for config, it's better to use an actual JSON parser. https://john-millikin.com/json-is-not-a-yaml-subset https://news.ycombinator.com/item?id=31406473

Thanks! That's really interesting.

You could mitigate some of the issues and get JSONs "strictness as a feature" by passing the document through e.g. `jq . $file` as a CI step, but I don't think that'd resolve the 1e2 issue. TBH I didn't know you could write numbers in JSON like that, so I imagine it'd be an issue that doesn't come up often. But it's disappointing that it wouldn't just work.

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

#256

Post by throwaway894345 »

sgarland wrote: post #240
throwaway894345 wrote: post #228

Earlier quoted context omitted.

People are incorrectly assuming that using kubectl implies invoking it from an administrator's laptop. Of course, you can and should invoke kubectl from your CD pipeline. The CD pipeline maintains its own record of runs, and Kubernetes deployments have a revision history. Moreover, people in this thread also don't know what "declarative" means. The patch is declarative, and "declarative" doesn't provide the claimed b…

A patch is declarative in that it's an idempotent command which requires you to fully define the patch. It's still something that is being manually defined rather than contained in a file to be applied. Of course, if that file is just being locally held and modified on someone's laptop instead of committed to version control, it's a moot point. I will grant you that `kubectl delete -f` breaks my argument, since it's…

Yeah, my point is that whether you're changing a manifest and doing an apply versus a patch isn't relevant, the relevant bit is whether or not you have a version history and in both cases you do via your CD pipeline and via k8s deployment revision history. You can also commit to git, but I don't think there's much value in committing every image version change to git.

Also, working in raw manifests isn't a panacea; if you delete a resource's manifest, Kubernetes won't delete its corresponding resource (maybe this is what you were referring to with your bit about `kubectl delete -f`). You need something that diffs the manifests against the current state of the world and applies the requisite patches (something like Terraform) but this isn't related to how you change image versions.

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

#257

Post by Art9681 »

Avalaxy wrote: post #101
planetafro wrote: post #82

Earlier quoted context omitted.

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…

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

There are tools that let you convert a running docker/podman container to a kubernetes deployment manifest which you can then deploy with one line command to your cluster. Kubernetes is the new data center and I don’t expect anyone with <10 years of enterprise experience to master it. Certainly one can use it and deploy things to it if you work at a place where there are mature pipelines, but deploying your own cluster and all associated services plus networking plus security is the domain of experienced/senior engineers. How quickly one achieves that “status” is up to the individual. It took me 15 years before I could build an enterprise network from scratch. It took me two years to understand how to do the same with K8s.

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

#259

Post by throwaway2037 »

rustyminnow wrote: post #233
throwaway2037 wrote: post #197

Earlier quoted context omitted.

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…

> 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 might be nitpicking, but I'm not sure that's necessarily true. You could in theory write a compiler for a new language in C (or even assembly!), and once you have a working language, re-write the compiler in that new language. Now that there is no C code in…

Great point and not a nitpick at all! I hope the next generation of languages is written on top Python, Ruby, C++ (ultra modern), Java, or DotNet/C#. I wish more languages would figure out if they can host in JVM/CLR, which would provide some crazy interactions!

After seeing so much great work done with JavaScript in the form of "transpilers", I think a lot can be done in that area. I feel Zig is a crazy good idea: A brand new language that produces binaries that are 100% compatible with C linkers. If all goes well, in a few years, why would anyone use C over Zig? It seems like the future.

Lots of people think C++ is bat sh-t crazy complex (me too, but I still like the mental gymnastics!). What if there were different C++ dialects supported by transpilers that intentionally restricted features? I think kernel and embedded programmers would the primary audience.

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

#260

Post by throwaway894345 »

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…

The quotes here have nothing to do with k8s, it's just how you encode JSON in shell.
Post reply on HN