We spoke to two Helm maintainers — Matt Butcher, a Helm co-founder and Principal Software Development Engineer at Microsoft, and Matt Farina, a Senior Staff Engineer at Samsung SDS — about how the project reached this point and where it’s headed next.
Graduation is of course the big milestone, but what are you proudest of along the way?
Matt Butcher: We hit one million Helm downloads per month in November 2019. That was a really exciting milestone for us. Knowing that so many organizations and users have put trust in our project is a momentous occasion — though one that brings a high burden of responsibility.
At KubeCon San Diego, we got to do our first big introduction of Helm 3. Helm 3 had been a long and frustrating journey for us. The development work was arduous. It took longer than we wanted, and all the while we were frantically trying to keep Helm 2 up to date. KubeCon felt like the victory lap, and a good chance to celebrate all of the contributions and contributors that made Helm 3 a reality.
Matt Farina: When it comes to developing software, there are a lot of competing voices with opinions. There are Kubernetes insiders who know how the sausage is made. There are new application operators who are just getting started. There are those at fast-moving startups. There are those at slow-moving enterprises with regulations they need to meet. And just about everywhere in between.
The Helm developers have taken the time to listen to users and potential users. For example, some of the changes made to Helm v3 and the changes we are talking about in the coming year are targeted at making application operator experiences better and easier. I am proud that the Helm maintainers take the time to listen to end users and work on solutions to their real-world needs.
I think this is one of the things that’s made Helm a success.
Can you talk a bit about the graduation requirements, and how well Helm measured up on all the criteria?
Matt Farina: Graduating is no easy task. We didn’t just want to pass but wanted to excel at the graduation criteria.
For example, one of the criteria is to obtain a Core Infrastructure Initiative Best Practices badge. We not only obtained the best practices badge but are almost all the way to the silver level. This included the creation of a Helm Security Assurance Case, which looks at the way Helm is developed and operated from a security perspective.
Another requirement related to security is having completed a third-party independent security audit. This audit looked at both Helm and the security processes we have around the project. I was blown away at the conclusion from the security auditors, who wrote:
To conclude, in light of the findings stemming from this CNCF-funded project, Cure53 can only state that the Helm project projects the impression of being highly mature. This verdict is driven by a number of different factors described above and essentially means that Helm can be recommended for public deployment, particularly when properly configured and secured in accordance to recommendations specified by the development team.
A third criteria deals with adoption. While not a listed element in the criteria, which looks for some names of those using Helm which we provided, we also looked at Helm downloads over time in the spirit of viewing adoption. Between KubeCon + CloudNativeCon San Diego and Helm graduation, which was a little less than 6 months’ time, the number of downloads per month had doubled. I had to double check those numbers as I was just so surprised by them.
What are your goals or personal hopes for Helm?
Matt Butcher: I think the most interesting thing about Helm, vis-a-vis CNCF, is the fact that we are an old project. Helm was introduced at the very first KubeCon, and has grown up alongside the cloud native community. Over time, we have watched the broad CNCF community change from the “wild west” of research, experiment, refine to the mainstream enterprise market. I think every single one of the Helm core maintainers will tell you that today we spend most of our time talking about stability and maintainability, not new features and fun ideas.
In this vein, Helm will have two major challenges over the next few years.
On the one hand, we will have to learn how to say “no” to exciting features that are either too experimental or are of only niche appeal. I think Helm 3 is the last release where we’ll see any major feature changes. On the other hand, Helm has become the main “interface point” to Kubernetes for so many people that it is now incumbent upon us to protect people from the changes in Kubernetes. In this way, the Helm community has asked us to be the “backward compatibility” layer for Kubernetes. It’s an interesting circumstance to find ourselves in, but if we want to welcome and support the mainstream enterprise with its steady cadence, this is very much something that we should prioritize.
The days of “moving fast and breaking things” are over for Kubernetes, for Helm, and for the rest of the graduated CNCF projects. Sometimes that is hard for people like me to accept. I look back with fondness on the days when we could spike out a new Helm feature in a few days, and then cut a brand-new release a week later. Now, it routinely takes months to get a single pull request merged. An idea for a new feature might require months of debate, only to be rejected at the end. But if we are to keep the user’s best interests in mind, then this is absolutely the way we should go. So it is not just the project that must mature, it is us as core maintainers as well.
Any shoutouts you want to give to the community?
Matt Farina: In the past year we have seen some new people and new contribution areas that, I think, deserve to be highlighted. These are beyond the usual suspects and typical Helm topics.
Marc Khouzam rewrote the way Helm handles auto-completion to make it easier to work with. The feature worked so well, he was able to get it upstreamed into Cobra, which Helm uses for its base console functionality.
The OCI is working on artifact support in distributions, which will allow us to store Helm charts in container repositories. Josh Dolitsky has done a great job working with the OCI and getting code, currently in experimental form, into Helm to support this.
Helm is moving to a distributed Helm repository environment, where we make it easier for organizations to run their own repositories. Scott Rigby and Reinhard Nägele have been working on tools, including GitHub Actions, to make the automation easier. You can find the actions in the GitHub Marketplace.
These are just a subset of the people doing amazing work in the community. There are too many to name, and we appreciate all of them.
Matt Butcher: I almost feel like it would be unjust to call out only a few. Thousands of people have contributed over time. And sometimes it’s those small patches or updates to the documentation that make a world of difference. But I do feel like I should call out Martin Hickey, one of the Helm core maintainers, for his long-term “chop wood, carry water” mentality. If one were to assemble a room full of Helm users, and then ask those in the room to raise a hand if Martin had helped them (via Slack, via issues, or even with his helpful utilities and conference talks), I would not be surprised if 75% of the audience put a hand in the air.
Of course, Martin is not the only generous soul in the community, but I am deeply appreciative of the work he has done day after day.
What do you want the greater community to know about Helm?
Matt Butcher: Since the very first day of Helm development, we have called it the “package manager for Kubernetes.” Hidden in that phrase, though, are two goals that we keep at the top of our minds:
- Helm should be a reliable tool for installing, upgrading, and deleting Kubernetes applications.
- Helm should be the easiest way for a new Kubernetes user to install their first application.
It has been hard to stick to these two goals. Many people want Helm to be a replacement for Chef or Puppet or tools like that. Others pit Helm as a competitor to the operator design pattern. Still others want us to morph Helm into an application management platform. It was not until recently that we, as the core group of maintainers, had to begin to draw some lines. Helm cannot be the Swiss army knife of the cloud. And we shouldn’t be. There are thousands of brilliant developers out there building excellent tools in each of those niches. The mentality that we need to “own the space” is, to put it bluntly, nonsense.
At the end of the day, Helm needs to stay true to its role as the package manager for Kubernetes, and strive to meet those same two goals we set out to achieve five years ago.
Maturing as a project is hard. Maturing as a developer and a project leader is hard. But I earnestly believe that if we can build a project that keeps a tight and narrow focus, we can produce a superior tool that solves a core set of problems well. If we let our focus drift, we may solve more problems — but we will solve them poorly in ways that frustrate and ultimate drive away the users we care about.
For more about Helm, check out the CNCF webinar Charting Your Voyage to Helm 3 on June 12.