Live data from Hacker News

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

news.ycombinator.com

101–110 of 433 posts

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

#101

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…

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 trying to figure it out, I decided to ditch the whole solution and go for Azure Container Instances instead. It was too much for me to learn about all the concepts of Kubernetes, how you configure them, how to make it work for solutions that are not as simple as the example on the website, and how to navigate through the various different methods of deploying stuff.

Maybe I'm just too dumb. But I wasn't going to invest a month of my time into doing something that should be simple enough for an average developer to accomplish.

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

#102
post #57

Kubernetes can really help bringing more scalability. All you need is to rewrite your application (think microservices), reduce cold latency (get rid of anything VM based such as Java, or rewrite in Spring or Quarkus), use asynchronous RPC, and decouple compute and storage. Then you need an elastic platform, for instance Kubernetes, with all the glue around such as Istio, and Prometheus, and Fluentd, and Grafana, Jae…

> reduce cold latency

You don't even really need to do this, as you can tell k8s how to check if the pod is healthy, what a reasonable timeframe for becoming healthy is, etc. I've got some services which can take up to 10 seconds before they're actually ready to serve workloads and k8s can scale those services up and down without too much issue. Its definitely nice to reduce cold latency, but I wouldn't say you need to do it.

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

#103
post #65
post #47

Earlier quoted context omitted.

Also because they are just outright missing the point of the post they were replying to. Yes, deploying thing on kubernetes is pretty simple. Deploying kubernetes itself is definitely not very simple.

People are confused, you should most likely not opperate k8s yourself if you don't know or does not have a team for it, nowdays managed k8s are easy to use and operate, with 3 clicks you get a cluster up and running with sane defaults.

Not to sound trite but I feel like your continued pressing of this issue evokes the entire "Do you even lift, bro?" meme. There are PaaS that can get you up in 3 clicks, but now you are in bed with k8s which is critical for the infrastructure. I think it's quite necessary to definitely understand the inside-and-out of such a vital component for my infra.

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

#104
I've seen a general blurring of the lines between these roles. But a common theme is that if you have a dedicated "role" for something, they will prefer tools which cater to their "role". This is both a good thing for companies who benefit from further optimization within that "role", and a bad thing for companies who do not.

Kubernetes is a powerful tool for "DevOps" roles. It provides an immense array of configuration, and largely replaces many OpenStack, Xen, or VMWare type environments. You can build powerful internal workflows on it to colocate many services on one compute fleet while maintaining developer velocity - which can translate to large margin improvements for some firms. This comes at a cost that you are likely to need a Kubernetes team, and potentially a dev tooling team to make it all work. On a large compute environment, the latter costs don't effect the big picture.

Now on the other hand, more teams than you would expect are just fine on Heroku/AppEngine/AppRunner/Lambda. These teams tend to pay the cost of not having a dedicated dev tooling team through more expensive compute, and sub-optimal tooling. The benefit here though is that "more expensive compute" may mean a fraction of a salary in many environments, and "sub-optimal" tooling may mean a production grade SaaS offering that has a few rough edges you talk to the vendor about.

IME it's much cheaper/lower risk to choose the latter in the long-run. The apparent savings from option 1 eventually turn into tech debt as the shiny tools get old, and migrating to newer/cheaper compute options becomes more expensive. I once built a colo facility which resulted in a 4x reduction in monthly recurring expenses (including salaries) for the same compute footprint, 1 year into the lifetime of the facility the former cloud provider reduced prices by ~30%. Around 6 months into the facility the DataScience team suffered attrition, resulting in fewer compute needs. At the 1.5 year mark the team begged for a flip to SSDs as they were having latency issues (a point of initial contention with the team that SSDs should have been used in the first place). Over the 3 year expected lifespan of the facility there were about ~2.5 months of ramp up/migration work which impacted ROI.

Overall, in hindsight, I'd say at best we achieved a 1.5x reduction in compute expenses compared to the alternative of tooling improvements, cloud cost reductions, and compute optimization. I now seek the tool which provides the lowest friction abstraction as at the worst case I can simply migrate to something cheaper - investing in compute infra has a crazy level of depreciation.

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

#105
post #96

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…

It's a good point: tools made by giants for giants, such as Kubernetes, Bazel, etc, may not make sense for a smaller operation. But what would you suggest in lieu of Kubernetes? What would save work for a shop which is not yet a giant but has already overgrown the capabilities of 2-3 manually managed boxes / instances? I can think of several options. Management by Ansible / Saltstack / Chef can easily become a rabbit…

A cloud service that can run containers directly, e.g. Amazon ACS, Google Cloud Run, etc.

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

#106
High Availability, Scalability, Deployments, etc are NOT the goal of Kubernetes, they are features that are not exclusive to Kubernetes, nor is Kubernetes necessarily better at them then others.

The goal of Kubernetes is to improve the portability of people by introducing abstraction layers at the infrastructure layer - These abstractions can seem overly complex, but they are essential to meet the needs of all users (developers, operators, cloud providers, etc)

Before kubernetes in order for a developer to deploy an application they would need to (send email, create terraform/cloudformation, run some commands, create ticket for loadbalancer team, etc) - these steps would rarely be same between companies or even between different teams in the same company.

After kubernetes you write a Deployment spec, and knowing how to write a deployment spec is portable to the next job. Sure there are many tools that introduce opinionated workflows over the essentially verbose configuration of base Kubernetes objects, and yes your next job may not use them, but understanding the building blocks, still make it faster than if every new company / team did everything completely differently.

If you only have a single team/application with limited employee churn - then the benefits may not outweigh the increased complexity.

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

#107
post #92

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…

Anybody who watched "Kubernetes: The Documentary" knows the answer: https://youtu.be/BE77h7dmoQU Kubernetes only exists, because Google lost the Cloud Wars, and this was their Hail Mary pass.

And I might cynically offer it was "invented" to solve the problem of ex-googlers not having any useful immediately transferable skills as the Google internal tech stack had nothing in common with industry.

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

#109

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…

That's actually my point. If Kubernetes does indeed provide the best solution to provide scalability and availability, one can argue that this would result in a decreased demand for dev ops engineers, as they "would just have to use Kubernetes" and it would decrease their workload. In reality this does not seem to be the case, that's why I asked.

> If Kubernetes does indeed provide the best solution to provide scalability and availability, one can argue that this would result in a decreased demand for dev ops engineers, as they "would just have to use Kubernetes".

I'd say it would result in either:

- the same scalability and availability with fewer DevOps engineers - better scalability and availability with a similar number or more DevOps engineers

In my experience, it's almost always the second case that happens. For example, a service would be moved from a few (virtualized or physical) servers that can only be scaled manually, to a k8s cluster with either autoscaling or at least scaling by changing a configuration file.

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

#110

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…

> Kubernetes doesn't save work, it adds work. It saves, but for certain heavy scenarios like High Availability, autoscaling etc. I hope, one day we can see Kubernetes simplified, that will fit 95% of SOHO users.
Post reply on HN