What is Helm and why you should love it?
- Azure Cloud CMS DevOps Helm Kubernetes Microservices News Workflow
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.
What do you think on the topic? How was your experience with Helm? Did it help you streamline your microservice management? Please share your feedback in the comments below!
Feel free to browse through the latest insights and hints on the DevOps, Big Data, Machine Learning and Blockchain from IT Svit!
What if the transition to the cloud does not increase your profits?
The biggest fallacy of nowadays world is the so-called Productivity paradox, which states that the increase in investments in the IT operations does not lead to the growth of productivity.
Guide to AWS platform migration: AWS migration best practices
One of the most common tasks we perform at IT Svit is cloud migration from AWS to GCP, Azure, DigitalOcean and vice versa, or from legacy infrastructure to the cloud.
What if a company could really inspire self-development in employees?
There are tons of materials from multiple experts and gurus, who promise to teach businesses to inspire their teams, to make the employees grow and become more productive. However, their methods rarely work. Why so? We describe our vision of why conventional employee engagement practices fail, and how to really inspire the employees to self-development.