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.
