[koalalorenzo]

Probably they have a different experience! I love using helm but I feel I got used to go templates and sub charts done right. I use it at work a lot and at home on my homelab with no issues at all: I guess is the usual tab vs spaces.

The alternatives of helm are not that interesting to me: I still have nightmare when I had to use jsonnet and kustomize just for istio, with upgrade hell.

So I am sticking to helm as it feels way straight forward when you need to change just a few things from an upstream open source project: way fewer lines to maintain and change!

[fsniper]

Most of the time discussion derails as everyone is focusing on different aspects of the experience.

When you look into all the complaints one by one they are exceptionally acurate.

  * yaml has its quirks. - check
  * text templating can’t be validated for spec comformity - check
  * helm has lot’s of complexity - check
  * helm has dependency problems - check
  * helm charts can have too many moving parts with edge cases causing deep dive in the chart - check

and many others. However proposed solutions cut short on providing the value helm brings on.

Helm is not just a templating engine to provide kubernetes manifests. It’s an application deployment and distribution ecosystem. Emphasis on the "ecosystem".

  * It brings dependency management,
  * It provides kubernetes configuration management.
  * It provides abstraction over configuration to define applications instead of configuration.
  * It provides application packaging solution.
  * It provides an application package manament solution.
  * There is community support with huge library of packages.
  * It’s relatively easy to create or understand charts with a varied experience level. A more robust and strictly typed templating system would remove at least half of this spectrum.
  * The learning curve is flat.

When you put all of these in to consideration, it’s relatively easy to understand why it’s this prominant in the kubernetes ecosystem.