DevOps are supposed to be part of the software development team. NOT a separate department. That’s the difference between SysAdmins and DevOps. It’s in the name! Developers (on a team that run) Operations (of the teams products). DevOps.
Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
381–390 of 433 posts
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#382In my opinion, the main benefit of Kubernetes for large companies is that it allows for a cleaner separation of roles. It's easier to have a network team that's fully separate from a storage team that's fully separate from a compute team that's fully separate from an application development team because they all work around the API boundaries that Kubernetes defines. That's valuable because, on the scale of large com…
The other problem I see large enterprises dealing with when it comes to K8s is the lack of cultural change in developer and infrastructure processes.
Traditional deployment models also have ways to separate the network, from the security, from the storage, from the application stack. But it's typically done through strict change control processes.
I see many orgs choose to change to K8s because it offers improvements to operational tasks related to provisioning all of those changes, and speeds up the old change control gateways.
However, K8s is tuned to operate extremely profitably in organisations that need to make large numbers of changes to their infrastructure or software stack all of the time. And begins to break down at scale (at least from a cost point of view) compared to alternative solutions if organisations are not meeting minimum requirements for deployments a day.
IT orgs have chosen to adopt this huge piece of operations software that is itself fairly monolithic, and requires large amounts of upkeep and maintenance to keep it running smoothly and provide constant availability.
But even though they've adopted this new massive fixed cost in their IT operations. They continue to use old change control processes, often because restructuring old teams, that have traditionally made the company a lot of money, into new teams proves to be an incredibly risky exercise.
And so, the net outcome, is that their overall IT operations processes marginally improve at best. But they now have simply absorbed a new fixed cost on top of all their existing ones. What's worse, I see in some orgs, the additional cost pressure is being noticed, but they attribute (IMHO incorrectly) this cost pressure to lack of competence in the new technology (K8s), and begin a massive hiring spree to try and find specialists to better tune the technology stack. The solution, IMHO, instead should be to push hard on existing teams to simplify and downsize, and create incentives to interact with the infrastructure APIs more aggressively, letting Sysadmins/DevOps/SREs deal with faults, errors and failures the way they always have, but with the new fancy tools that let them work more efficiently.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#383Earlier quoted context omitted.
The complexity difference between bog-standard ECS+Fargate and EKS+Fargate deployments rounds down pretty small. Biggest I've seen: ALB integration, IAM integration, and maybe certificate management. Most of that stuff is out-of-box on ECS, but on EKS you need some extra containers or configuration to watch the K8s API and provision stuff for you (if you want to use it; you can also just go pure-k8s) (edit: just to b…
Agreed. I had the displeasure of doing CodeDeploy to ECS Fargate a few weeks ago for a side project and IMO it was overly complex.
Yup. You can get pretty dang far with just "the task definition is in cloudformation, so update the image in cloudformation and submit the template". For a bit more complexity, add ALB routing weights in, and the case for CodeDeploy is kind of weak. My statement that ECS needs it was probably overzealous; for most situations it doesn't, and if there's some crazy functionality it does I'm not aware of, you'd probably need something else in k8s as well (e.g. istio).
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#384Reading the comments here validates my experience. When K8s was pitched as a way to make this all run smoothly, I thought, "Great! I'll write my code, specify what gets deployed and how many times, and it'll Just Work(tm)." I built a service which had one driver node and three workers. Nothing big. It deployed Dask to parallelize some compute. The workload was typically ~30 seconds of burst compute with some pretty m…
[deleted]
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#385Earlier quoted context omitted.
kubectl apply on a directory full of yaml works fairly well for small stuff. Check it into git and it's version controlled. If you need something more flexible than that, try making your own helm chart. Helm will give you some text templating, pre and post hooks, some basic functions, and some versioning and rollback functionality. You can start simple by just pasting in your existing k8s yaml, and then just pull out…
kubectl apply on a directory doesn’t work because deleting a resource manifest won’t delete the corresponding resources.
'kubectl delete -f dir/' will delete all resources in the directory.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#386Reading the comments here validates my experience. When K8s was pitched as a way to make this all run smoothly, I thought, "Great! I'll write my code, specify what gets deployed and how many times, and it'll Just Work(tm)." I built a service which had one driver node and three workers. Nothing big. It deployed Dask to parallelize some compute. The workload was typically ~30 seconds of burst compute with some pretty m…
This can probably be chalked up to youre-doing-it-wrong (sorry) but not knowing your precise scenario, it's hard to know what went wrong. Maybe really old versions misbehaved (only started a few years ago and its been smooth sailing), but I've never seen your problem on any of our stuff and we have dozens of different services on a bunch of languages/frameworks, and none of them just give up for no reason ( though a…
> This can probably be chalked up to youre-doing-it-wrong (sorry)
I think you're absolutely right. I freely admit that I knew NOTHING about K8s before embarking on this project (and still pretty much know nothing about it now), and I was able to cobble together something that 'worked', but that doesn't mean it was right.
And as another commenter points out, "a huge asterisk there if the tool makes it very easy to 'do it wrong'". I would rather be very clearly told that I've got it wrong and be prevented from progressing further vs. making something that superficially seems right then crashes and burns in prod.
I'm sure there are folks that can wield Kubernetes with great effectiveness, and good on them, but I found it to be supremely frustrating and the wrong tool for the right job. Not that I have a better solution, so I'm admittedly just kind of complaining.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#387Earlier quoted context omitted.
In my particular market sector it seems everyone is using some form of cloud functions (SAM, Serverless Framework etc), and migrating away from K8S/containers. Regarding PaaS stuff like Heroku, the only people I know that are still using that are solo hackers.
That's interesting. In the latest Who Is Hiring discussion, there seems to be more than 10 times as many references to Kubernetes compared to serverless. https://news.ycombinator.com/item?id=31582796
[deleted]
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#388I think it was originally pushed as a way to get more people to use cloud platforms. And who better than Google to host that which they created?
Luckily its from the functionally less evil google days and open source so it is possible to use anywhere.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#389Earlier 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…
This is a very insightful comment.
Re: Ask HN: If Kubernetes is the solution, why are there so many DevOps jobs?
#390Earlier quoted context omitted.
> so there are more niches where hiring someone to babysit a few hundred VMs is profitable This makes a lot of sense. The same thing happened in the past with new technology, such as the electronic spreadsheet: "since 1980, right around the time the electronic spreadsheet came out, 400,000 bookkeeping and accounting clerk jobs have gone away. But 600,000 accounting jobs have been added." Episode 606: Spreadsheets!, M…
In 1980 - there were 90M employees in the US. Now there's 151M. Given that the US has transitioned out of manufacturing and into businesses services - I don't think much of this is explained by technology creating new jobs. I think it's just explained by the workforce growing - and the shift in the US's role in the global economy.
workforce grows as more is goods and services are produced.
So the real question is - whether the ratio of different roles changed vs total population.