Infrastructure as Code : Can I be your super hero

How We Organize Terraform Code at 2nd Watch - 2nd Watch

In this blog post, we’ll go over how we structure our IaC repositories at 2nd Watch with a particular focus on Terraform, an open-source tool by Hashicorp for provisioning infrastructure across multiple cloud providers with a single interface.

2nd Watch

Terraform best practices for beginners

Getting started with Terraform takes some effort to read the documentation. To give you a head start, we’ve compiled a quick list of Terraform best practices.

UpCloud

The days when we bought equipment to build servers as come to an end and is being replace with the cloud. It's now easier than ever to commission infrastructure but the end result is not always what we would expect.

Picture's credit to Roberto Barrios

This cable management is probably doing the job but the maintenability is a damn challenge.

Maintenability

Applying changes by hand is a hard way to avoid mistakes and ensuring that all environments are excalty configured the same way. The more your projects grows, the harder it is the make changes without impacts.

At first, a manual change could be seens as a quick fix or giving you a boost in productivity but in the long run, it's all hell let loose. What if you don't have to the time to code the modification and want to bypass this step?

You should maintain a unique workflow
Scripting your infrastructure will give you a massive advantage, a state.

Versionning

Let's say you used the graphical user interface of your cloud provider to create a brand new virtual network and then have configured all your services to use it. Your changes get tested and are refused. How do you revert the moodifications?

The state management comes defacto with the use of a source control to version your infrastructure. You will have full visibility of what changed over time and by who, thus giving you the possibility to rollback to any state.

Fast

After having deployed your first infrastructure with code, this is probably the first word you will have in mind, "Fast". Because of it, you will gain agility by behing able to spin up environments. Once your done, you can shut them down to reduce expenses.

Cost

As everything is automated, so cost can be optimised. For example, we can deploy new ressources when creating a pull request. The QA then test the newly created environment and apply his seal of approval or refusal.

Then the PR is merged or closed so the associated environment is destroyed. This gives a lot of flexibility for testing. No need to pay for a limited and static set of environments. You can scale as you go.

Consistency

With scripts, you can be assured that all your environments will be identical.

Simplicity

Deploying the whole infrastructure is as hard as writing down the parameters and executing the script.
- You have to ask yourself : "What happends in case of a disaster?" "How much work is needed to spin up the infrasctructure back online and how much time will it take?"
Reusability of the code
Minimization of risk
- I would be terrified if a single humain mistake could completely freeze the compagnie and not knowing what has been changed so we can revert it.
- The documentation is the code so this reduce the learning path for new employes.
Governance and control
- Workflows can be enforced to allow ressources to ask for modifications but only the owners of the infrastructure can review accept and deploy thoses changes.

Infrastructure as Code has so much to offer to overcome this fact :

Every time you make a change to an infrastructure manually, you contribute to it's instability.

Photo's credit