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

This is a declarative kubectl command.

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 work with little or no config. Including clustered software that just exploits things that are widely available like Zeroconf to get a decent low effort cluster up and running. No, you probably won't be able to (or want to) use those features in production, but that's beside the point. The point is to lower the thresholds. And then keep aiming at lowering them wherever you can because asking other people to care about your software is seriously uncool. Other people will never care as much as you do.

It is normal for programmers to become defensive about software. Be it their own or software they really like. But it is far more productive to assume that when users think something is awkward, perhaps it is because it is awkward. And perhaps it could have been done better.

Nobody actually gives a crap what someone thinks Kubernetes was built for -- and what kind of rubbish experience they think is deeply justified by the goals.

It is either needlessly awkward to use or it isn't. And guess what: most people think it is awkward. And I seriously doubt it needs to be this awkward.

The reason why they provide it, is because everyone expects it. The reason everyone expects it, is because it was "cool" and an ecosystem grew around it. I use AWS ECS and it's really really good and easy to understand.

The cloud providers haven't closed the DevOps loop yet is why. I mostly have experience with Google's stuff, so I will take Cloud Build as an example. It provides the framework of CI/CD, but there isn't automatic build+deploy for every software and framework ecosystem.

What I'm trying to do at work is simplify the build ecosystem for all languages to the familiar `configure ; make ; make test ; make install` sequence that works well for OSS. If every ecosystem fit into that metaphor then the loop could be closed pretty effectively by any cloud provider by letting users add repositories to the CI/CD framework and it would do e.g. a standard docker build (configure, make, test), docker push (make install 1/2), and kubectl rollout to k8s at the end (remainder of make install).

Blockers:

Liveness and readiness checks are not automatic; they need to be part of each language*framework so that developers don't have to implement them by hand. At Google they just sort of came with the default HTTPServer class in your language of choice, with callbacks or promises you knew you had to invoke/complete when the instance was ready to serve. It helped that only 4 languages were officially supported.

Integration tests have no standard format and many deployments are combinations of artifacts built from multiple repositories, and configuration is not standardized (configmaps or ENVs? Both? External source of feature flags?) so all integration tests are manual work.

Metrics and SLOs are manual work; only humans can decide what actual properties of the system are meaningful to measure for the overall health of the system beyond simply readiness/liveness checks. Without key metrics automatic rollouts are fragile. This also means autoscaling isn't truly automatic; you need quality load metrics to scale properly. Not all services are CPU or RAM limited, and sometimes the limit varies depending on traffic.

All that said, cloud functions (Google, AWS, or other versions) are beyond DevOps. If you don't need high-QPS services then use cloud functions. They bypass 90% of the headaches of having code running on https endpoints. Most people don't have high-QPS (10K requests per second per shard) services, and could probably get away with cloud functions (1000 RPS on GCP). Everyone else pays the DevOps or hopefully the SRE tax for now. But we're still trying to automate ourselves out of a job; we don't want to be doing DevOps day-to-day either.

It's not drift, because the infra-as-code doesn't manage the image field (the application's CD pipeline does). You don't trawl through someone's shell history', you look at the CD pipeline history. Rollbacks are easy--you just deploy the prior version via your CD tool.

I think you're assuming that invoking kubectl means invoking it directly from a user's command line, but kubectl can also be called in a CD script.