Live data from Hacker News

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

news.ycombinator.com

111–120 of 433 posts

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

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

That sounds a lot like the original Google App Engine. They'd provide a lot of power, but you had to restrict yourself to its design choices to use it. Then it could 100% manage your deployment.

I don't see people wanting to give up control to get a platform like that any time soon.

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

#112

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

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.

You want the person who designs the car to know what a car is, and to be able to diagnose basic issues like "the fuel gauge says 'empty' and engine won't start". And there's no analogy to an Indy car driver in software, every distributed system is self-driving.

The most popular alternative to "DevOps" is a team of developers who do not run the software, and may not even have the skills or capabilities needed to boot up the server process. They do their development in an IDE, run unit tests to verify functionality, and do not have permission to log in to the production environment.

Meanwhile the "ops" side consists of people who may know basic shell scripting, or some Python if they're a go-getter, but are unable to read stack traces or diagnose performance excursions.

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

#114
post #9

A few thoughts... 1) Kubernetes is an infra platform for the ops in DevOps. If developers need to spend a lot of time doing Kubernetes it takes away from their ability/time to do their dev. So, there are a lot of platform teams who pull together tools to simplify the experience for devs or DevOps specialists who handle operating the workloads. 2) Kuberentes is, as Kelsey Hightower puts it, a platform to build platfor…

> 3) Kubernetes is hard. The API is huge and it's complex. > The docs are limited. Eh, I wouldn't go that far. Kubernetes has a lot of API surface for features that are useless (config maps), attractive nuisances (CRDs, packet routing), or outright dangerous (secrets). If you strip it down to its core mission of distributed process scheduling, the API is reasonable and the docs are extensive. The biggest challenge wi…

I'm not sure how config maps are "useless". It seems to be a pretty important element of the platform in general.

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

#115
post #2

Because many many companies herd pets using kubernets. The number of single-server setups with kubernetes thrown in for added complexity and buzzwords I’ve found is way too dang high.

Single Server kubernetes on a managed platform like Digital Ocean is a lot like having a managed server but you are more flexible with separating your services. I no longer just run imagemagick by shelling out of my ruby process in rails I use an external service that does just that. Which I can scale very easily. I can add an image for chrome with chrome driver instead of trying to build that in my dockerfile

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

#116

Earlier quoted context omitted.

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

Similarly, we switched from self-managed k8s on EC2 to Fargate. Took about 2 months part-time with some consultants to get thing squared away.

Once we deployed, we ran into all sorts of SRE-issues. Turns out AWS sets all those “sane limits” that our own folks never did. Still hunting ghosts from the rollout 6 months ago.

Makes for good resume fodder, and makes me laugh at the prestigious titles and positions the folks who built this system went on to receive at big name firms.

Guess it is someone else’s management problem now. :shrug:

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

#117
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?

Definitely check out all the aws offerings under ECS

There's now even onprem ECS variants which means not having to pay aws very much and still get the benefit of them running and maintaining the control plane

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

#118
Few reasons :

- Kubernetes is very complex to setup

- It is not needed for many use cases

- It is (hopefully) not the defacto and standard for devops

- Load Balancing is already a solved problem way before Kubernetes. For many use cases, you don't need the complexity. Even things like Self Healing are kinda solved by AWS Auto Scaling for example.

- NOt every use case needs Kubernetes and its additional overhead/complexity

- Most importantly, devops is not "one size fits all" magic wand that Kubernetes or any other tool can solve. Various nuances to consider and hence you need DevOps as a role.

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

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

You can do this type of analysis for most software, since building on existing solutions allows us to write powerful tools with less code. Listing out the existing solutions that allow developers to write less code doesn't necessarily mean the new solution is bad.

Every time I read a post like this about Kubernetes, I scratch my head. It takes me maybe half a day to deploy a CI/CD pipeline pushing into a new Kubernetes cluster with persistent DB's, configuration management, auto-renewing SSL certs and autoscaling API/web servers per environment. I'm by no means an expert, but I've been running 10+ sites this way for various clients over the past five years, with almost zero headache and downtime.

When I compare this solution to the mishmash of previous technologies I used prior to Kubernetes, it clearly comes out on top (and I use/d Terraform religiously). Setting up automatic server provisioning, rolling updates, rollbacks, auto-scaling, continuous deployment, SSL, load balancing, configuration management, etc... requires an incredible amount of work. Kubernetes either provides most of these out of the box, or makes them trivial to implement.

The only way I understand this argument is if you're building an extremely simple application. The nice thing about simple applications is that you can build them using any technology you want, because they're simple. Despite this, I often Kubernetes anyways, because it's _so simple_ to take a Helm chart and update the image name.

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

#120

DevOps isn't a job. DevOps is a system to work with people directly and find out what they need and give them things that enable them to get their job done faster, while also getting enough information to make sure the product stays online and reliable. What people call "a DevOps role" today is just sysadmin or sysop or syseng or SRE. Back in the day we cobbled together solutions out of different parts because it gav…

>DevOps isn't a job.

And Agile isn't Scrum, but once again a buzzword became the catalyst for a change that the buzzword isn't even "supposed to" represent.

It's our fault for never learning our lesson about buzzwords.

Post reply on HN