Written by Nathan Bennett, Cloud Architect, Sterling
terraform: verb, (especially, science fiction) transform a planet so that it resembles the earth, so as to support human life.
cloud: noun, a mass of water vapor floating high above the earth.
When you look at these two definitions, do you see opposites? You would be correct. Terraform is all about the earth or “making” an earth to support human life. Clouds are nothing more than vapor. They can neither support humans, nor can they be created into something different. Or can they? HashiCorps Terraform allows companies to deploy their own environment into the Cloud. This leads to different definitions. For one, Terraform is a codebase and a solution provided by a company; and second, a public Cloud is just using someone else’s computer.
Even in light of these definitions, I see Terraform as the Language of the Clouds.
I’ve had many discussions with individuals about the big three public Clouds; Azure, Google Cloud Platform (GCP), and Amazon Web Services (AWS), but one day, something was made abundantly clear to me. I do not see these as different platforms. To me, they are different endpoints.
The way I view the Cloud is through the lens of a tool that allows me to deploy my infrastructure the same way every time. In Azure, I use Terraform; in GCP, Terraform; in AWS, Terraform. Even in networking configurations and hypervisors such as vSphere: Terraform.
“Which is your favorite GUI (Graphic User Interface) to use in the cloud?” One individual asked me. My face was blank as I stared into my webcam. “GUI?…. I see the Cloud through Terraform. So, to me, it’s all resource blocks, data blocks, and provisioners. They aren’t that different. Just different blocks.”
Azure Terraform Manifest
What my answer shows is the versatility of Terraform. Anyone who looks at GCPs, GUIs, and an AWS’ GUI cannot intuitively transfer knowledge from one to the other. They are set up to be as proprietary as they can be. Some similarities exist between them, but how you interact with them can be quite different. Each Cloud has storage, compute, and networking, but how those functions interact within the Cloud is different. My goal here is not to say which Cloud is better. The goal is to introduce you to Terraform 1.0, which was recently announced by HashiCorp. Terraform has been around for a long time.
Here, we have HashiCorp’s requirements for a 1.0 release:
- The project is deployed broadly and has years of production-hardening.
- Major use cases are understood and well supported.
- User experience of the project is well defined.
- Technical architecture is stable and mature.
All of these have been achieved and exceeded with Terraform. In fact, Terraform was more well-known than HashiCorp in my experience. Sure, Vault is amazing and a powerful tool for secrets management — programmatically retrieving, using and rotating secrets — but Terraform itself lends power to businesses, operators, and individuals looking for quick ways to build environments. It sounds barbaric to add to this sentence the idea of destroying the whole environment as well, but that’s the goal of Terraform. (These machines are not pets that need care and feeding, but, more like paper cups that have a limited use, can — and should — be disposed of.)
AWS Terraform Manifest
Since its launch in 2014, Terraform came bounding onto the market allowing users to spin up environments from 0 into full production. It quickly became the industry leader in Infrastructure-as-Code (IaC) and may have even defined it. I’ll go into IaC a little more in a different blog to show its use cases, but Terraform’s way of deploying IaC allowed operators to deploy full infrastructure stack and Cloud services. Terraform utilizes “Providers,” which are filters that define what each block within Terraform will perform, build, and adjust. Terraform’s first Provider was AWS and is still one of the best out there. Today, Terraform has over 450 providers with companies like Azure, GCP, VMware, Cisco, Fortigate, etc. Each provider can be either a HashiCorp provider (which has HashiCorp support), Vendor Provider, or Community Provider. Each is useful in deploying the needed solutions, but the operator would need to be very specific on how each is deployed and how they use it from day to day.
Google Cloud Platform Terraform Manifest
This leads me to my last thought here. I was recently asked an intriguing question: “Should businesses use beta software?” In the world of Terraform, the answer is a resounding “’Depends.” I jest, but Terraform is an anomaly — that is, the value of using it far outweighed any ‘beta’ quirks. The main reason for the exception is that HashiCorp supported Terraform before its 1.0 release; whereas, in most betas, you’re on your own in terms of support.
Terraform’s versatility changed the way we see the Cloud. It allowed multi-cloud to become so easy to reach. Instead of going to a different country with a different language, and a different process, Terraform unites languages and processes, as if it were a United Nations of the Cloud. Indeed, it transforms “Clouds” into habitable environment, where environments can be built, managed, and grown.
At Sterling we understand the struggles of figuring out the Cloud. Our architects and engineers are ready to help you navigate through the maze of what each Cloud can do for your business, but more importantly, which Cloud is right for you. If you are dealing with “Shadow IT” (unknown IT resources) and need to bring multiple Cloud environments under the umbrella of a single organization, let us know. We would be happy to show you how tools such as Terraform can transform your business and allow everyone to play off the same sheet of music.