> For your average developer who just wants to get something running on a port, Kubernetes introduces two barriers: containerization and Kubernetes itself. These are non-trivial things to learn, especially if you don't have an ops background, and both of them add substantial debugging overhead.

From the application-developer side, I'd dispute this. I was told to use Docker + Kubernetes for a relatively small work project recently, and I was able to go from "very little knowledge of either piece of tech" to "I can design, build, and deploy my app without assistance" in about 1 week of actual study time, spread out over the course of the project. And although I have several years' experience, I'm not some super-developer or anything.

What surprised me most is how well-documented (for the most part) everything is. The Kubernetes and Docker sites have a ton of great information, and the CLIs are rich and provide a consistent interface for all the details about your environment. (To tell the truth, that alone makes the time investment worth it.)

After this, there's no way in hell I'm going back to Heroku or similar and trying to piece together their crappy, one-quarter-documented "buildpack" system. I'd take a Kubernetes-and-Docker-first PaaS at a reasonable markup any day of the week.

Did you already have a Kubernetes cluster set up? If so, that seems plausible to me. And yes, if you're deploying to a PaaS already, Kubernetes is a fine one. But compared to "start up a process and leave it running", I think any PaaS requires a fair bit of learning to deploy anything complicated.

I think the original article made a good point, and one that seems to be overlooked by pretty much every critical response: if you don't already know standard sysadmin tooling and procedures, then the value proposition for k8s for small projects alone is probably comparable to standard sysadmin tooling. At least with k8s, you can take that knowledge with you when you want to scale.

I don't know if I'm totally convinced by that argument alone, but it would be nice if every critical response didn't seem to assume that every hobbyist is born understanding systemd, ansible, packer, qemu, etc.

This is the thing I think most people miss when they complain about the complexity of Kubernetes. If you already know how to use standard sysadmin tools it looks like a lot of additional knowledge to achieve similar outcomes. These people seem to forget that there is a lot of complexity in their sysadmin tools too.

Do you really thing you can set up and run a Kubernetes cluster, even a small one, without significant understanding of standard sysadmin tooling? I know a fair bit, and I didn't find it easy.

Absolutely. I set one up from scratch on a cluster of Raspberry Pis and I don't know shit about Packer, Ansible, SystemD, and probably a bunch of things I'm only nominally familiar with. And that was a bare metal cluster, and it was hard; however, I don't think it was hard for lack of sysadmin knowledge, it was hard because I was learning K8s, I had to learn about ingres and MetalLB, K8s requires you to modify cgroups things that I don't know shit about, various RPI/docker/architecture tedium, and other K8s particularities that aren't "standard sysadmin" things. More importantly, as the original article mentioned, cloud providers do this setup for you for an affordable price so you absolutely don't need to know the standard sysadmin things.

If you, or somebody available to you, doesn't know standard sysadmin things, you shouldn't be deploying a production system. When things inevitably do go wrong, you'll need that sysadmin knowledge to get things sorted out.

But here we're talking about personal projects. That's how a lot of people learn exactly what production systems take.

You certainly can, but you need to find that one easy way to do it, that only appears obvious in hindsight.

> These are non-trivial things to learn

Right, but again I think the point being made is that, if those are skills you do want to learn, or plan on using later down the road, it's worth knowing that you can use K8s even at a small scale.

Obviously, in most cases it could be premature optimization, but for some people (including you), it can be fun to learn.

OK, but this is a point made in the article the comment attempts to refute!