What is Helm? The Benefits & Disadvantages

Most businesses serious about becoming agile or taking on digital transformation have considered containers as an alternative to standard monolithic applications. The reason for this is that containers make it far easier to not only deploy at scale but to deploy applications and services that are better suited for modern, cloud-centric needs. They also help with the addition of CI/CD automation while offering automatic scale up and scale down and a level of failover capable of delivering near five-9s uptime.

The thing most people neglect to tell you about containers (especially Kubernetes) is that deploying and managing those deployments isn’t easy. Not only do you have to first spin up the services that allow for container deployment/management, but you also have to carefully craft complex manifests that can devour a developer’s time.

To make this even more time-consuming, every time a developer is tasked with deploying yet another full-stack container, it’s back to the manifest drawing board. And as your apps and services become more and more complex, that lifecycle grows more challenging and time-consuming.

Fortunately, there’s a tool available to help ease both the complexity and time involved in deploying containerized applications and services.

That tool is called Helm.

What is Helm?

Think of Helm as the apt or DNF for containers. It’s a package manager that makes it possible to download charts, which are pre-packaged collections of all the necessary versioned, pre-configured resources required to deploy a container.

Helm charts are written in YAML and contain everything your developers need to deploy a container to a Kubernetes cluster. This makes it possible to download a chart, customize it (if necessary) and deploy it to your cluster with a single command. This simplification goes a long way to making container deployment more efficient, reliable, and repeatable.

Think about it this way: Helm charts are like templates that you can download, use, and re-use for the deployment of a container. So instead of always having to reinvent the wheel or start from scratch, you can always start with a predefined manifest and deploy from there.

The Benefits of Using Helm

The benefits of using Helm should already be obvious. First and foremost, they can save your development team a lot of time. Instead of having to start from square one each time, your developers can turn to Helm charts to get a considerable head start on deployment.

By making use of Helm, your business will immediately benefit from:

• Greatly improved productivity
• Reduced complexity of deployments
• Implementation of cloud-native applications
• More reproducible deployments and results
• Ability to leverage Kubernetes with a single CLI command
• Better scalability
• Ability to re-use Helm charts across multiple environments
• More streamlined CI/CD pipeline
• Easier rolling back to previous versions of an app (should something go awry)
• Numerous CI/CD hooks to automate actions and even schedule health checks

Another very important benefit of using Helm is that your developers will no longer need to construct individual YAML files for every application in a stack. With a Helm chart, you get everything necessary for the deployment, including resource configurations (which can be adapted as necessary). Given how complicated resource configurations can be (and how easily they can cause problems if poorly configured), this is often considered an important draw for Helm.

Even a simple Kubernetes manifest can get complicated. Here’s a very basic 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 far more complicated full-stack (with numerous applications and services that even connect to third-party APIs). If your developers have to write those out for every deployment, they are wasting precious time.

Instead, they could pull down a Helm chart, customize anything necessary in the downloaded chart, and then deploy with a single command. That’s considerably more efficient than writing everything from scratch.

Another major benefit of using Helm charts is they make it possible for your newer container developers to get up to speed quickly with how Kubernetes works. Download a Helm chart and start combing through the YAML files to see what’s what. Knowing everything within the package works as-is is a great way to learn how a successful manifest is built.

The Disadvantages of Using Helm

It’s not all perfect with Helm. Although the learning curve isn’t nearly as great as doing everything manually, your developers will have to get up to speed with not only customizing manifests but the Helm command-line tools as well.

Another disadvantage is Helm’s complexity. Your developers won’t just be pulling down simple single file manifests but very complicated packages of full-stack app definitions that can take some time to comb through and customize to fit your needs.

But even with those two disadvantages, Helm still makes a very complicated software lifecycle much more manageable.

The Pros & Cons of Helm Compared

Conclusion

If your development team is just now starting to dive into containers and Kubernetes (or if they’re only now starting to really grow their deployments), you should seriously consider Helm a must-have. That’s especially true if you want those teams working at top efficiency and your deployments to not only be highly available, but reliable and repeatable.