Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Cult of Kubernetes

christine.website

Post reply on HN
Print view View original

321–330 of 338 posts

Re: The Cult of Kubernetes

#321

Post by xtagon »

asdfman123 wrote: post #220
lukasLansky wrote: post #29

Kubernetes is our one shot at having the universal vendor-neutral cluster interface. The fact that it's time consuming to do simple things directly against it doesn't surprise me in the same way I'm not surprised that writing todo app directly against POSIX abstraction would be time consuming. It's a great way to learn how these interfaces work though.

Question: why hasn't someone come up with a simple interface that abstracts away the tricky bits if you just want to deploy a blog? I think MS is trying to make tools like this for the C# world, but I haven't seen them yet.

The simplest technique for a blog, IMO, is using a static site generator. Deploying static assets is simple, and you have your pick of generators/languages.

Re: The Cult of Kubernetes

#322

Post by fulafel »

root_axis wrote: post #244

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…

Infrastructure as code is a much older practice, not something that Kubernetes enables. Kubernetes can be criticised for being too complex for most things that benefit from IaC.

Re: The Cult of Kubernetes

#323

Post by fulafel »

The Heroku/App Engine model seems so obviously superior for 99% of apps that it's puzzling how much more press all these full-time-job platforms like k8s, AWS serverless, etc get.

Maybe the job thing is the answer.

Re: The Cult of Kubernetes

#324

Post by parasubvert »

root_axis wrote: post #234
parasubvert wrote: post #196

Earlier quoted context omitted.

Except Kubernetes has sucked all the oxygen up in the industry and has had a subset of adherents that trash the alternatives such as Heroku, Cloud Foundry, etc. As such, people do expect it to replace Heroku.

Anyone who suggests k8s as an alternative to Heroku is wrong. Heroku is a product that manages infrastructure so that the programmer doesn't have to, k8s is a solution for operational engineers that want a code-driven approach to managing their own infrastructure. Suggesting k8s as a replacement for Heroku is like suggesting docker as a replacement for EC2.

And yet, they both fight for the same budget. They're absolutely alternatives in that sense. Not necessarily the right tool for the job, but alas, that's not stopped the wave. And eventually, even Heroku will be based on K8s, as they see the writing on the wall.

Also note that most adherents view K8s as a replacement (more accurately new API) that replaces EC2. the fundamental unit of computing becomes the Pod, not a VM.

Re: The Cult of Kubernetes

#325

Post by auslander »

cweagans wrote: post #306
honkycat wrote: post #303

Earlier quoted context omitted.

What is the point of this question? Why are the other tools special?

My point is that if "infrastructure as code" is your sole requirement, Kubernetes doesn't seem like the first choice. Adopting Kubernetes is not a small task, but it seems to be the go-to answer for a lot of the HN crowd. Don't get me wrong: it's a great tool for some things. But IMO, for 80% of projects it's completely overkill.

+1. Infrastructure as code is exactly that, code. For AWS it is Cloudformation template code, Cloudformation service and some CI/CD on top, like jenkins or ansible. Or Terraform for unlucky ones. K8s is container orchestration, like AWS ECS, totally different beast.

Re: The Cult of Kubernetes

#326

Post by wikibob »

wayoutthere wrote: post #153
rcarmo wrote: post #150

Earlier quoted context omitted.

Well, maybe it isn't _only_ what it's for, but I have thought of doing largely the same and "bundle" a bunch of assorted projects onto a single 3-node cluster, including my blog. The only thing that's really prevented me from doing so is that I have my own micro-PaaS ( https://github.com/piku ) that makes it trivial to run a bunch of different apps/services on the same VPS, and the added complexity isn't really neces…

I mean, that’s kind of my point. It’s just not designed for that use case. Someone could build a simplified fork / derivative of Kubernetes designed for this purpose. That would be pretty rad actually, but it would cease to be Kubernetes because the complexity is the point.

k3s? https://k3s.io

Re: The Cult of Kubernetes

#327

Post by tnolet »

dkarl wrote: post #288
tnolet wrote: post #251

Earlier quoted context omitted.

...and the crux of the problem is where people who have never encountered the problem Kubernetes solves, still start using Kubernetes.

I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you "infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a colle…

I'd argue the opposite. Only a relative handful of companies, startups etc. encounter the problems IAC solves. Most do fine without it.

Or maybe they use Puppet or Chef. Most won't even need that.

Re: The Cult of Kubernetes

#329

Post by autotune »

tnolet wrote: post #327
dkarl wrote: post #288

Earlier quoted context omitted.

I think the crux of the problem is that everyone encounters the problem Kubernetes solves. As the GP states, Kubernetes gives you "infrastructure as code" so that application infrastructure can be managed in a way similar to application source code (e.g. PRs, blame, code reviews, CI, rollbacks etc). This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a colle…

I'd argue the opposite. Only a relative handful of companies, startups etc. encounter the problems IAC solves. Most do fine without it. Or maybe they use Puppet or Chef. Most won't even need that.

That’s how you get every other startup thinking Heroku is the solution and then two years later they realize they might need to invest in building out their own self-documenting, automated architecture. More than happy to upvote you as it means more work opportunities for me down the line.

Re: The Cult of Kubernetes

#330

Post by nailer »

root_axis wrote: post #244

This is another case of "I have never encountered and don't deeply understand the problems this tool was built to solve, thus the tool is totally unnecessary and the people who use it are part of a cult". This is the same kind of flawed reasoning you see in the front-end world where a bunch of people complain that they do all their work in jQuery so React must be a cult. Pasting what I wrote in another comment: The g…

> the goal is "infrastructure as code"

You can have infrastructure as code without running a second containment layer on top of the containment layer your cloud provider runs (which describes many k8s deployments).

Post reply on HN