Ever wanted to learn Kubernetes? Serverless? Write some Microservices in AWS or GCP? Awesome… But don’t. Or at least, not yet. Why? Because the first thing you should learn is Terraform. Don’t touch Serverless. Definitely don’t touch Kubernetes, and I’d probably not even bother creating an AWS S3 bucket.
There are many reasons for you to be excited to learn Cloud Engineering as a whole. But no other decision impacted my ability to learn Cloud Engineering than: first learning Infrastructure As Code. In hindsight, I wish I did it sooner.
In todays article I’ll try (and hopefully successfully) to convince you why Infrastructure As Code is the most logical starting point for learning Cloud Engineering concepts and tools.
By the end of the article you’ll know what Infrastructure As Code (with Terraform) is and I’ll give you 5 reasons why Terraform should be your starting skill when learning Cloud Engineering.
What is Infrastructure As Code (And Terraform)?
First of all, Infrastructure As Code is the practice of writing your infrastructure i.e web servers, load balancers, databases through version controlled scripts (read: code). There are many generic advantages to Infrastructure As Code. But today I want to talk specifically about why Infrastructure As Code is a logical first step prior to learning Cloud Engineering.
And what is Terraform? Terraform is a third party tool that allows us to write the aforementioned Infrastructure As Code, but we’ll talk a little more about why Terraform kicks ass later.
Importantly though, Terraform is a declarative Infrastructure As Code tool, which means that creating, updating and deleting resources is easy with Terraform. These workflows (create, update and delete) are are a first class concept in Terraform, unlike other Infrastructure As Code methods such as ad-hoc scripting (i.e with the AWS SDK). Don’t worry too much about what declarative Infrastructure As Code means, we’ll cover it in more detail soon enough.
If you want to know more about these concepts, I’d suggest you check out: Infrastructure As Code: A Quick And Simple Explanation., Declarative vs. Imperative Infrastructure As Code and Learn The 6 Fundamentals Of Terraform — In Less Than 20 Minutes.
Infrastructure: Is It So Hard?
So now we know what Infrastructure As Code is, how can it help us learn Cloud Engineering? Let’s start with a Tweet that I recently saw from Cory House (@housecor).
In contrast, DevOps interests me. But I avoid it.
It typically has a slow feedback loop and low control.
Change is risky = approvals required.
I’m effected by cloud issues I can’t control.
The environment may go down at any time. And when it does, it’s my problem.
— Cory House (@housecor) October 6, 2019
Firstly I should say that I really like Cory, and his work — but on this topic I think Cory is wrong. “DevOps” may have slow feedback loops in ways that are too big to discuss today. But I don’t think “DevOps” is inherently slower than other types of engineering, you just need the right setup. And I think by using Terraform you can get a correct setup that makes feedback loops fast, and ultimately makes your learning quicker.
So — without further ado — let’s discuss the five reasons Infrastructure As Code should be your first step to learning Cloud Engineering.
Reason 1: Faster Feedback Loops With Terraform Plan
Terraform Plan
As Cory said, when it comes to learning or implementing technology it’s important that we can experiment easily. We want to be able to update code and instantly see the results of what we did, so that we know whether we’re right, or wrong and where we need to course correct.
And in the web development world, we get fast feedback through techniques such as TDD. We write the test first, leave it running and then write the code to match the tests. Tests help us work through our problems piece-by-piece, ensuring that we haven’t broken anything along the way. And an iterative approach can take away some serious headaches.
When you write your infrastructure-as-code with Terraform, you’re going through the same TDD loop. Except, in Terraform, we execute the feedback loop by running a command called terraform plan. A Terraform plan is a dry-run command that outputs a so called “execution plan”. An execution plan simply tells you what is going to happen when you run your Infrastructure As Code script. What will be destroyed? What will be created? Or what will be updated?
If you know your target state, similar to a test in TDD, you can easily tinker with your Terraform code until the terraform plan returns as you expected. If you missed required fields, Terraform will tell you, if you made a syntax error, Terraform will tell you. All of these bits of early feedback contribute to the fast feedback loops that help reduce the friction and frustration of learning.
When we contrast the speed and repeatability of running Terraform and Infrastructure As Code versus poking around in interfaces making changes manually… Terraform wins. Hands down.
Reason 2: Easy Roll Back
Versioned Terraform State Files
The next reason that Infrastructure As Code helps you to learn Cloud Engineering is through easy rollbacks.
When your code is written entirely in version control, you can easily step forward or backwards through changes. Let’s say you accidentally created a resource you didn’t mean to, simply delete the resource and re-run Terraform. Terraform will then destroy that resource for you. As long as you’re committing frequently you’re going to always have a history of changes that you can easily rollback to.
Compare automated Infrastructure As Code rollbacks with Terraform against trying to rollback changes manually by hand and… Yeah. Rolling back manually configured changes can be a nightmare. And we really want to avoid nightmares when we’re learning.
Reason 3: Less Worry About Cost
One big cause of stress for me when I learn cloud engineering is cost. I’ve even been burnt badly and had an $3000 dollar bill due to my own negligence. Ouch.
My $3000 AWS bill
I got this particular bill because I misconfigured the AWS account I was working on. The misconfiguration lead to my account getting hacked. Resources were created that didn’t belong to me, leading to a huge bill, and a serious pain-in-the-ass. If I had written my infrastructure properly (as code) in the first place the issue likely wouldn’t have come about. Writing Infrastructure by hand leaves you vulnerable to these types of threats. You don’t want a heart-attack-inducing-email bill like this, trust me.
Secondly, when your code is in Infrastructure As Code you can easily tear down all the resources that you’ve created, you have a reference to them after all. Also, remember that before I mentioned Terraform being declarative? Declarative Infrastructure As Code you simply declare the end state and Terraform works out how to get you there. In this case, the end state is: No state. Delete everything. And because Terraform’s state file tracks all our resources we can easily declare that we want to delete everything. All we need to do is run terraform destroy.
Again, as compared with frantically clicking through AWS trying to find resources to kill, running a simple command to tear down all your resources is a no-brainer. Notice the service you spun up is costing more than you expected? Kill it. Easy.
Reason 4: Working Across Clouds
And now onto a point specifically about Terraform, rather than Infrastructure As Code as a whole. A big draw for working with Terraform is that it’s a third-party tool. Unlike other tools like CloudFormation, which are heavily coupled to a cloud provider (in this case, AWS).
Because of the way Terraform is written, it has a core library which is extended by use of a feature called Providers. A provider is essentially a third-party plugin that allows you to use Terraform with a new, or any tool. Terraform has providers for GCP, Azure, AWS and also other cloud tools you might not think about, like Auth0, Stripe. Anyone can (and they do!) write a new Provider and share it with the Terraform community. Which means you’re not stuck working with only one Cloud Provider.
And another big advantage to the third-party tooling of Terraform is that once you learn the technology once, it works seamlessly with the other cloud providers, such as GCP. So if you suddenly decide you want/need to start learning GCP, you don’t need to re-learn Infrastructure As Code tooling.
Poking around provisioning Cloud resources via an interface quickly makes you dependent on the interface. Learn how to script resources by Infrastructure As Code and you increase the mobility of your skills between Cloud services. Win.
Reason 5: Out of the box modules
The Terraform Registry
And last but not least, another reason to use Terraform to learn cloud is: Re-using Modules. If you’re not up-to-speed on what a Terraform module is, I’d suggest this article on: Terraform Modules: A Guide To Maintainable Infrastructure As Code.
But the short definition is: A Terraform module encapsulates related infrastructure into a neat, re-usable and shareable component. Modules can be used to reduce repeated code in your own Infrastructure As Code. But, importantly for us, we can leverage modules that have been created by the community! Using Terraform Modules can drastically reduce the amount of time it takes to get up and running playing with a new cloud tool.
So You’re Gonna Learn Terraform, Right?
Hopefully I did a decent job of convincing you why Infrastructure As Code, or more specifically: Terraform makes sense to learn before you learn Cloud Engineering. I know that in your haste you just want to dive in, but if you take this (brief, I promise!) step by you’ll drastically reduce the headaches you experience when wrestling with manually created Infrastructure.
If I did convince you, and you do want to get started right away I wrote an opinionated, step-by-step guide on how you can bootstrap an AWS account with Terraform (and a versioned backend) so you can start experimenting. To get your hands on the resource, all you have to do is sign up to the Cloud Native Software Engineering Newsletter.
Learning Cloud Engineering is super fun, and I want to see more engineers getting involved, and I think getting literate with Infrastructure As Code is the best way to do it. Dive in, and let me know how you get on!
- 2023 Summary: Data Driven Stories About The Cloud - December 31, 2023
- 2022 Summary: The Open Up The Cloud System - January 1, 2023
- Open Up The Cloud Newsletter #30 (January Recap 2022) - March 1, 2022