Guest post originally published on the Nirmata blog by Spruha Pandya

The adoption of microservices architecture has revolutionized the way applications are developed today. As the microservices architecture replaced the monolithic architecture, containers replaced VMs. However, with this transformation, application deployment was no longer an easy task. Container orchestration was a new challenge, which was solved by Kubernetes. Just like any new technology, containers and Kubernetes brought in new complexities with them.

Among all the challenges, deployment and management of applications on Kubernetes has proved to be the most difficult one for IT teams. But, due to the runaway success of Kubernetes, there is a growing ecosystem of tools focussed on addressing the complexities of application deployment. The majority of these tools exist as open-source projects maintained by the developer community. Helm is one such open-source project that has been successfully simplifying the lives of Kubernetes users since 2016.

Helm is a result of the combined efforts of Deis (a container tooling company, now part of Microsoft) and Google. It was a part of the Kubernetes 1.4 release in 2016. Helm helps IT teams manage Kubernetes applications through Helm Charts. These charts can enable teams to define, install, and upgrade even the most complex Kubernetes applications.

What makes Helm so popular?

While the problem of managing applications on Kubernetes can be complex, Helm itself is quite simple to use. Here is a typical view of how deployments happen without helm and how Helm simplifies them.

Without Helm:

Teams rely on Kubernetes YAML files to configure Kubernetes workload. These YAML files specify everything needed for deploying containers. Everything from the way each Pod needs to be configured to how load balancing is done by the Kubernetes cluster, has to be mentioned in those YAML files. Thus, to set up a new Kubernetes workload, you need to create a YAML file for that workload. To do it manually means writing multiple YAML files – one for each workload you create.

With Helm:

Instead of having to write separate YAML files for each application manually, you can simply create a Helm chart and let Helm deploy the application to the cluster for you. Helm charts contain templates for various Kubernetes resources that combine to form an application. A Helm chart can be customized when deploying it on different Kubernetes clusters. Helm charts can be created in such a way that environment or deployment-specific configurations can be extracted out to a separate file so that these values can be specified when the Helm chart is deployed. For example, you need not have separate charts for deploying an application in development, staging, and production environments.

Helm has evolved with time and with each new upgrade, it has made application management on Kubernetes simpler. With the recent release of Helm 3, the benefits have surpassed expectations of the DevOps community and it has been happily added to the list of must-have tools for deploying applications to Kubernetes.

Helm 3 – Adiós Tiller

When Helm 2 was launched, Kubernetes did not have Role-Based Access Control (RBAC). Helm included a component called Tiller which was responsible for deploying the chart. But, with newer versions of Kubernetes, RBAC is enabled by default and Tiller allows users to bypass access control. So, in Helm 3, the Tiller was removed – finally eliminating the security weak-link of Helm, making it more reliable and stable.

Benefits of Helm:

Even with all these benefits, Helm 3 isn’t all rainbows and sunshine…

Helm Alternatives

When it comes to CI/CD with Kubernetes, it is challenging for a tool to address all scenarios well. Helm tries to simplify application deployment but has some limitations. There are several alternatives to Helm available that you might want to explore if Helm does not meet your needs.

Out of all the Helm alternatives out there, Kustomize is the most popular. Kustomize is a template-free way to customize application configurations and manage Kubernetes workloads. There are several instances in which templating using Helm could be complicated. This is when Kustomize can come to your rescue. Developers tend to use both, Helm and Kustomize depending on their requirements. When it comes to the question of which one is better out of the two, the jury is still out there.

Final Takeaway

Additionally, there is one more thing to keep in mind while starting off with container deployment – do not lose sight of the big picture. DevOps users need the flexibility to choose the right tool based on their requirements. But it is also important to ensure that you are aware of the limitations of these tools so that your project is not stalled or delayed. Helm is definitely a popular tool when it comes to packaging your applications and it is also the most widely supported by container management platforms such as Nirmata.

Kubernetes offers many advantages to Day 0 and 1 stages of the application lifecycle. However, most organizations have found it lacks critical Day 2 capabilities like reliability, security, and risk management. Download the Day 2 Kubernetes whitepaper to understand these challenges and how you can maximize your success with Kubernetes.