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

231–240 of 433 posts

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

#231

Post by jljljl »

I think this Kelsey Hightower quote has summarized my experience working with Kubernetes:

> Kubernetes is a platform for building platforms. It's a better place to start; not the endgame.

https://twitter.com/kelseyhightower/status/93525292372179353...

Everywhere I've worked, having developers use and develop Kubernetes directly has been really challenging -- there's a lot of extra concepts, config files, and infrastructure you have to manage to do something basic, so Infra teams spend a lot of resources developing frameworks to reduce developer workloads.

The benefits of Kubernetes for scalability and fault tolerance are definitely worth the cost for growing companies, but it requires a lot of effort, and it's easy to get wrong.

Shameless plug: I recently cofounded https://www.jetpack.io/ to try and build a better platform on Kubernetes. If you're interested in trying it out, you can sign up on our website or email us at `demo [at] jetpack.io`.

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

#232

Post by bashinator »

Like cloud APIs, K8s replaces a ton of by-hand work that formerly made up the profession of systems administration (among others). I see my career progressions from sysadmin to devops as being a pretty natural development of "automate your (old) job away". So today with cloud and k8s, I can be as productive as ten of my old selves fifteen years ago. Back then, it would have been almost unimaginable for a company like the one I'm with to be able to thrive and grow during its first 18-24 months with only a single "IT" staff who can still maintain a great work/life balance.

TL; DR - K8s and cloud let me do the work of ten of my old selves.

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

#233

Post by rustyminnow »

throwaway2037 wrote: post #197
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…

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 involved in the stack anymore, would that still count as a C-turtle?

Haskell for example, has some "bits" written in C, but a lot is written in Haskell or assembly[1]. So if you look at the WHOLE stack you'll find C _somewhere_ (probably most places), but I don't think _everything_ boils down to C.

Granted, a LOT of stuff is written on top of C.

[1] https://stackoverflow.com/questions/23912375/what-language-i...

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

#234

Post by muskmusk »

Because everyone and their dog insists on using way over complicated micro service architectures.

Wages does not count as cost of goods sold, so who cares about a couple of extra hires? Funding is easy.

Also you severely underestimate the amount of work that goes under DevOps. Everything from build servers to test and security infrastructure is usually handled by DevOps. It's a massive surface area and it would be way worse without kubernetes.

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

#235

Post by rustyminnow »

heretogetout wrote: post #155
Avalaxy wrote: post #101

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…

I hear you about feeling dumb. I think some early decisions in the k8s ecosystem led to a lot of wasted time and effort, and this frustration. YAML: significant whitespace is always unwelcome but YAML also introduces unexpected problems, like how it deals with booleans. For example, say you have this array: foo: - x - y - z You might think this is an array of strings, but you'd be wrong. It's also difficult to read t…

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.

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

#236

Post by throwaway894345 »

sgarland wrote: post #221
throwaway894345 wrote: post #211

Earlier quoted context omitted.

This is a declarative kubectl command.

Kubernetes' docs[0] disagree. [0] https://kubernetes.io/docs/tasks/manage-kubernetes-objects/i...

They’re not being precise with their language. Applying a full manifest is no more “declarative” than applying a patch.

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

#237

Post by throwaway894345 »

sgarland wrote: post #200
jen20 wrote: post #187

Earlier quoted context omitted.

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…

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.

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

#238

Post by throwaway894345 »

sgarland wrote: post #229
throwaway894345 wrote: post #219

Earlier quoted context omitted.

It's not drift, because the infra-as-code doesn't manage the image field (the application's CD pipeline does). You don't trawl through someone's shell history', you look at the CD pipeline history. Rollbacks are easy--you just deploy the prior version via your CD tool. I think you're assuming that invoking kubectl means invoking it directly from a user's command line , but kubectl can also be called in a CD script.

If you're using ArgoCD or something then sure, but bear in mind the original statement you made was directed at someone who is new to K8s, and given a command that can be executed from their shell, they would likely assume that's what you meant.

It doesn’t have to be Argo, it can be Jenkins. Whether or not you use a CD pipeline is orthogonal to whether or not you use k8s. The best practice is to use a pipeline whether you’re targeting k8s or bare VMs or a higher level PaaS abstraction.

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

#239

Post by Sohcahtoa82 »

jstream67 wrote: post #52
dusanh wrote: 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?

If you are on AWS you should check out ECS Fargate (serverless). It is really really good. Probably one of their more polished products. If you want to stay on the Kubernetes route check out k3s. Super easy to setup and usable for small production workloads

As a security engineer, I always cringe when anything involving containers is referred to as "serverless".

I always thought that one of the advantages of going serverless was that you didn't have to worry about keeping the underlying operating system up-to-date. No needing to do a monthly "sudo apt update && apt upgrade" or whatever. But containers throw that all away when container images enter the world.

Instead of updating your operating system, you're updating your images...and it's basically the same thing.

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

#240

Post by sgarland »

throwaway894345 wrote: post #228
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…

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 imperatively modifying objects given a declarative manifest. Re: changes via stdin, I mean sure; you can also pipe a deployment manifest into `ex` or `sed` to make changes on the fly and then echo it back to `kubectl apply -` but I wouldn't recommend it.

Post reply on HN