Happy 1st Birthday Helm!
The Story Behind Helm
Happy 1st Birthday, Helm!
On October 15th, 2015, the project now known as Helm was born. Only one year in, Kubernetes Helm is part of the CNCF, and is marching toward the v2.0.0 release. And in every sense of the word, it is now a community-driven project. But the circumstances behind the creation of Helm read like a script for a Silicon Valley tech comedy.
Deis v1, the Fleet-based PaaS system, had a command called
deisctl that could be used for (among other things) installing the Deis platform. In July of 2015, we shifted the foundation of Deis. We switched from Fleet to Kubernetes. And one of the things we had to rewrite was the installation tool.
My first shot at this was a shoddy command line tool I called Trireme. It took a set of Kubernetes manifests, ran a few simple substitutions, and loaded them into Kubernetes. But for many reasons, this early Kubernetes installer required hard-coded lists of manifest files. And it performed a fixed sequence of events. It was painful enough to use that I couldn't even convince the other two members of the Deis v2 R&D team to use it. But the seed of an idea was there.
The Fruits of a Hackathon
Fast forward to October, and the Deis team had blocked off a few days for an off-site. We had many serious meetings about Deis v2, Kube-Solo, and team structure. We had a few not-so-serious sessions, like one involving giraffes and owls learning Kubernetes. But we also decided to do a hackathon project. The company broke into multiple teams of 2-4 people, and each team built a little mini-project.
From database provisioning to running Vault in Kubernetes, there were some really cool projects. When Jack Francis, Rimas Mocevicius, and I got together, we weren't really sure what we were going to do. Jack had just been working on a Node.js project, and I was working on Glide, so one of our conversations veered toward package management. Rimas had just demoed Kube-Solo (a GUI tool for running Kubernetes easily on OSX). It didn't take long for this conversation to home in on a big question: Could we take the ideas behind npm and Glide and build something for deploying apps into Kubernetes?
Over the next day and a half, we rushed through a prototype. Jack wrote a package management server. I wrote a client. Rimas wrote the first ever chart files. Remarkably, it came together without a hitch, and we had a prototype that worked well enough for us to demo it live at the end of the hackathon.
Fun Facts (for Small Definitions of "Fun")
- The original names were a little different than what we presently have:
- The server was called k8splace, pronounced Kate's Place. We liked the friendly coffee-shop vibe.
- The client was called
- The original package format was called
k3, pronounced kay cube.
- During the hackathon we put together a design document that is remarkably similar to today's Helm.
- Our very first version intended to use Python Jinja as a template language.
The Race to KubeCon
We demoed k8splace at the end of our offsite meeting. Our demo was just splashy enough to get everyone excited about the potential of such a tool. But our plan was to get back to work on Deis v2.
When I showed up in the office the following Monday, though, plans had changed. The first ever KubeCon was coming in a month. Might we be able to transform our demo into something we could talk about there? By the end of that day, Gabe, Jack, Rimas, and I were busy translating our hackathon project into a product.
Naming is Hard
While we really did like the name k8splace, it didn't quite fit. We wanted something nautical to go with the name Kubernetes. So Jack and I had one of the strangest Google Hangouts I've ever experienced. We each found an online nautical dictionary, and we spent over an hour reading nautical terms back and forth to each other.
I learned why "talking like a sailor" is not a good thing.
After giving up on prow, mast, and countless others, we alighted on helm as the name for our tool. Being short, it made sense not just as the project name, but also as the command name. So k8splace and
kpm both vanished.
But when it came time to name of the package format, we found ourselves stuck. Calling a package a helm felt wrong. The original K3 name felt a little pretentious. We could imagine ourselves forever repeating, "It's pronounced KAY CUBED!" over and over again.
So we went back to our nautical dictionaries. Map had the right idea, but wasn't quite right. We tossed a few similar ideas past Beau, who is both our CEO and an actual real-life sailor. He kindly pointed out that sailors do not use maps, they use charts. And we had it.
With naming behind us, we formed a small team of engineers to work full time on Helm. Adam Reese and Michelle Noorali joined the nascent Helm team, and in the next three weeks we churned out Helm 0.1.
By late December, Helm was relatively feature complete. We were already using it for deploying Deis v2, and we were hearing many encouraging stories from the Helm community. As 2015 wound to a close, a team from Google called. They, too, had been working on a similar tool for Kubernetes. Deployment Manager (DM) for Kubernetes was a port of an existing tool they used for Google Cloud Services. Would we be interested, they asked, in spending a few days talking about similarities and differences?
In January, the Helm and DM teams sat down in Seattle to share some ideas. We walked out with a bold plan: Merge the projects, and create Helm v2. Along with Deis and Google, SkipBox joined the development team, and we got coding.
For the next three months, we took the DM codebase and tried to rewrite Helm to fit it. We made progress, but the resulting tool was veering from Helm's original intent. We hit a wall.
One afternoon, Michelle and I headed over to the whiteboard wall. We decided to go back to the basics: What should this tool feel like to the end user. This conversation led to the realization that while we had not made any huge mistakes, we had made so many small ones that we had veered hopelessly off course.
Over the next few weeks we made some tough decisions. The cumulative result was that we needed to return to the original Helm codebase and start over from there. In case you're counting, this was the fourth time we rebuilt Helm within a six month window.
Soon after, Bitnami joined the project as core contributors. Having already built many Helm v1 charts, the Bitnami team had a wealth of insight to share. In just a few weeks, they suggested numerous changes designed to make the entire process better for the user. And we were off again.
As Helm v2 rapidly approaches feature completion, it has been surprising to pause and look back at the course we've followed.
- Helm today is still astonishingly similar to the original k8splace design
- DM's approach to server-side management radically changed our view of how to deploy into Kubernetes
- We are passionate about building a tool that is good for the user. And that has been harder than any algorithm we've implemented
Helm now has over 55 contributors, and hundreds upon hundreds of active community members. This is a credit to the colossal efforts of the Kubernetes community which has transformed this project from a shoddy Deis installer into a power tool for all Kubernetes users.
You should also read Rimas' recollection.