Terraform, Kubernetes and Helm – What and Why

<p>Terraform, Kubernetes and Helm are all infrastructure tooling that have grown in popularity and use. These tools are in line with best practices and management of the deployment of infrastructure and applications. While the initial burden to learn these tools can be quite high, after the initial investment they simplify the deployment and management and allow scaling and growth of both the infrastructure and application quickly and painlessly.</p> <p>In this post we will talk about the “what” and “why (and when)” for each of these popular tools.</p> <h2 class="wp-block-heading" id="What">What</h2> <h3 class="wp-block-heading" id="Terraform">Terraform</h3> <div class="wp-block-image"> <figure class="aligncenter size-large is-resized"><img loading="lazy" decoding="async" src="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/Terraform_PrimaryLogo_Color_RGB-1024x361.png" alt="Terraform logo." class="wp-image-1697" width="379" height="134" srcset="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/Terraform_PrimaryLogo_Color_RGB-1024x361.png 1024w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/Terraform_PrimaryLogo_Color_RGB-300x106.png 300w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/Terraform_PrimaryLogo_Color_RGB-768x271.png 768w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/Terraform_PrimaryLogo_Color_RGB-1536x542.png 1536w, https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/Terraform_PrimaryLogo_Color_RGB-2048x723.png 2048w" sizes="(max-width: 379px) 100vw, 379px"></figure></div> <p>Terraform is an infrastructure as code language that is designed to create infrastructure and keep it in sync with any changes to the terraform code. The job of Terraform is to make changes only when the code specifically says it differs from what is actually running.</p> <p>A simplified example is that imagine a virtual machine running called “my_vm”; if the vm name is changed out of band to be “not_my_vm” the next call terraform it would detect this and want to change it as it is not what the specified name should be. The AWS CloudFormation offering this is in the same space, but, Terraform supports AWS, Azure, Google Cloud and many others.</p> <h3 class="wp-block-heading" id="Kubernetes">Kubernetes</h3> <div class="wp-block-image"> <figure class="aligncenter size-large is-resized"><img loading="lazy" decoding="async" src="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/kubernetes-logo.svg" alt="Kubernetes logo." class="wp-image-1698" width="212" height="205"></figure></div> <p>Kubernetes is defined as a scheduler but was does that mean exactly? Meant to be installed across numerous machines Kubernetes provides ‘scheduling’ of jobs across these machines. What this means in practice is that computation can be divided across multiple machines, or more frequently it trivializes having a deployment that is redundantly deployed across many machines, load balanced and even can handle growing or shrinking deployment size based on load.</p> <h3 class="wp-block-heading" id="Helm">Helm</h3> <div class="wp-block-image"> <figure class="aligncenter size-large is-resized"><img loading="lazy" decoding="async" src="https://wordpress.highwaythreesolutions.com/wp-content/uploads/2022/09/helm-horizontal-color.svg" alt="Helm logo" class="wp-image-1699" width="223" height="223"></figure></div> <p>Helm calls itself a package manager for Kubernetes, and while Helm can’t be used without Kubernetes (or one of the other branded alternatives) it is more than just a package manager. With just Kubernetes the configuration of everything needed in a deployment is specified with yaml files. Helm provides a layer of abstraction above that, allowing the use of variables, loops and conditionals in normal Kubernetes files, all of the configuration that was now needlessly duplicated across many Kubernetes files is condensed into one file, which can have smaller files to override needed changes for different environments (for example dev/test/prod values).</p> <p>Imagine the configuration of a url for an application, this may be specified in a couple of spaces across a few files for a single deployment, without Helm those files would all need to be duplicated for dev/test/prod and changed for the corresponding environment. With Helm the process is to simply make a new values/configuration file for each environment replacing the url in one place (on one line in that file).</p> <p>Helm also provides rollout/rollback deployments and only makes the fewest possible changes when a configuration value changes.</p> <h2 class="wp-block-heading" id="Why-(and-When)">Why (and When)</h2> <h3 class="wp-block-heading" id="Terraform.1">Terraform</h3> <p>Terraform is a powerful tool that takes the manual process out of deployments. It’s hard to argue against the use of Terraform when doing infrastructure provisioning. While Terraform does also allow for deployments and configuration of bare metal machines it leaves a lot to be desired where other tools can do the job much more efficiently.</p> <p>Terraform is a good choice when using a cloud provider* and doing anything other than a proof of concept project that might need to be deployed more than once or maintained in a consistent way. Terraform also helps build up modules that can be used across multiple projects and is cloud agnostic in that it doesn’t require learning another language to define resources for that cloud type.</p> <p><em>*There may be instances to choose cloud formation or other proprietary options but that is a topic for another blog post</em></p> <h3 class="wp-block-heading" id="Kubernetes.1">Kubernetes</h3> <p>Kubernetes is one of the harder products to determine when to use it and will be more of a case by case basis.</p> <p>Kubernetes allows a highly reliable, scalable deployment. Docker (or some other containerization) is required for Kubernetes so that overhead should be considered if software isn’t already containerized. The overhead of setting up, maintaining and running a Kubernetes cluster is likely not worth it for small projects or proofs of concept. If the software being developed can have some occasional downtime or if it doesn’t need to support a large volume of traffic then Kubernetes can likely be a skip.</p> <p>However, since one of the only requirements of Kubernetes is containerized code it can easily be moved if the project traffic suddenly does grow, or needs to be more reliable which makes it a perfect option to scale to, and can serve as a container for many different applications.</p> <p>Kubernetes can also seamlessly manage compute resources in different regions under the same cluster which when administered correctly can make load balancing a global facing application an easier task.</p> <h3 class="wp-block-heading" id="Helm.1">Helm</h3> <p>For projects using Kubernetes, Helm should also be utilized. The only downside of Helm is that is requires a slightly higher amount of learning than base Kubernetes (and Kubernetes requires a fair amount) but the advantages far outweigh the downsides. Helm simplifies Yaml with variables and shortens the amount that has to be written with the ability to have loops and helper functions.</p> <div style="height:64px" aria-hidden="true" class="wp-block-spacer"></div> <p>Overall nothing described here will replace existing code without an investment and every project will have it’s own considerations to take into account before choosing any of the tools. Hopefully this has helped to explain some of the tools that are currently leading the way for newer deployments and some of the thought processes we here at Highway Three use before deciding to use one of these tools.</p>