Hacker News new | comments | show | ask | jobs | submit login

Personally, as somebody who is building a small Kubernetes cluster right now at home just for the fun of it: I think using Kubernetes for small projects is mostly a bad idea. So I appreciate the author warning people so they don't get misled by all the (justified) buzz around it.

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. And again for that developer, they provide very, very small gains.

I think the calculus changes if that developer starts to run multiple services on multiple servers, wants to keep doing that for years, and needs high uptime. I have a bunch of personal services I run in VMs with Chef, and I'm excited to convert that over to Kubernetes, as it will make future OS upgrades and other maintenance easier. But my old setup ran for something like 6 years and it was just fine. For hobbyists whose hobbies don't include playing with cluster-scale ops tooling, I think it's perfectly fine to ignore Kubernetes. It's the new hotness, but it doesn't provide much value for them yet. They can wait a few years; by then the tooling will surely have improved for low-end installs.




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




Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact

Search: