Live data from Hacker News

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

news.ycombinator.com

411–420 of 433 posts

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

#411
post #38

Kubernetes is a Google scale solution. Lots of teams said “hey if Google does it then it must be good!”…but forgot that they didn’t have the scale. It caught on so much that for whatever reason it’s now the horrendous default. I’ve worked on at least 3 consulting projects that incorporated K8s and it slowed everything down and took way too much time, and we got nothing in return - because those projects only needed s…

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?

You may think you want an alternative but you don't.

The API is the main drawcard of k8s in the first place, if you are off in ECS land all you are doing is wasting a bunch of time on a dead-end.

I would instead focus on getting to understand the basics of the API by using a hosted k8s service like GKE or EKS. Stick with some basic manifests, i.e deployments, services, ingress.

Once you have some stuff running you can start learning how it really works and goes together, i.e what are pods, why are pods immutable, why is a replicaset, how does a deployment orchestrate multiple replicasets, what are endpoints, what is the difference between pod readiness/liveliness.

Don't cheat yourself this early in the game, just learn things the right way from the start and save yourself a bunch of work.

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

#412
post #271

Earlier quoted context omitted.

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…

Is anyone's goal of 'serverless' that they no longer have to deal with updating the OS? Most would say even a server-ful system (k8s, or whatever) should be considered 'cattle not pets' with immutable nodes replaced as needed anyway. No update, just replace. Just like building a new image and having new pods (or serverless whatevers) pull it.

AppEngine was the original serverless platform

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

#413
post #291

Earlier quoted context omitted.

The major point is that "mechanical sympathy" for how to operate software should be considered early in the development cycle. Fulfilling the business goals in operation should be a major design consideration that might warrant trade offs in other areas. Traditionally, this has been seen as more of an afterthought and DevOps solution to the problem is that involving the people who design and maintain software in its…

Generalization: - each role in a company tries to optimize/nudge whole organization toward this role's convenience. - specialization improves local optimum (advances certain role) at the cost of global optimum (everybody has to dance around new roles processes) - joining seceral roles into one, creates the oposite result, optimum is searched at more global level (not necessarily found) - Separation of responsibilitie…

If you look at construction, they have a system that's very similar to what DevOps espouses. Lots of trades and specializations, because building to code is complicated and important, and having the experience of doing one job well is important to be able to work around problems on the fly. But - this I think is the critical part - they must know about the other trades that are affected by their work, so as not to impede others' work or the project by accident. It's as much about compassion for the guy coming after you as it is reducing cost and speeding up construction. All of that is the aim of DevOps.

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

#414
post #358

Earlier quoted context omitted.

throwaway787544 deleted their reply to this post. My response was as follows: --- > So you're familiar with Six Sigma then? Value stream mapping? TPS? > W.E. Deming? Martin Fowler? There's more to DevOps than deployments > and CI/CD. None of those have any relationship to DevOps. > I haven't worked at Google, but I expect somebody gave you some tools > and some access to cloud infra and said "good luck". I was on Bor…

> So you're familiar with Six Sigma then? Value stream mapping? TPS? > W.E. Deming? Martin Fowler? There's more to DevOps than deployments > and CI/CD. >> None of those have any relationship to DevOps. Deming. I think you mean maybe that Deming has less of a relationship to SRE (Google style). The DevOps Cafe guy wears a Deming t-shirt and talks about Deming all the time. Maybe he has denounced Deming for some reason…

Thank you. I didn't want to get into a whole "thing" because the parent just doesn't know what they're talking about and I can't teach them everything in a comment thread, but suffice to say that Gene Kim and Jez Humble would agree with me, and that anyone who wants to know more can look up books and blogs by them.

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

#415
post #359
post #280

Earlier quoted context omitted.

> My second job in large-scale software was at Google, which used the "DevOps model" since before DevOps was named. I have no need to read a blog on it. Cool, you probably know my old colleague Hugo, he was one of the first SRE's at Google in a team of like 20 or so. (I wasn't there, could be mistaken). Anyway, what "Production" was, is different than what devops is. DevOps is different things to different people. In…

