Hacker News new | ask | show | jobs
by j2kun 695 days ago
This rests on the incorrect assumption, pointed out in the post, that most applications need the kind of scale that warrants quickly scaling to more servers.
1 comments

The article tried to make k8s all about scale, when that's not the whole story.

On other socials, a screenshot of the 'Not scaling' section is getting responses of "Those idiot developers think they need k8s scaling for their 1 req/s sites, ha ha."

The author brags about being able to (skip testing, CI/CD pipelines and just) edit their perl scripts (in prod,) really quickly.

What uptime is associated with that practice? As many 9's as it takes for Brad to debug his perl program in prod? This approach doesn't even scale to 2 developers unless they're sitting in the same room.

DevOps isn't a machine where you put unnecessary complexity in one end and get req/s out the other end. It's about risk and managing deployments better.

If I really wanted to engineer for req/s, I'd look at moving off k8s and onto bare metal.

In an enterprise environment, I'd like a networking solution that allows me to run an app on my own office workstation and expose it as a service to some part of the company at an SLO that can be reasonably be guaranteed with a workstation: 99.9%. That would allow to cut so much time in "productionizing" stuff that doesn't need CI/CD pipelines or deploy to a datacenter: just me editing a Python file and restarting it.