Posted on July 6, 2021
How-To Guides
In many ways, management tasks are much more complicated these days. Your team needs to bring up one hundred new AWS instances, network them together and load balance them. By Monday.
You already have twenty instances on VMWare Cloud and another ten in Microsoft Azure. On top of that, you need to make sure you roll your application out in a standard and security-conscious way.
Whether you choose to roll-your-own deployment and infrastructure or need a fully managed, security-forward Private Cloud, it’s important to ask some basic questions.
Which tools should you use to manage your deployment lifecycle? What are the pros and cons of using Terraform vs Helm?
Read on and see how you can use both Helm and Terraform’s strengths.
The world has moved on from mainframes. Applications aren’t rolled out to a single server anymore though colocation is becoming popular. People have found new ways to describe what they want to create. Infrastructure as Code just allows you to describe what you want in a way that’s easy to understand.
If you use technology like Git, you already have a way of keeping track of changes to your applications. It’s helpful to think of Infrastructure as Code in the same way.
State is simple to think about – we need to know what we have, what we want to have, and how to get there. It’s important to track this in a good way that also lets us observe it. You want to see what’s already out there before you start creating anything new.
If I have thirty instances at the moment and I want one hundred, I need seventy new instances. I need tools to track where I am (thirty) and where I want to be (one hundred).
Terraform emerged as the leading contender to describe infrastructure. It has a simple approach, easy-to-understand syntax, and can describes all your resources quickly.
If you were using a cloud provider like Microsoft Azure, you would need to use specific tools to manage resources. This usually means a command-line interface or API. While those work very well with particular vendors, it’s easy to see that things could become very complicated if you were to switch from, say, Azure to AWS.
Terraform solves this problem by giving you “providers” and “modules” to deal with different vendors. This takes the responsibility of working with the vendor away from your code. Now you show what you want to achieve without needing to know all the magic behind how.
Terraform also does a great job of keeping track of everything that’s going on with your resources. Using the “terraform plan” command gives you a plan of what Terraform will do. This means you should never be surprised by the outcome of an action. Terraform will tell you if a resource is going to be added, deleted, or updated.
Those one hundred AWS instances we talked about earlier? They would be straightforward to describe in Terraform code. Terraform will also keep track of the state of your resources.
Terraform supports both local and remote state files, so all the code describing your infrastructure can be backed up . This also lets many team members work on it at the same time.
Terraform supports most significant providers, with more coming on board all the time. There’s a registry of all available providers, Official (written by Hashicorp), Verified (Certified as good by Hashicorp), and Community.
Best of all, due to its open-source nature, if there’s a feature or provider that’s missing, it’s simple to contribute code that will add it.
Helm exists to help sensibly manage Kubernetes applications and packages.
Before V3, you would have had to track Kubernetes applications using complex YAML files. This could become confusing and difficult to maintain.
Helm still uses YAML, but it follows rigid standards and best practices. Like Terraform, Helm also has a list of supported packages that have been verified as good to use.
Before V3, you would have installed “Tiller”. Tiller allowed teams to share the same set of application releases and definitions. Now, Kubernetes handles this using internal controls and processes, alleviating many security concerns.
Introducing Helm allowed applications to be managed using “Charts.” Charts give a way to work with complex concepts in a repeatable and standardized manner. Easy roll-back of applications/application versions make Helm a clear winner.
Terraform describes the way you want your infrastructure and resources to be. Helm explains the way you wish applications to behave in a Kubernetes context.
Let’s break down some of the scenarios you are likely to encounter and check each tool’s effectiveness.
Terraform can be used to manage infrastructure and all the attached resources, while Helm’s primary purpose is to manage applications and application states from within a Kubernetes cluster.
Terraform’s Helm provider seemed to be a way to use one tool to manage both infrastructure and applications and is still popular in limited circumstances. The Helm Provider has also had several issues related to chart cache that could cause significant issues while changing existing, running applications.
If you consider that Terraform uses a state file to keep track of every status, it’s easy to see that storing complicated application descriptions would lead to a very complex state file.
While not as granular as the control you get by using Helm to manage applications directly, you could also use the Terraform Kubernetes provider as an end-to-end solution for provisioning Kubernetes resources (clusters, nodes, node-pools), managing their lifecycle through planned create/delete/update actions, and even creating deployments and services.
This approach has the advantage of using a single tool, but any added complexity is likely to make this much harder to deal with in the medium to long term.
Helm’s state management is through Kubernetes itself, making it robust, available to everyone (with access), and simple to roll back. Because Helm stores previous versions of the application state in Kubernetes, rolling back is simply “pointing” the application at the last state.
If you have a heavy reliance on external providers and need to use information from them in your helm charts, it may make sense to use the Terraform Helm provider, but otherwise, this is a task best left to Helm.
Both Terraform and Helm support using modules though their way of talking about them differs (Helm calls them “sub-charts” while Terraform calls them “modules”)
Conventional wisdom suggests that rather than one complex Terraform module, several smaller, simpler modules work well.
Typically, you would use Terraform to break the infrastructure deployment into several distinct parts.
Likewise, Helm favors simplicity over complexity and does an excellent job of keeping application definitions separate. A modular approach to developing, testing, and deploying your applications means a faster, more agile cycle of improvement.
Helm V3 was released to address security concerns that the community had brought up over time. These mainly had to do with the use of Tiller and the broad permissions it required when being installed.
All permissions are now handled through Kubernetes directly so that cluster administrators can have a highly granular view of access rights.
Because of its modular approach to administering resources, Terraform is secure by nature – a user must have access to act on the resources to make any changes.
Similarly, Providers are merely giving gateways into their systems (For example, the AWS provider for Terraform), so permissions are not relevant out of this context.
So you can safely manage your Cloud Security separately from your code deployment.
A hybrid approach looks like it would give the best results. First, use Terraform to define your team’s initial infrastructure and resource needs. The Terraform Helm Provider can set up initial application states. This is useful before there are complex changes that might render them too complicated to maintain.
Then, use Helm to describe and manage your application rollout across that infrastructure. Helm will provide you with a robust, manageable way to roll out your applications globally while leveraging the stability of Kubernetes for the state.
Your Helm charts can be as complex or simple as you would like them to be. Sub-charts help to contain complexity. You won’t have to worry that you’re leaving permissions too open because Kubernetes will be handling all access control.
Managing your array of cloud computing resources and trying to stay on top of the trends can be daunting. Rather than Terraform vs Helm, you will need decide which tools to use. You should consider whether to run these complex systems yourself or use a company that has experience in managing them.
We provide a fully secure, managed cloud solution and would love to give you a solution. When you’re ready, contact NetDepot.