Photo by Valery Fedotov on Unsplash

From Terralith to Terraservice with Terraform

This is the first article, of a three-episode series on Terragrunt and Terraspace.

Episode 1: From Terralith to Terraservice with Terraform
Episode 2: Terragrunt cheat sheet
Episode 3: Terraspace cheat sheet

All those tools may be used to define your Infrastructure as a Code (IaaC) trying to apply the DRY pattern.

Pre-requisites: Basic understanding of the main Terraform concepts.

Which is the symptom?

The infrastructure becomes more complex and you need
to figure out from these requirements:

• Multi-region,
• Multi-environment,
• Multi-account.

The 3 “Multi-” pattern.

There are multiple ways to manage the IaaC when complexity increase.
The evolution of a Terraform project to manage multiple patterns is composed of steps, new features, and experiences that can bring you high.

In terms of complexity, a typical terraform project evolves through these 5 patterns. Since we want to be DRY [please have a look at this great presentation] for an in-depth analysis of them.

Here’s a quick summary:

1. Terralith: Single state file, Single definition file, Hardcoded config, Local state. In two words: All together!
2. Multi Terralith: Remote state, Multiple terraform files, Better use of variables →1:1 tfState-environment.
3. Terramod: Reusable modules interconnected with Env variables, Separate Env management → 1:1 tfState-environment
4. Power(Terramod, n): Nested modules (Base[infra]+ system-specific), dedicated module repo → 1:1 tfState-environment
5. Terraservice:

• Independent management of logical components: Isolates & Reduces Risk
• Multi-Team Setup
• Distributed (Remote State): N:1=tfState:environment
• Requires additional orchestration effort
• Repository Isolation between environments

Photo by Annie Spratt on Unsplash

Now you have at least two choices to manage the “Terraservice” scenario:

1. Invest some time in a custom script and pipelines and solve all the requirements.
2. Start learning Terragrunt, Terraspace and compare them.

What I’m gonna explain is the second option

Let’s list the key requirements and the reasons that we would like to solve in the Terraservice scenario:

• DRY— But I prefer a trade-off on it.
  Sometimes repeat yourself introduce some clarity.
• An organized structure between account, env, region, service.
• Multiple state files in the same account, with auto Backend Provisioning. Instead of having a single huge state file, split it!
• Manage multiple regions in the same account.
• Work simultaneously between teams.
  When the team increase, you need to increase the parallelism to decrease the conflicts.
• Layering over TFvars (base.tfvars merged with specific env staging.tfvars).
  Don’t repeat all the variables. Copy-paste could be a serious problem!
• Dependency “management” between modules.
  Maintain a low interconnection between modules can decrease the number of headaches.
• Hooks to run after and before commands.
• Single command to plan/apply all.
  Take care with the “apply all” command provided by the two frameworks.
• Not increase the overhead too much.
  Few people want to learn a new programming language for this.

What do you think about this list?

In the next post, I’m going to show with a real example how you can solve the major part of these requirements with Terragrunt and Terraspace.

Follow Me and Subscribe to get the updates on this and the next series!

Photo by Omar Flores on Unsplash

References:

[1] https://www.hashicorp.com/resources