I have been using Terraform for a couple of months now and I am very impressed with it. Its a declarative infrastructure as a code tool that allows you to write, deploy and manage your infrastructure in a sane way while being platform agnostic (looking at you CloudFormation 👀).
Terraform allows you to create your infrastructure with one command, and tear it down completely with another. And that my friends, is where its power is most amazing.
Like many, I started my ventures in Cloud in the console. Clicking away at several screens without fully understanding what I was deploying at first.
Creating an instance and tearing it down felt powerful, but also scary. After deleting resources I realized there were times where some things got left behind. Either I didn’t delete them in the proper order, or some resources were generated in a particular set of clicks that I just failed to remember to reverse. Those things ultimately cost money. Being as cost aware then as I am today, that had me worried.
What if I forgot some resource in an obscure part of my infrastructure and wasn’t wise enough to set budgets? It was hard to keep track of all the clicks I made through the console, all screen I went through. The console changes quite rapidly. New services are added and screens are reworked for UX. It’s part of their job to make things easier for new users.
I heard lots of nightmare stories of colleagues who deployed and forgot, only to be welcomed by lengthy bills at the end of the month. That scared me, as it should.
Cloud grants you a lot of power. And Uncle Ben never lets us forget, with great power comes great responsibility.
I then started playing around with Cloud provider CLIs. That took me to another level. I could now automate, most if not all of what was available on the console.
But still, things didn’t feel right. APIs changed, some endpoints didn’t provide all the context I needed. Securing the state of the infrastructure wasn’t always reliable because I wasn’t always aware of the chain of calls that I did. This felt like a useful tool to have in the toolbox, but something was missing.
Some of my first ventures into Infrastructure as a Code were using CloudFormation. It felt nice, albeit a bit overly complex. It only worked for AWS and I had been using a mix of Cloud providers for quite some time, so although it did solve part of the problem, it was, in the end, an incomplete solution.
I had heard of Terraform, and some stories of it not being mature enough, which was enough to make me stay away from it for a while. What a mistake that was.
My first contact with Terraform was with their own tutorials and guides (which are great by the way) after being introduced by the good folks at CodeCentric who were using it on a project that was being handed over to me.
At the risk of replicating parts of the tutorial here, I am just going to demonstrate how to create a Kubernetes cluster in Google Cloud just to get a taste of how easy this is.
Requisites for this:
- Register for a Google Cloud account.
- Log in -> Create a sample project with a random name -> Left Menu -> IAM & admin -> Service Accounts
- Create a service account with Project Owner Role and a name to identify it (click the check Furnish a new private key). It will download a JSON file. Keep it VERY safe, or delete the service account afterwards. Rename it to account.json.
- Go to Menu -> APIs -> Library
- Enable Kubernetes Engine API
- Go back to the Menu -> Home
- On the top left side you will find a Project ID. Copy that
- Install Terraform
This is an example of a Kubernetes cluster deployment. For this to work you need to have the json you downloaded in the same file as this file (it’s referred here as account.json).
Copy this into a folder together with the account.json file.
On that folder, run:
terraform init
This initialises Terraform and fetches the providers and modules, which in this case is the Google Cloud provider.
Then run:
terraform plan
This will show you which resources terraform will want to create (this does NOT create them).
After you are ready to create them, run:
terraform apply
And confirm the creation of the resources.
You can see the Kubernetes cluster you created in the Kubernetes Engine link in your Hamburger Menu, and then destroy it completely by running:
terraform destroy
Needless to say, after the first terraform apply followed by a terraform destroy, I was hooked.
From instantiating to destroying it, the whole thing took less than 5 minutes, and my console was clean (which isn’t always the case, but that is the subject of another post).
This changes things. I was now able to iterate on infrastructure as quickly as I would on an application. This felt powerful. Hell, this was powerful.
I felt that now I was able to experiment much faster than previously by using the console or CLIs. It was a safer, more reliable way to replicate and document what I was doing. It finally felt like this was the right way to do this.
It finally felt like this was the right way to do this.
I could now commit our infrastructure to versioning control, make it available so my coworkers could review it and it was ultimately a lot of fun to just experiment on several different sets of architecture.
Which leads me back to the subtitle of this post. Trial and Error. Infancy is a very fertile ground for learning in great part due to the lack of restraint regarding failures. A child does not care if it makes a mistake while writing a sentence. It just writes the sentence the way it thinks it’s supposed to be and corrects it in case there is a failure. It doesn’t hesitate to make a move, to explore an avenue of thought. That makes you execute more, hesitate less, and learn more in the process about what is actually happening.
I’ve seen this happen in IT. Some professionals that were a bit too afraid to touch a particular system due to its complexity, or an infrastructure due to not being able to fully rebuild it in case something went wrong. I feel that Terraform changes this landscape for the better since now it makes a lot of things clearer, and builds on top of transparency.
Innovation needs experimentation to flourish.
There are hundreds of ways to solve the same problem, which begs the need for creative solutions (not necessarily complex) for the problems we have today. Innovation needs experimentation to flourish. The whole Lean Startup movement preaches quick experimentation in order to quickly learn the way forward without wasting time on tasks that don’t drive your purpose forward. And to do that without suffering the consequences of a failed experiment is pure gold.
In this case, this means being able to recreate your infrastructure and iterate on it as much as you want. If you want to call it a day, just destroy it and rebuild it the next day with one command. It’s amazing.
No longer was I wary of the Cloud. I now knew that it was much simpler to just experiment with no strings attached since I could just tear it down and iterate on it minutes later. From that moment on, I changed the way I deployed infrastructure (and became a vocal advocate for Terraform).
I was able to learn and get to requirements faster since I wasn’t wasting time hunting down spurious resources. This was to me the most prolific environment I could hope for.
Terraform changed the way I work to a more reliable, audit-able and safe provisioning process. I hope it does the same for you too.