Hacker News Reader

Comment by hobofan | Hacker News Reader

I don't get why anyone would use this. You are completely replicating the API that Kubernetes exposes, without adding any benefit, so this just adds an unnecessary layer of abstraction (that doesn't abstract anything) that increases brittleness.

You say that it "reduces time to prepare deployment"? How? What would be a before and after scenario where this actually saves time?

View on HN

I kinda get why this is useful, helm has poor library/component story, so people just dup the chart templates thing for any service, which itself became a problem… i do think helm should not be such popular without a solid component/lib design.

But how does this do anything to improve the situation on that front? It's not like this creates new meta structures that could actually fix that like e.g. a "proper" package manager.

If you would like to do re-use of any service you would just put them inside their own first-class chart in which you'd write the templates directly, rather than going through this layer of indirection, and then copy-paste the small usage portion in your parent chart.

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.

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

100% agree. The default Helm chart generated when creating a helm chart is itself too bloated in my opinion! Just take the basic k8s yaml files and parametrize what needs to be parametrized!

Without Helm or a proper language you might end up parametrizing whole blocks of indented YAML via environments variables and sed.

Deploying software on single machines was too risky, because all of the operations and configurations had to happen in one place, and if that system went down, you'd be offline, so we built specialized hardware and VM platforms to allow each piece of the service to be deployed on a specialized platform that could be run by dedicated experts.

But deploying systems to specialized VMs and load balancers and networking devices had too many disparate pieces and was impossible to unify, and developers didn't want to have to talk to all of those experts to get the configurations they needed, and anyway, resources were wasted on all these specialized pieces of hardware, so the Kubernetes API was created to encapsulate all the pieces into straightforward and consistent APIs any developer could understand that allowed services to be binpacked to achieve maximum efficiency.

But the Kubernetes API was too complicated with so many complicated interrelated concepts in one big monolith of an API, and developers did not want to have to think about how to configure all the individual pieces and dependencies, so people created Helm charts to allow that one dude on the team who understood the infrastructure to hide the complexity.

But Helm charts were too obfuscated, and no one could tell what was going on inside them, and reliability suffered and it became too risky to use black boxes to configure your deployment, so now there's a universal chart that exposes every Kubernetes API option for easy visibility.

But obviously, this new universal chart has far too many options, when all I want to do is deploy my application without having to think about every detail. So I'm looking forward to the upcoming packaging system that wraps this universal chart into something with less visible complexity.

Reply on news.ycombinator.com