Live data from Hacker News

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

news.ycombinator.com

61–70 of 433 posts

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

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

What is this? An argument for actual decisions based on merit? That's not the cargo cult i signed up for!

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

#62
So, I am old enough that when I started my career I was just a "system administrator" who happened (rather luckily) to work primarily with BSD and Linux servers. At that time, I was still learning a lot. I eventually learned enough and gained enough experience to become a "systems engineer" which meant that I could architect solutions for customers of my employer. I then became a senior systems engineer. Throughout this entire time things like Chef, Puppet, ansible, and Salt were not widely used even after they were created. Red Hat pushed ansible really really hard once it came out, and config management became a thing. The combination of config management systems with containers created two new roles: DevOps, SRE. Servers became VMs, which in turn became container platforms. Config managers took the place of version control and a bash script. CI/CD became weirder. In times past, you would have something like HAproxy on FreeBSD, which would then send traffic to Apache/Nginx servers, which in turn sent traffic to PHP servers, which called data from database servers and an NFS cluster. Now, behind the scenes, you may still have HAproxy or other load balancers, but those are combined with something similar to OpenStack with an underlying storage system like Ceph. All of that may get partnered with geo-aware DNS if you're really fancy. Systems engineers and admins are still managing that stuff behind the scenes at Azure, AWS, Google, RackSpace, Cloudflare, DigitalOcean, and other places (or at least I imagine so). There are also engineers who specialize in OpenStack. Most, however, have transitioned to the new roles of DevOps or SRE, because the need for highly skilled SEs and SAs has waned.

Essentially, these roles have narrowed the focus of system administrators and systems engineers. In one, you are concerned with CI/CD, and in the other you are making and maintaining cloudy solutions for people. This is yet another layer of abstraction for people, but it also means that most people do not know how to configure underlying software anymore. Because they lack knowledge of how to configure underlying software, they also require automation frameworks. They now do not know how to automate their workflows with Bash, Ruby, Python, or anything else. They need the cloud system to do it for them, which means that they get very vendor locked.

EDIT: the plus side of a new abstraction layer is cheaper tech departments at non-tech companies (fewer and cheaper personnel); which also means that pretty much everyone wants to be a software developer now, and very few people want to be SAs, SEs, DOEs, or SREs; you have to know everybit as much but you get paid much less.

All of this may bust. Increasingly, more and more people are becoming wary of monopolistic tech giants. The cost of their datacenters on the planet is increasingly rapidly. The governments of the world are growing wary of their increasing power. For businesses, complete reliance on a third party who has vastly more power isn't as palatable as it used to be. We may see a resurgence of smaller DCs and bare metal deployment, but any such change would only happen if another massive tech bust occurs. The reality that I see is that we may see both models live in tandem indefinitely, as there are differing use-cases that make either more suitable.

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

#63
post #26

Earlier quoted context omitted.

> Have you ever tried setting up a Kubernetes cluster and deploying apps in it? Kubernetes doesn't save work This is wrong, deploying on Kubernetes is easy and quick for most apps, you have one docker image one deployment spec and that's it. https://kubernetes.io/docs/concepts/workloads/controllers/de...

And a service configuration, ingress, other networking, persistent volumes, a mechanism for updating deployed applications, management of the nodes (even with a managed service like EKS or other cloud solutions), logging, roles, security, etc. If you're a developer and all you have to worry about is one deployment spec, thank your devops team for making your life easier. Kubernetes is great for making the dev team's…

This is still easier with Kubernetes than with other tools. Installing e.g. fluentd and Kibana is again a configuration / chart which you apply to the cluster. For monitoring and visualization again you have an operator / chart that you can apply to the cluster. Yes there is a lot of complexity and learning involved but overall I was still pretty amazed at how quickly I was able to get a cluster up to speed with the available tools.

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

#65
post #47
post #37

Earlier quoted context omitted.

I'm expecting you are getting downvoted because of your assumptive and dismissive statement. The type of deployment you are suggesting is overkill to apply k8s as there is minimal to no orchestration.

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.

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

#66

Kubernetes is raw material, like concrete and lumber. It needs to be massaged/crafted/assembled into something that fits the use case. A 'devops' engineer would leverage Kube to build a system, the same way a builder/contractor would leverage raw materials, subcontractors, off the shelf components, etc to build a home or office.

By far this is the best explanation, thank you.

Just like there are a plethora of programming stacks, there exists a ton of choices in implementing a software supply chain. Kubernetes is valuable to infrastructure engineers to use it to create these systems in a maintainable and reliable way.

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

#67

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 mean, obviously it was designed to reduce human work. A tool that adds work wouldn't be very useful, would it?

The key question is what are you comparing to k8s in terms of complexity?

Does it add work compared to setting up a VM with Docker and Watchtower? - for sure..

But does it add work compared to setting up something that gives you all the same benefits of k8s without using k8s? - imho definitely not.

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

#69
post #45

My short hot take on DevOps and infrastructure as code: "Infrastructure as code has it backwards" ------- Take the development of programming as an analogy: * Punched cards * Programming in assembler * Goto * Callable procedures * Proper functions * Compiled languages (There used to be companies just selling a big C compiler) * Interpreters/JIT compilation/... * ... ------- And here's a similar progression: * Servers…

I believe a real glimpse of the future you're describing can be seen with AWS CDK's L2 or higher constructs: https://github.com/aws/aws-cdk

We already have the tools to have a cloud-scale application dynamically redefining and re-allocating its infrastructure. Give those tools some time to mature, and I'm sure the capabilities will be awesome.

A good example is the common database backend. A lot of groups have some RDS instance provisioned someway to somehow serve some frontend. Over time, the number of users grow and the RDS needs more resources provisioned for it. My last 4 jobs, it was always someone's job to check the provisioning or respond to an alert and bump the provisioning up to whatever the next rung was. In the not too distant future, this type of task will be handled by a mildly intelligent CDK application.

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

#70
post #67

Earlier quoted context omitted.

I mean, obviously it was designed to reduce human work. A tool that adds work wouldn't be very useful, would it?

The key question is what are you comparing to k8s in terms of complexity? Does it add work compared to setting up a VM with Docker and Watchtower? - for sure.. But does it add work compared to setting up something that gives you all the same benefits of k8s without using k8s? - imho definitely not.

> all the same benefits without using Kubernetes

That's the catch, if running your app on a manually setup VM is equivalent to running your app on Kubernetes then you don't understand what Kuberentes is or provide.

Post reply on HN