Live data from Hacker News

The Cult of Kubernetes

christine.website

241–250 of 338 posts

Re: The Cult of Kubernetes

#241
post #221

Earlier quoted context omitted.

Kubernetes is the new Java Application Server for people who didn't realize that Java Applicaiton Servers were a terrible idea. Despite a long track record of failure individuals are trying to introduce the complexity of J2EE onto kubernetes. It doesn't need to be that way. Kubernetes can be very simple and it has been up until recently. Once the Enterprise Architects got their hands on it and decided everything need…

This strikes as the exact opposite of reality. Java App Servers were specifically built for vertical scale. You just paid $80,000 to rack 30 CPUs and now you need to a way to optimally utilize all of them so we have a deployment model for sticking multiple applications in a single multi-threaded runtime. That was a pretty decent concept for 2005 and was pretty successful. The concept of packing code into archives (ja…

That's not the point of the analogy. The point is that k8 and JAS are designed for "large scale" deployment, whatever that means.

(But yes, you're correct about what "large scale" meant in the early 00's)

Re: The Cult of Kubernetes

#242

Earlier quoted context omitted.

K8s is writing config files just like Python is writing Python Syntax. If you don't understand the underlying mechanism, either with Python or K8s yaml files, you're going to have a very bad time. Somewhat ironic side note - Asking folks to write K8s config files is exposing too much complexity for some developers I work with. And I kind of get it. Properly setting up a service with changing environment variables, se…

Yeah, fully integrated “DevOps” at scale is a pipe dream. You will always have some segregation of dev and ops because the scope of knowledge is so different, especially today where “Ops” often means “expert in XXX cloud vendor’s product portfolio and how our operating model uses the features”. What we call “DevOps” is really a delicate balance of giving the dev teams enough rope to hang themselves while child-proofi…

> What we call “DevOps” is really a delicate balance of giving the dev teams enough rope to hang themselves while child-proofing the gallows.

Oh, dear, @wayoutthere, my dev team is about to hate you because I'm going to use that quote extensively over the next few weeks... (giggle...)

Re: The Cult of Kubernetes

#243
post #239

I was trying to get airflow ( https://airflow.apache.org/ ) up and running in the cloud. It has a few moving pieces that I didn't want to worry about. So I used a helm chart to install it - https://github.com/helm/charts/blob/master/stable/airflow Maybe this is overkill but it was reasonably quick to get up and running, scaling workers will be trivial, and the Airflow Kubernetes Operator opens up a lot of options for…

There aren't simpler ways to deploy cluster software. Kubernetes might be overkill for a blog, but it's not overkill for a lot of cluster software. And with Helm charts it's really easy to run it.

Re: The Cult of Kubernetes

#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 goal isn't "ease of deployment", the goal is "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 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.

Re: The Cult of Kubernetes

#245

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…

I think k3s is sort of trying to do that?

Re: The Cult of Kubernetes

#246

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.

"Deploying a blog" is already trivial with existing technology. You don't need complex infrastructure tooling for a blog.

Re: The Cult of Kubernetes

#248

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…

[deleted]

Re: The Cult of Kubernetes

#249

I mean, good on the author, but this isn’t what Kubernetes is really for. Kubernetes is basically a way to run a Java-like application server that can run things other than Java. If that sounds like an appealing prospect to you, the complexity of Kubernetes may be a good fit. Kubernetes is complex because sometimes you need to be able to do complex things. Sometimes you operate at a scale where spending 12 hours writ…

Context is always key with these kinds of reactions. Few people feel that hex editors are unnecessary, they probably don't know they exist. The reason you see this sort of thing with Kubernetes is that for whatever reason its hype over-extends its problem domain and many times people who do not need them receive the suggestion (or insistence) to use them. If someone were to tell you to use a hex editor to edit your JavaScript, you might very well reach the conclusion that hex editors are a cult, and useless. Someone might then point out that there are actual completely justified use cases for them. That's what I see happening here: whether it be indirect (tons and tons of blog posts and articles about moving to Kubernetes), or direct (an employee insisting that the company's infrastructure be moved to Kubernetes), or a mix (starting to see Kubernetes experience as a requirement for jobs that probably doesn't need it), all of a sudden you have the backlash against the perceived "Kubernetes for everything" culture (which in turn looks like a weird straw man to people who actually know what its for).

Re: The Cult of Kubernetes

#250
post #50

Earlier quoted context omitted.

It's typical for web application devs . There is a huge ecosystem of software developers outside of web services who are much less fad-happy and much more focused on using established tools to produce useful, reliable systems.

Webdev is where the money is. It's where people with a CS degree or programming experience are most likely to find a way to put food on the table. Everything else requires more expertise and, aside from the most specialized of applications, pays less money. So as it is, webdev is the center of the universe, and RDD is table stakes for being considered a professional in the field.

That's not quite true; most of my colleagues with CS degrees work for non-tech companies in factories (doing really boring stuff, but still).

Webdev does seem to pay better than most other stuff, though.

Post reply on HN