What is helm? The benefits and disadvantages

Most companies looking to become agile or undertake digital transformation have considered containers as an alternative to standard monolithic applications. The reason for this is that containers make it much easier not only to deploy at scale, but also to deploy applications and services that are better suited to modern cloud-centric needs. They also help with the addition of CI/CD automation, while offering automatic scaling up and down and a level of failover capable of providing uptime of nearly five to nine seconds.

What most people fail to tell you about containers (especially Kubernetes) is that deploying and managing these deployments is not easy . Not only do you first need to enable services that enable container deployment/management, but you also need to carefully create complex manifests that can consume a developer's time.

To make this even more time-consuming, every time a developer is tasked with deploying another full-stack container, they go back to the manifest drawing board. And as your applications and services become increasingly complex, this lifecycle becomes more challenging and time-consuming.

Fortunately, there is a tool available to help alleviate the complexity and time involved in deploying containerized applications and services.

This tool is called Helm.

What is helm?

Think of Helm as apt or DNF for containers. This is a package manager that makes it possible to download charts, which are pre-packaged collections of all the pre-configured and versioned resources needed 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 in making container deployment more efficient, reliable, and repeatable.

Think of it this way: Helm charts are like templates that you can download, use, and reuse for your container deployment. So instead of always reinventing the wheel or starting 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 be obvious by now. Firstly, they can save your development team a lot of time. Instead of having to start from scratch every time, your developers can turn to Helm charts to get a considerable head start on deployment.

By using Helm, your company will immediately benefit from:

• Greatly improved productivity
• Reduced complexity of deployments
• Deploying cloud-native applications
• More reproducible deployments and results
• Ability to leverage Kubernetes with a single CLI command
• Better scalability
• Ability to reuse Helm charts across environments
• Simplified CI/CD pipeline
• Easily roll back to previous versions of an app (if something goes wrong)
• 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 build individual YAML files for each application in a stack. With a Helm chart, you get everything needed for deployment, including resource configurations (which can be adapted as needed). Given how complicated feature configurations can be (and how easily they can cause problems if misconfigured), this is often considered a major draw for Helm.

Even a simple Kubernetes manifest can be complicated. Here is 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 much more complicated full stack (with multiple applications and services that even connect to third-party APIs). If your developers have to write them for every deployment, they will be wasting precious time.

Instead, they could download a Helm chart, customize whatever was needed in the downloaded chart, and then deploy with a single command. This is considerably more efficient than writing everything from scratch.

Another big benefit of using Helm charts is that they allow newer container developers to quickly get up to speed with how Kubernetes works. Download a Helm chart and start digging through the YAML files to see what it is. Knowing that everything inside the package works as is is a great way to learn how a successful manifest is created.

The Disadvantages of Using Helm

Not everything is perfect with Helm. While the learning curve isn't as steep as doing everything manually, your developers will have to get up to speed with not only manifest customization but also Helm's command-line tools.

Another disadvantage is Helm Complexity . Your developers won't just extract simple single-file manifests, but very complicated packages of full-stack application definitions that can take some time to parse and customize to meet your needs.

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

Helm's pros and cons compared

Conclusion

If your development team is just starting to dive into containers and Kubernetes (or if you're just now starting to really scale up your deployments), you should seriously consider Helm as a must-have. This is especially true if you want these teams to work at peak efficiency and your deployments to be not only highly available but also reliable and repeatable.