Live data from Hacker News

The Cult of Kubernetes

christine.website

251–260 of 338 posts

Re: The Cult of Kubernetes

#251

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…

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

Re: The Cult of Kubernetes

#252
post #203

Earlier quoted context omitted.

Oh I get the author’s point, but her use case was “basically a Heroku replacement for easy deployment”. It’s just the wrong use case for Kubernetes and it is well known that deploying to Kubernetes is a bit of a nightmare.

What is the right use case for K8s? And why is "ease of deployment" not something that someone should expect from K8s? I've been sitting on the K8s sidelines for a bit as things iron out, and I've been deploying it on bare metal on a test bed over the last few days with the intention of using it as IaaS for some of my own apps. It seems to be what it's meant to do. Keep my app running on infra following the rules I s…

> What is the right use case for K8s?

It is for making things easy to deploy ONTO the K8s cluster, not for making the cluster itself easy to deploy.

The key is only to use it for cases where the deployment of the containers without K8s is more difficult than the deployment of K8s.

Re: The Cult of Kubernetes

#253

Earlier quoted context omitted.

It's not difficult if it's your full time job. The learning curve is punishing though if you're trying to learn it from 9-12 AM on Saturday.

So what? It wasn't designed to make it easier for hobbyists to deploy their weekend projects, it's meant to provide ops-engineers with an infrastructure-as-code abstraction for distributed applications.

Exactly. The point of the first meme in the blog post isn't "kubernetes is so overcomplicated why would anyone deploy their blog on it", it's "your blog is nowhere near complex enough to merit running on kubernetes".

Everyone here is blaming the truck company instead of the person that bought a flatbed to transport a 2-lb box

Re: The Cult of Kubernetes

#255
post #240

step 1) keeping a service up and running is hard. we have all these issues and it seems like we are struggling to do simple things step 2) only if there was some magic tech that could solve all these issues. and have a cool name. and we could put it on out resumes... drum roll: K8Sssssss step 3) bro. it’s working. i don’t really understand what it’s doing but look at all the containers we are running. and the config.…

You do realize that one of those cloud services you can use is k8s, right? GKE is pretty amazing. They manage the k8s control plane for you, offer worker node scalability and you can use a decent, intent based, automatable API for declarative deployments. No need to mess around with VMs or proprietary lambda/serverless stacks.

yes. i realize, but having a 3rd part manage the control plane for you != you managing the control plane. again, this comes down to delegating the work to someone that does this for a living. You could say you're using k8s at that point but you're definitely not operating a k8s cluster

Re: The Cult of Kubernetes

#256
post #104
post #99

Earlier quoted context omitted.

Part of the problem is the hiring process (plus attitudes seen on here). Your resume needs to have lots of fashionable buzzwords rather than pragmatic good enough / keep it simple choices. You must keep on learning (lots of things rather than mastering any one thing). I can write a really nice site in standard Django with some JQuery, and it will take me half the time that adding React to it will. But adding React wi…

The real trick is to make your site load so fast people swear it's magic. I use a combination of serving things from ram and https://instant.page to do this with a fairly boring plain old HTML rendering on the server app. I even have a Progressive Web App out of it too.

What do you use to serve from RAM?

Re: The Cult of Kubernetes

#257

Earlier quoted context omitted.

Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…

Or perhaps somebody will evolve Kubernetes itself into becoming simpler? I know that's a pipe dream, but really, why does it have to be? What would have to happen for people to actually work on making existing things simpler and better factored rather than reinventing the wheel? My personal theory is that it's largely because that kind of work simply isn't being valued highly enough. Reinventing the wheel is a much l…

How about Hashicorp nomad? (https://www.nomadproject.io/)

Re: The Cult of Kubernetes

#258

Earlier quoted context omitted.

Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…

Oh they have and are; but what is the business case open source such a wrapper? Wouldn’t you just host it on your own hardware and basically be another Heroku? This kind of software is complex enough it would take corporate backing (either an industry group or VC backing) so it’s probably not getting built unless there’s a business case. Even Google only released K8s because they thought it would push people towards…

> it was too easy for AWS to implement a similar service using Google’s open source tech

AWS had the most K8S deployments even before they released EKS, according to the CNCF:

https://www.cncf.io/wp-content/uploads/2018/08/cncf_survey_g...

Re: The Cult of Kubernetes

#259

Earlier quoted context omitted.

Odds are someone / some people will create some kind of simpler solution with an easy default setup within the next ~5 years. Maybe as a wrapper over Kubernetes, or maybe as something new and interoperable with it. Maybe it'll involve a bunch of "serverless" buzzwords or some newly invented buzzwords. That's how things usually go historically. A lot of value can still be extracted if you're careful to ignore the cult…

Or perhaps somebody will evolve Kubernetes itself into becoming simpler? I know that's a pipe dream, but really, why does it have to be? What would have to happen for people to actually work on making existing things simpler and better factored rather than reinventing the wheel? My personal theory is that it's largely because that kind of work simply isn't being valued highly enough. Reinventing the wheel is a much l…

The problem with making things simpler is compatibility. If you make something simpler, but don't stay compatible, it might be better to just find a new name for your simple version.

Re: The Cult of Kubernetes

#260

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…

> This helps ops people because it allows them to think about infrastructure as abstract resources rather than as a collection of individual machines with specific designations. With k8s, individual machines become a homogenized resource that do not need specialized provisioning depending on the application they will host.

This is a very true statement. I'm looking at it with a bit of a different view as well: We're currently setup very classically. Ops maintains terraform, VMs, config management. Some developers have taken over some highlevel cluster management via the configuration management. This works very well.

As long as you're pushing 3 applications around. Onboarding an application into a config management solution can easily take 2 - 4 engineering weeks on the ops side. And the work will always be on the ops-side because that's where the required expertise of the configuration management lies, which is a hefty chunk of specialized knowledge. If you're looking at a ramp-up from 3 applications to 5, 8, 20, like in our case, that's ... ugly. In our case, that's actually planned, because we've been bought due to our experience in this context. Yey.

That's a huge investment if you look at time alone, it's like 80 engineering weeks at worst. That's a year of nothing else all of a sudden. A situation like that magnifies the operations team as a bottleneck even worse.

And that's IMO where the orchestration solutions and containers come in. Ops should provide build chains, the orchestration system and the internal consulting to (responsibly) hand off 80% of that work to developers who know their applications.

Orchestration systems like K8, Nomad or Mesos make this much, much easier than classical configuration management solutions. They come with a host of other issues, especially if you have to self-host like we do, no question. Persistence is a bitch, and security the devil. Sure.

But I have an entire engineering year already available to setup the right 20% for my 20 applications, and that will easily scale to another 40 - 100 applications as well with some management and care.

That's why we as the ops-team are actually pushing container orchestrations and possibly self-hosted FaaS at my current place.

Hm, guess that got a bit longer. You hit a nerve somewhat.

Post reply on HN