Our next-gen architecture is built to help you make sense of your ever-growing data.

Watch a 4-min demo video!

Terraform vs Helm Charts

  • Amir Raz
  • July 27, 2018
Share article
Helm Vs. Terraform

Since Docker first came onto the scene in 2013 and really popularized containerization, many organizations have chosen to deploy cloud workloads using Docker containers.

Containers come with numerous benefits over running applications directly inside of a virtual machine hypervisor, including significantly portability benefits and efficiencies in terms of storage and overhead.

Docker provides a runtime for running containerized applications, in addition to a format for encapsulating and delivering applications in containers.

With the increasing adoption of containerization, the need arose to manage, schedule and control clusters of containers, and that’s where Kubernetes comes in. Kubernetes is an open-source system for automating deployment, scaling, and management of containerized applications, generally being Docker containers.

When interfacing with Kubernetes, 2 competing tools are often discussed: Terraform, and Helm.

Terraform

Terraform is a tool for building, changing, and versioning infrastructure safely and efficiently. Terraform can manage existing providers, as well as custom in-house solutions.

Terraform

For example, in large-scale infrastructures, static assignment of applications to machines becomes a challenge. To solve this, there are a number of schedulers like the aforementioned Kubernetes that can be used to dynamically schedule Docker containers. Resource schedulers can be treated as a provider, which allows Terraform to request resources from them, enabling Terraform to be used in layers; setting up the physical infrastructure running the schedulers, and provisioning onto the scheduled grid.

Configuration management is critical in the software development ecosystem, and while people have used platforms like Chef or Puppet for this purpose, Terraform adds a whole new dimension.

Key features of Terraform include:

Infrastructure as Code: Infrastructure as code (or IaC) is the process of managing and provisioning computer data centers through machine-readable definition files, rather than physical hardware configuration or interactive configuration tools. With Terraform, infrastructure is described using a high-level configuration syntax, allowing a blueprint of your data center to be versioned and treated as you would any other code.

Smoothness through cloud provider’s API

Terraform actually uses the cloud provider’s API, which makes the whole process a lot smoother, and more effective in terms of maintainability, ease and security.

Stability and efficiency through immutable infrastructure

Forget about configuration drift and bugs. Terraform uses the immutable infrastructure approach, where servers are replaced rather than changed. This means simplified operations, fewer failures, and fewer errors, threats, and vulnerabilities.

Simplicity through code

With server provisioning, Terraform leaves issues pertaining to software container deployment to Docker. The cloud infrastructure is seen as code, bringing additional advantages.

Effectiveness through declarative code style

With a declarative code style (imperative programming: how you do something, declarative programming: what you do/what the end state should be), meaning advantages when it comes to succinctness, speed, and fewer complications.

Terraform works with any cloud-based setup, so it doesn’t matter if it’s public cloud or an on-premise-based setup.

It allows:

Execution Plans: Use the planning step to see what will happen when you call apply, avoiding nasty surprises.

Resource Graph: Builds a graph of all your resources, and build infrastructure as efficiently as possible.

Change Automation: Apply changesets to your infrastructure automatically, conserving resources and avoiding errors.

Terraform is open source, with strong community engagement.

Helm

Helm helps users manage Kubernetes applications, and Helm Charts assists users in defining, installing, and upgrading Kubernetes applications.

helm

Helm is maintained by the CNCF in collaboration with Microsoft, Google, Bitnami and the Helm contributor community.

Keeping with the nautical theme of docking, containers and quays, Helm enables Kubernetes users greater control over their cluster, just like the captain of a ship at the helm.

Helm Charts provide the ability to leverage Kubernetes packages when building and deploying applications through a click or single CLI command. When a user executes the Helm install command, a Tiller (yes, another maritime reference) Server receives the incoming request, installing the appropriate package into the Kubernetes cluster. These packages are called Charts.

A chart can have deployments, configmaps, services, and so on defined as yaml files, which are templates. You can define certain charts as dependencies for other charts, or nest charts inside others.

Helm has a number of advantages:

  • Deploy and manage manifests in a production environment
  • Complex applications can be packaged together
  • Rollback or upgrade multiple objects together
  • An extensive and reusable pre-built chart repository
  • Easily change parameters of templates
  • Deploy to multiple environments easily

Helm has been praised by users for its vibrant community, its ability to manage complex apps, in-place upgrades and custom hooks for hassle-free updates, the ability to share Chart, and easy rollbacks.

Terraform vs Helm

Both Terraform and Helmchart have a number of similarities, as well as some differences.

In terms of similarities, they allow you to describe and maintain Kubernetes objects as code, they support modularity, have a curated list of packages, allow you to see the impact of changes before running them, and allow installation from sources like git repositories or local directories.

In terms of differences, Terraform does not install anything within the Kubernetes cluster itself, while Helm installs Tiller within the cluster. Helm cannot install a Kubernetes cluster, while Terraform can. When it comes to modularity Terraform uses modules while Helm uses sub-charts, and Terraform uses the JSON/HCL file format while Helm uses standard manifests and Go-templates.

Both Terraform and Helm have their advantages and disadvantages. For example, because Terraform uses the same tool and codebase for both infrastructure and cluster management, there is not too much of a learning curve when it comes to using it with Kubernetes. Terraform is also relatively new with its Kubernetes interfacing, so there are some kinks and issues. On the other hand, rolling back with Helm is a lot easier, but maintaining it can take up precious resources.

The safe option is to go with Helm, as it has been around for a while and has proven itself, not to mention the support of some serious players behind its continuing development. Terraform is improving rapidly, however, and can do a lot of the heavy lifting for you.

Using the Tools to Add Value

The debate is likely to rage on for a while, but what cannot be disputed is the popularity of Kubernetes, and the value it can add to any organization. The great news is that with some simple integrations, there are configuration management tools available that can take Kubernetes to a whole new level. Coralogix can be integrated into Kubernetes logs with a pre-set image so that you can take advantage of everything the platform has to offer: including mapping software flows, automatically detecting production problems, delivering pinpoint insights and providing top-level visibility.

Observability and Security
that Scale with You.