"Oh man, the original article went way over the author's head." No, the author of the Kubernetes article completely, so utterly missed the point that it's not even funny: none of those Kubernetes complications are necessary if one runs SmartOS and optionally, as a bonus, Triton. Since doing something the harder and more complicated way for the same effect is irrational, which presumably the author of the Kubernetes a…
Kubernetes for personal projects? No thanks
131–140 of 278 posts
Re: Kubernetes for personal projects? No thanks
#132Oh man, the original article went way over the author's head. The point of the original article was that even though Kubernetes is primarily useful for tackling the challenges involved with running many workloads at enterprise scale, it can also be used to run small hobbyist workloads at a price point acceptable for hobbyist projects. Does that mean that Kubernetes should now be used for all hobbyist projects? No. If…
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 Kube…
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.
Re: Kubernetes for personal projects? No thanks
#133Earlier quoted context omitted.
I do agree with you, but I don't think I really missed the point of the original article. From the original article: > However popular wisdom would suggest that Kubernetes is an overly complex piece of technology only really suitable for very large clusters of machines; that it carries a large operational burden and that therefore using it for anything less than dozens of machines is overkill. I think that's probably…
I have to disagree. It doesn't introduce burden and complexity. They're already there whether you use Kubernetes or not. The difference is that if you did build it all by hand as the author said, if it ever scales, you're going to have double the job to make it scale. It's all a question of: do I think my software will succeed? If it's a hobby project that will never get big, it's not worth the hassle. If it actually…
With hobby projects for the vast majority of people, the answer is somewhere in the territory of "you can worry about that after it succeeds."
Re: Kubernetes for personal projects? No thanks
#134I totally agree with this article. I'm giving a point of a view of a pure developer who knows nothing about DevOps things and managing servers. I kind of know what NGINX is and barely know how to configure something like systemd. I recently setup a digital ocean droplet and setup my blog there to actually understand how it works. It was great because I learned a ton and feel in control. Pretty simple setup - single d…
Re: Kubernetes for personal projects? No thanks
#135You could also have told that it is a very complex system where one still just runs Bash scripts to solve exactly the same problems as on bare metal, VMs, etc.
Re: Kubernetes for personal projects? No thanks
#136In the end, the steps you take to deploy with rsync and run your systemd service are the same (conceptually) you'd take to run on K8S, but translated to some YAML and a docker push. In one case you need to learn a new paradigm, in the other case you deal with something you already know. Not having to learn something new is an argument, but it doesn't mean your bare-Linux approach is simpler than the K8S approach. You just know it more.
Re: Kubernetes for personal projects? No thanks
#137"Oh man, the original article went way over the author's head." No, the author of the Kubernetes article completely, so utterly missed the point that it's not even funny: none of those Kubernetes complications are necessary if one runs SmartOS and optionally, as a bonus, Triton. Since doing something the harder and more complicated way for the same effect is irrational, which presumably the author of the Kubernetes a…
We detached this subthread from https://news.ycombinator.com/item?id=18138716 .
Re: Kubernetes for personal projects? No thanks
#138Re: Kubernetes for personal projects? No thanks
#139I totally agree with this article. I'm giving a point of a view of a pure developer who knows nothing about DevOps things and managing servers. I kind of know what NGINX is and barely know how to configure something like systemd. I recently setup a digital ocean droplet and setup my blog there to actually understand how it works. It was great because I learned a ton and feel in control. Pretty simple setup - single d…
Re: Kubernetes for personal projects? No thanks
#140I work as an engine mechanic full time, and im learning programming as a hobby. Kubernetes to me is like the shade-tree mechanic vs the professional. Professional mechanics use high grade tools that can cost thousands of dollars each. We have laser alignment rigs, plasma cutters, computer controlled balancing and timing hardware, and high performance benchmarking hardware that can cost as much as the car you're worki…
This is an interesting perspective because I view k8s as the "shade-tree" version of a robust cloud platform. It's cheap, quick, dirty, and probably can take off a few of your fingers if not done carefully, but the payoff is in being able to spin up lots of resources very quickly. What do the pros use, then? I hear of things like DC/OS, Openstack, I know that Google's got "Borg", which is like professional k8s.
In other words, I think there are two answers to your question of "what do the pros use?" The first answer is "Kubernetes, because that's the right tool for the job." The second answer is "My product division has an internal team the size of a growth stage startup, and it's specifically dedicated to solving server scaling problems, and that's just my product division."
Another analogy would be the question "how would an F1 team solve this problem?" One answer is "you don't need an F1 team for that", and the other is "first, hire an F1 team, then have them build all of the custom tooling the F1 car needs."