Conclusions: Cool, but …

Helm is not a plain vanilla package manager. If you compare it with rpm or dpkg, you always need to bear in mind that they also deliver preconfigured services, but multiple packages are usually not aligned with each other. A Helm chart, on the other hand, rolls out prebuilt images that are perfectly matched. The "packages" in this equation are ready-made Docker images, which are usually created and offered for sale by the software providers themselves. Helm spins a web of configuration around the images and provides the administrator with a simple interface to launch new workloads on K8s or modify existing ones.

Accordingly, Helm competes with automators, such as Ansible, Chef, and others, which can now also launch workloads in K8s. For instance, an Ansible playbook would be a conceivable option for getting ownCloud up and running in K8s – with the drawback that it would not be natively integrated into K8s. On the other hand, a playbook would not suffer from the problem that many rightly criticize in discussions on Helm. It would not be a YAML shovel that receives configuration parameters from the user on one side and passes them on to the programs in the containers on the other.

At this point Helm runs into a systemic problem: If you want to offer all the parameters of the containerized applications for changes, you have to pass them through to the outside somehow. Parts of the Helm chart for ownCloud therefore basically work as a simple translation tool for parameters. However, if you want to use the full set of ownCloud parameters, you might end up writing a suitable pod definition yourself at the end of the day. Helm does offer a genuine efficiency boost, though, especially if you intend to adopt most of the defaults defined by the chart developers.