Terraform Abstraction Tips: Just Because You Can Doesn't Mean You Should

Learn how to think about balancing automation and abstraction against maintainability when building your Terraform setup.

Reducing manual effort by building automation or abstractions to ease Terraform workflows is usually a good thing. But how far down the rabbit hole should you go for your teams and use cases? These days we see platform teams trying to build CI/CD pipelines to manage all your CI/CD pipelines and expose a interface to developers where you can deploy with just 3 lines of YAML.

It sounds amazing, but building abstraction layer on top of abstraction layer without a good idea of what errors might emerge is a recipe for frequent bugs and difficult maintainability.

Terraform has so many opportunities for abstraction: modules, wrappers, and orchestration tools, all allowing for increasingly more sophisticated code - so where do you draw the line? What are the trade-offs?

What You’ll Learn

In this hallway track, Natalie Godec, cloud engineer at Babylon will explore the boundaries of infrastructure as code and look for the balance between abstraction and maintainability.

Risks of Terraform Abstraction

  • Dependency loops

  • State drift 

  • Inconsistency

  • Security holes

  • “Off road” implementations

Complex Configuration

Here are some things you should try to avoid when building Terraform configurations and modules to avoid making them overly complex and brittle:

  • Having “everything but the kitchen sink” in one module

  • Attempting to abstract every use case

  • Having transformations and conditions everywhere

Terraform is Declarative

Terraform is a state engine built to read HCL, a declarative DSL. With the greater freedom that came in Terraform 0.12 and later versions, users are now able to use functions, operators, for loops, and more. This means you can create procedural flows in Terraform that don’t follow the principles of declarative usage, which can clash with Terraform’s processes since it was built to be declarative.

Here are a few other elements you need to be careful with when using in Terraform:

  • Local execs

  • VPC peering

  • Kubernetes services: EKS, AKS, GKE

All-in-One States

Another risk is all-in-one states, for example:

  • All DBs in one state

  • All IAM roles and policies together

  • Targeted Deployments

Safer Practices

Single points of deployment are one way to improve maintainability of your Terraform workflows. Here are some ways to divide your configuration into single points of deployment.

  • All the infrastructure needed for a service

  • A group of resources used by a single team

  • Standalone, complex infrastructure

Get more details in the session recording.

More resources like this one