In 2017 we all had front-row seats to the overwhelming domination of Kubernetes. It's on every cloud, it's running in the world’s biggest data centers, and it's making a big impact on the way companies host software. In 2018 this adoption will shift into high gear, fueled in large part by a quickly growing project called Helm.

Helm, a package manager for Kubernetes-based applications, lets software engineers define application services, how they work, and how they interact with each other. This represents a major evolution in the way server-side software is deployed, managed, and defined. The shift is a key component in the mass adoption of microservices, and it's going to be big.

Anyone who has used a desktop package manager such as Homebrew or Aptitude understands the value. Rather than building a single, monolithic application, using a package allows you to pull and reuse parts from other software. This speeds up development, improves security, and makes managing and updating an application easy. Installing a package is as simple as knowing its name.

Cloud's packaging challenges

Vendors have long struggled with the challenge of packaging applications for the cloud. Amazon has Amazon Machine Images (AMIs), Microsoft has Azure Resource Manager (ARM) templates, and to some degree Docker containers have been used to fit the bill.

Each of these has its own problems. And in most cases, defining an application requires that the package run on a single server.

Helm, on the other hand, is built on top of Kubernetes and takes advantage of that architecture to manage scalable packages.

Let's say I want to launch a WordPress site. I could use an AMI or Docker image that has everything WordPress needs to run. But because these templates are linked inherently to virtual machines, you can scale only in the way VMs allow. In other words, I have to install those images on a larger machine and feed it more resources.

With Helm, WordPress is defined as a set of services that can all run on their own Kubernetes pods and nodes. With Helm, setting up a WordPress site that can handle millions of connections is simple. You're not replicating a single image with all the components; you're pulling in a set of images that can all scale independently of one another.

Helm will be the new default for defining apps

One of the challenges in building microservices-based projects is decreased portability. The application is more robust and scalable, but how do you stand up a new instance? Without a package manager, creating a new instance of a project with, say, 50 different microservices is a nightmare.

With Helm, it's a simple matter of knowing the name of the package, or chart, you want to install.

This leads to some exciting possibilities. For instance, some of our users have been using Helm to define their application and stand up one-off ephemeral environments for testing and development. This removes the bottleneck caused by a traditional staging server and gives teams scalability and faster engineering loops.

The battle in 2017 was to see which cloud orchestrator would take over. Kubernetes won that. Now in 2018, Helm is poised to become the de facto technology that allows engineering teams to take full advantage of Kubernetes.

Keep learning