Item — HN Reader

I really hate where the industry is at this point... Kubernetes is nice but the API is incredibly broad and complicated, overkill for the vast majority of applications. I liked Heroku much better for simple web development.

Helm is terrible. It's a bit like bash for kubernetes (string based templating, really??), instead of something strongly typed. This leads to text & obtuse yaml being the way to deploy complex applications to k8s, which leads to bad packaging.

Enforcing some kind of convention in Helm configs is a necessary evil. I see this project as a "contract" on helm configs, much like bitnami is doing (their Helm charts all look alike). It's about as good as bash scripts written in bash that all had a similar case/esac/getopts function to parse arguments.

1 comments

Helm is terrible, except for everything else.

> Kubernetes is nice but the API is incredibly broad and complicated, overkill for the vast majority of applications. I liked Heroku much better for simple web development.

These are not comparable. You're welcome to use any provider's managed offerings -- Google Cloud Run, AWS Fargate, fly.io, etc.

I'm really sick of people hating on Kubernetes because it's complicated, sure, but the thing it abstracts is far more complicated. When it comes to orchestrating resources across systems nothing comes close.

> Helm is terrible, except for everything else.

100% .

> I'm really sick of people hating on Kubernetes because it's complicated, sure, but the thing it abstracts is far more complicated. When it comes to orchestrating resources across systems nothing comes close.

Agreed, and it's elegant at the core. It's just A LOT to take in for most developers. It solves a much bigger problem than Heroku did, but most web devs would just need a simple overlay over a managed k8s offering that doesn't expose all the k8s interfaces.

I kind of get this, but you see this same level of complaints about build tooling as well. Gradle, for instance, is well known for being difficult to understand and work with. Part of the problem is that generic build tooling is necessarily complex, but part of the problem is also the UX around Gradle is just terrible (lots of ways to make your code difficult to understand, for instance) and could stand for some significant improvement and better abstractions. Both of these things can be simultaneously true