> build engineers or sysadmins or developers who learned a bit of bash and terraform. From what I have seen, it's also getting familiar with the inner workings and process of the company, as well as current and past runtime tendencies for performance and uptime.

> it's also getting familiar with the inner workings and process of the company, as well as current and past runtime tendencies for performance and uptime.

That sounds like sysadmins.

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

#416

Earlier quoted context omitted.

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

Then open a PR.

This is a strange way to concede an argument, but I’ll take it.

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

#417
post #415
post #359

Earlier quoted context omitted.

> build engineers or sysadmins or developers who learned a bit of bash and terraform. From what I have seen, it's also getting familiar with the inner workings and process of the company, as well as current and past runtime tendencies for performance and uptime.

> it's also getting familiar with the inner workings and process of the company, as well as current and past runtime tendencies for performance and uptime. That sounds like sysadmins.

let's say there's 5+ leading definitions of DevOps. I'll add this which I think is quite unpopular but true:

DevOps is how Engineering respects the work of sysadmins.

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

#418

Kubernetes is a Google scale solution. Lots of teams said “hey if Google does it then it must be good!”…but forgot that they didn’t have the scale. It caught on so much that for whatever reason it’s now the horrendous default. I’ve worked on at least 3 consulting projects that incorporated K8s and it slowed everything down and took way too much time, and we got nothing in return - because those projects only needed s…

Scaling is oversold and under criticized.

Folks, listen, if StackOverflow can run on this: https://nickcraver.com/blog/2016/02/17/stack-overflow-the-ar...

So can your doctor's appointment website, your little ML app or Notion clone.

"But...". No. You ain't gonna need it. Do some load testing, prove it to yourself. Now, multiply the load by 100x, reserve AWS resources and you're good to go.

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

#419

Earlier quoted context omitted.

And you probably didn't even get to TLS and or authenticated communication between containers, CI/CD, canary deployments, observability, monitoring etc. What we need is a Next.js for Kubernetes. Something that delivers a full stack solution on top of base Kubernetes. The core system is great, but we need to replace these DevOps with a framework or platform.

> What we need is a Next.js for Kubernetes. Something that delivers a full stack solution on top of base Kubernetes. Doesn't Rancher fit this description? It's pretty resource-heavy though.

Rancher seems to now be a "multi-cloud container management platform".

- Deploys kubernetes clusters - includes Fleet for CI/CD - install apps with helm - ISTIO (awesome)

It feels like it is positioned for orgs with large needs. I'm looking for k8s for small nimble orgs.

I will look at Rancher more, thanks for reminding me of it!

Google's Anthos is also hard to describe now as they cover similar "everything" product features.

GCP now has Autopilot which lets you pay just for the cpu you use (no cluster management at all).

Anthos includes ISTIO which may at some point work on Autopilot. This would mean not having to fiddle with GKE Ingress (which I found unpleasant) and instead use the new standard Gateway.

I believe that eventually GKE Autopilot will offer running individual pods on GPU/TPU, pay as you go.

But when is this all as easy as using Next.js ?

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

#420
post #307

Earlier quoted context omitted.

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.

> Applying a full manifest is "this is your state now". It isn’t though. It’s “please make the state look like this eventually”. You do not patch state, just spec. Controllers effect the changes.

You're both correct, but you're talking about different states. The parent's "state" is the state of the etcd database and your state is the actual state of the resources that the controllers are managing.

That said, the parent is wrong that a full manifest is declaring the (etcd) state in a way that a (strategic merge) patch isn't--both are declaring etcd state, but a strategic merge patch is doing so in finer-grained increments. A strategic merge patch can declare zero state or many full manifests, while applying full manifests can only work in increments of complete resource manifests. But both are telling Kubernetes "this is your (etcd) state now".

Post reply on HN