What is Helm and why developers should use it?

Most companies that are serious about transitioning to agile management or digital transformation consider containers as an alternative to standard monolithic applications. The reason is that containers allow not only deploying large-scale applications but also deploying applications and services that are better suited for modern cloud-oriented needs. Additionally, containers facilitate CI/CD automation, provide automatic scaling up and down, and a level of fault tolerance capable of achieving uptime close to 5 nines.
Most people talking about containers (especially Kubernetes) forget that deploying and managing these deployments is not trivial. Not only do you need to first run the services that allow deploying and managing containers, but you also need to carefully develop complex manifests that can take a lot of developer time.
Even more time is consumed because every time a developer has to deploy another full-stack container, they go back to the drawing board with manifests. And as your applications and services become more complex, this lifecycle becomes increasingly difficult and time-consuming.
Fortunately, there is a tool that simplifies and eases the deployment of containerized applications and services.
This tool is called Helm.

What is Helm?

Think of Helm as apt or DNF for containers. It is a package manager that allows you to download charts, which are pre-packaged collections of all the necessary versioned and pre-configured resources required for deploying a container.
Helm charts are written in YAML and contain everything developers need to deploy a container on a Kubernetes cluster. This allows you to download a chart, configure it (if needed), and deploy it on the cluster with a single command. This simplification makes container deployments more efficient, reliable, and repeatable.
Think of it this way: Helm charts are like templates that you can download, use, and reuse for deploying a container. Thus, instead of constantly reinventing the wheel or starting from scratch, you can always start with a predefined manifest and deploy based on it.

Benefits of Using Helm

The benefits of using Helm should already be obvious. First and foremost, they save the development team time. Instead of starting from scratch every time, developers can refer to Helm charts and get a significant head start on deployments.
By using Helm, your business will immediately gain the following advantages:

• Significant increase in productivity
• Reduction in deployment complexity
• Adoption of cloud-native applications
• More reproducible deployments and outcomes
• Ability to leverage Kubernetes with a single CLI command
• Improved scalability
• Reusability of Helm charts across different environments
• More streamlined CI/CD pipeline
• Easier rollback to previous application versions (if something goes wrong)
• Numerous CI/CD hooks for automating actions and even scheduling health checks.

Another very important benefit of using Helm is that your developers no longer have to create separate YAML files for each application in the stack. With a Helm chart, you get everything needed for deployment, including resource configurations (which can be adapted as needed). Given how complex resource configurations can be (and how easily they can cause issues if misconfigured), this is often considered a key advantage of Helm.

Even a simple Kubernetes manifest can become complex. Here is a very simple example:

apiVersion: apps/v1
kind: Deployment
metadata:
name: postgres

labels:
  app: database
spec:
replicas: 1
selector:
  matchLabels:
    app: database
template:
  metadata:
    labels:
      app: database
  spec:
    containers:
    - name: postgres
      image: postgres:latest
      ports:
      - containerPort: 5432
      volumeMounts:
      - name: sqlscript
        mountPath: /docker-entrypoint-initdb.d
      env:
        - name: POSTGRES_USER
          value: "postgres"
        - name: POSTGRES_PASSWORD
          value: "postgres"
    volumes:
      - name: sqlscript
        configMap:
          name: pg-init-script

Now imagine you need to create a much more complex full-stack (with numerous applications and services that even connect to third-party APIs). If your developers have to write them for each deployment, they lose precious time.

Instead, you can pull a Helm chart, configure everything needed in the downloaded chart, and then deploy it with a single command. This is much more efficient than writing everything from scratch.
Another important advantage of using Helm charts is that they allow novice container developers to quickly get up to speed with Kubernetes. Download a Helm chart and start browsing the YAML files to understand what's what. Knowing that everything in the package works as-is is a great way to learn how a successful manifest is built.

Disadvantages of Using Helm

Not everything about Helm is perfect. While the learning curve is not as steep as doing everything manually, your developers will need to learn not just manifest configuration but also the Helm command-line tools.
Another drawback of Helm is its complexity. Your developers will get not just simple single-file manifests but very complex packages with a full set of application definitions, which can take a considerable amount of time to sift through and customize to your needs.
But even with these two drawbacks, Helm makes a very complex software lifecycle much more manageable.

Conclusion

If your development team is just starting to dive into containers and Kubernetes (or is just beginning to truly scale its deployments), you should seriously consider Helm as a must-have. This is especially true if you want these teams to operate with maximum efficiency and have deployments that are not only highly available but also reliable and repeatable.