Helm is the first application package manager running atop Kubernetes. It allows describing the application structure through convenient helm-charts and managing it with simple commands.
Why is Helm important? Because it’s a huge shift in the way the server-side applications are defined, stored and managed. Adoption of Helm might well be the key to mass adoption of microservices, as using this package manager simplifies their management greatly.
Why are microservices so important? They have quite a few uses:
- When there are several microservices instead of a monolithic application, each microservice can be managed, updated and scaled individually
- Issues with one microservice do not affect the functionality of other components of the application
- New application can be easily composed of existing loosely-coupled microservices
Of course, Helm is not the unique package manager, nor is it perfect. However, the project is now being actively developed and grows a passionate community that appreciates the benefits of using Helm charts for software development.
Helm benefits and flaws
Unlike Homebrew or Aptitude desktop package managers, or Azure Resource Manager templates (ARMs) / Amazon Machine Images (AMIs) that are run on a single server, Helm charts are built atop Kubernetes and benefit from its cluster architecture. The main benefit of this approach is the ability to consider scalability from the start. The charts of all the images used by Helm are stored in a registry called Helm Workspace, so the DevOps teams can search them and add to their projects with ease.
For example, you need to launch a website built with WordPress, Joomla, Django or any other CMS. You expect the website to receive millions of daily visitors from the day one and you must make sure such huge numbers of connections will not lead to freezes or service unavailability.
Using virtualization capabilities ensures scaling, yes. Just keep in mind that an AMI, ARM (or a Docker container for that matter) you use to launch the app will be dependent on the Virtual Machine it is stored on and will be able to scale only the way the virtual machines are scaled — by adding more resources to the pool.
With Helm, we have quite another picture. The application can be composed of clearly defined microservices and we can scale only the ones we need to scale, adding more Kubernetes nodes and pods to the cluster. Instead of working with a holistic image and growing all the resources, you operate a set of images and scale them independently.
The problems begin when you want to launch a new instance of an application that runs, let’s say, 50 microservices. Starting and combining them all will be a laborious and error-prone task. However, with Helm, all you need to know is the name of the charts for the images responsible. Launching a new instance is the question of executing the corresponding Helm chart.
The only significant issue with Helm so far was the fact that when 2 helm charts have the same labels they interfere with each other and impair the underlying resources. This means it’s better to compose a new image for the project than adding a single Helm chart to it and affects the rollbacks too. However, the community has found workarounds for the issue and we are sure it will be removed for good in the future versions of the tool.
Final thoughts on the future of Helm
We are sure Kubernetes is the future of container orchestration in the cloud, and Helm is the way to use Kubernetes most efficiently. Of course, the DevOps team can do the same using standard kubectl commands, yet working with Helm provides the ability to quickly define, cleanly manage and easily deploy the applications. Thus said, the Kubernetes + Helm duo can (and must) become the basic toolset for any DevOps specialist in the years to come, namely a helm to navigate the cloud and deliver the containers safely.