top of page

Recent Posts

Archive

Tags

Terraform Part 1: ARM vs Terraform

This post is part of a short Terraform series which will take you through some of my learning about Terraform with examples. Many Microsoft fans such as myself resisted Terraform for quite some time, extolling the virtues of the native capabilities of ARM templates. Terraform, however, has gained so much momentum that not even the most staunch ARM template supporter can avoid learning how to work with it. I began working with Terraform templates recently and I wanted to share my thoughts below. I hope that this helps ease your transition into Terraform. Infrastructure-as-Code, no matter what tool you use is a powerful tool for any organization. It allows teams of people to define exactly what is needed once and deploy many times. Rather than chancing an important networking configuration, let's say, on human input an organization can be confident in the ability to deploy only their chosen settings the right time, every time. Both ARM templates and Terraform are powerful tools that are up to this task and both perform very well. While I have a plethora of experience and confidence in ARM templates, getting out of my comfort zone to try Terraform allows me to meet many customers where they are and enable their success in Azure. Terraform is an infrastructure-as-code templating language written in HashiCorp Configuration Language (HCL), an open source domain specific language. Terraform is cloud-agnostic. There are several providers for Azure, AWS, GCP and others. The source code is written in Go and you can find the repository here. Cloud-agnosticism and the ability to import resource state are two of Terraform's more powerful abilities. The resource state must be maintained however. If there are changes that are made without Terraform then the state file will have to be resolved. For customers, the language may be easier to read and work with than JSON and I can completely understand that. I am used to working with JSON but understand that it can be…verbose and difficult to look at day after day during development. Simple things like the use of an '=' sign make the key-value pairing easier to read and understand. The resource blocks are simpler as well, and you only need to define what you need in the resources rather than defining dependencies, types, API versions, etc. I work with Terraform extension in VSCode and use a formatter like Prettier to make sure everything lines up nicely. One of the largest drawbacks to Terraform early on was lack of resource parity with ARM templates but this has largely been addressed as, currently, it can deploy almost anything an ARM template can deploy. There are, however, some inconsistencies such as the open issue here. It seems these problems are resource specific as function apps do not have this issue, yet web apps clearly do. One of the perhaps lesser appreciated aspects of using Terraform is the clear documentation that includes plenty of examples. I applaud HashiCorp on this front as poor documentation can make or break a new technological experience for me personally. You are able to drill into cloud provider and the family of resources (Compute, Networking, etc) through the easy-to-navigate website on their registry page, registry.terraform.io There are a short series of steps to deploying a Terraform template that ensure that there is no ambiguity in the deployment. The plan phase of deploying a Terraform template list out a plan that details what will be done with the apply command (create, change, or delete) which is incredibly helpful when deploying complex infrastructure. While this functionality is possible with ARM Templates, you have to use Azure PowerShell or the Azure CLI in order to display it. Terraform allows you to confirm the changes that will occur in a single pane of glass. Terraform includes the use of state file. The state file contains a mapping between configuration objects and the resources in the cloud. There must be a correct mapping and if resources are created outside of Terraform, then they will have to be imported and you will have to inspect the state file to ensure that each imported resource maps to a configuration object. Terraform may have unexpected behavior with the plan command if state is not updated. The state file is created locally by default but remote state is also an option if working with a team. One thing that I noticed is that you can create service principals in Terraform. This requires the use of their AzureAD module but this is not currently possible with ARM templates and is a valuable resource. App Registrations in Azure Active Directory often require service principals as well as secrets and being able to automate this process is not only handy but more secure than manually creating them. All in all, I believe Terraform fulfills a need for organizations to go multi-cloud easily and with minimal tooling. It simplifies the deployment process while including useful tools for planning infrastructure deployment. While I still enjoy working with ARM templates, Terraform has been interesting to try and I am glad I took some time to learn it. I hope you will also give it a try. You can easily get started by going here. See Part 2 of this series for a peek into how I worked with Terraform for the first time and part 3 for how I transpose ARM templates to Terraform

Commentaires


Single post: Blog_Single_Post_Widget

Follow

  • LinkedIn

©2018 by Jennifer Morris

bottom of page