Live data from Hacker News

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

news.ycombinator.com

291–300 of 433 posts

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

#291

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

> but instead that operational load of running in-house software should be borne primarily by the developers of that software Go back and read a few DevOps books and blogs by the founders of it. We will always need separate disciplines for dev and ops, just like we need mechanical engineers and mechanics/racecar drivers. But we need them to work together and communicate better to solve problems better and not throw d…

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 operation would automatically create incentives to make operational improvements because the people making decisions are the people feeling the consequences of those decisions.

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

#292
post #213

Earlier quoted context omitted.

It could have been designed better to be easier to set up and use. Especially for ad-hoc or more casual use. If it is easy to use casually, people will use it more and they will learn how to use it faster. It is also easier to see why you would invest in learning to create more complex configurations. Pretty much every piece of software I've written in the past decade that tends to have configs in production can also…

It still comes back to right tool for the job. There's a perception in the market that k8s is the right tool for running all compute. As someone recently told me "I've been interviewing cloud people for 2 weeks and all I can find is people that want to run k8s all day." k8s is not the right tool for every job. Most companies are not at the scale where they need to worry about the problems that it's trying to solve. B…

Actually, I don't see it as being that much about scale, but more about moving complexity out of applications and about solving robustness challenges. Kubernetes offers a lot of things that are useful even at smaller scales. Which is why I'm not sure I think "but it's for scale" is a valid excuse.

Kubernetes ought at least to be the right tool for a wider range of compute task. And I think it could have been the right tool for a wider range of compute tasks.

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

#293
post #227
post #213

Earlier quoted context omitted.

It could have been designed better to be easier to set up and use. Especially for ad-hoc or more casual use. If it is easy to use casually, people will use it more and they will learn how to use it faster. It is also easier to see why you would invest in learning to create more complex configurations. Pretty much every piece of software I've written in the past decade that tends to have configs in production can also…

Most companies I've seen end up building some kind of framework around Kubernetes to make the developer experience tolerable. The threshold for getting started and getting a basic deployment up and running is way too high. Of course, there's a huge cost to building your own framework as well... And it's easy to get wrong. I started https://www.jetpack.io/ recently to try and build a better solution on top of Kubernet…

Thanks, I will have a look!

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

#294
post #292

Earlier quoted context omitted.

It still comes back to right tool for the job. There's a perception in the market that k8s is the right tool for running all compute. As someone recently told me "I've been interviewing cloud people for 2 weeks and all I can find is people that want to run k8s all day." k8s is not the right tool for every job. Most companies are not at the scale where they need to worry about the problems that it's trying to solve. B…

Actually, I don't see it as being that much about scale, but more about moving complexity out of applications and about solving robustness challenges. Kubernetes offers a lot of things that are useful even at smaller scales. Which is why I'm not sure I think "but it's for scale" is a valid excuse. Kubernetes ought at least to be the right tool for a wider range of compute task. And I think it could have been the righ…

When my system is running happily on a single VM with no real robustness issues then I don't really need to solve those robustness issues, and certainly not by bringing in a complex distributed platform to run it on. Or when my lack of robustness isn't costing me enough to make it worth it to spend the engineering cycles to adopt that platform. One way or another I have to be at a scale where it actually makes sense to make this investment vs just doing the simple/easy thing that's good enough for where I'm at.

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

#295
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.

From a purely security standpoint, "updating your OS" and "updating your image" are equivalent. What matters to the security people are that you're running the latest OpenSSL that isn't vulnerable to the newest branded vulnerability.

If you're truly "serverless" by my interpretation of it, then you wouldn't care. Your cloud provider will have updated their infrastructure, and that's all that matters.

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

#296
post #292

Earlier quoted context omitted.

Actually, I don't see it as being that much about scale, but more about moving complexity out of applications and about solving robustness challenges. Kubernetes offers a lot of things that are useful even at smaller scales. Which is why I'm not sure I think "but it's for scale" is a valid excuse. Kubernetes ought at least to be the right tool for a wider range of compute task. And I think it could have been the righ…

When my system is running happily on a single VM with no real robustness issues then I don't really need to solve those robustness issues, and certainly not by bringing in a complex distributed platform to run it on. Or when my lack of robustness isn't costing me enough to make it worth it to spend the engineering cycles to adopt that platform. One way or another I have to be at a scale where it actually makes sense…

There is a lot of ground between "runs on a single VM" to "runs on thousands of instances". In fact I would think most companies that deliver some online service fit into that category.

For instance, I don't regard one of our products that runs in three availability zones and has 3-4 instances per AZ as being "large scale". It is still a small system. And it doesn't run in multiple AZs for performance reasons but because we really need high availability.

We embedded discovery, failover and automatic cluster management in the server software itself. But it isn't really how we'd like to do it. But it is still less of a hassle than running K8S. (It also means that we can do that if you license our software to run it on-prem on pretty much most runtime environments, and that has its value, but again, this isn't functionality you want or should have to do yourself)

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

#297
post #76

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…

Exactly. I am consulting with a startup right now that chose to go everything docker/k8s. The CTO is half-shocked/half-depressed by the complexity of our architecture meetings, although he used to be a banking software architect in his previous assignments. Every question I ask ends up in a long 15 minutes monologue by the guy who architected all of it, even the most simple questions. They are soon launching a mobile…

Good god, there's a reason people worship monoliths. And here I think my company's app is over-engineered for using Sidekiq and Lambda for similar workloads.

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

#298
Because K8s is the very end of a long road, and even when that is done and setup, cloud eng work, shifts to CI/CD, data eng, significant networking maintenance, and IAM/account wrangling will keep the devops'ers employed. SRE is a golden goose job IMO

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

#299
post #76

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…

Exactly. I am consulting with a startup right now that chose to go everything docker/k8s. The CTO is half-shocked/half-depressed by the complexity of our architecture meetings, although he used to be a banking software architect in his previous assignments. Every question I ask ends up in a long 15 minutes monologue by the guy who architected all of it, even the most simple questions. They are soon launching a mobile…

this is not the fault of kubernetes but of microservice architecture gone horribly wrong

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

#300
post #276

Earlier quoted context omitted.

We’ve moved a small-scale business to Kubernetes and it made our lives much easier. Anywhere I’ve worked business always prioritizes high availability and close to zero downtime. No one sees a random delivered feature. But if a node fails at night - everybody knows it. Clients first of all. We’ve achieved it all almost out of the box with EKS. Setup with Fargate nodes was literally a one-liner of eksctl. Multiple env…

We don't have an issue with that last point, lots of EC2 EKS nodes and they don't fail randomly. Were you using resources and limits correctly? EKS nodes can fall over randomly if you don't reserve resources on the nodes for system processes, and your workloads eat up all the resources. That's probably not well documented either.

EC2 instances are inherently unreliable and that's not a knock on them, that's exactly the contract that you get using them and you're supposed to plan your architecture around the fact that at any moment an EC2 instance could die. We lose about 2-3 EC2 nodes per day (not like our app stops, like Amazon's own instance health goes red) and we couldn't care less.
Post reply on HN