Jam Notes #2: Terraform Templates

1. What makes a good Terraform template?

  • It should be well-laid out, with comments to let you know what’s happening
  • Separate the Terraform template by modules, so that different components can be worked on by different teams — this enables easier and faster collaboration across teams

2. What are common mistakes in Terraform templates?

  • Don’t put all your eggs in one basket by building a single Terraform template. Yes, it’s easier to write a single file, everything from a single repository for convenience, but if you make a mistake and you need to run the Terraform destroy command, you’ll take down the entire infrastructure (and end up taking down things you don’t want to)
  • Not separating persistent from non-persistent data. Always separate your persistent data from non-persistent data (things that can’t ever be deleted versus things that can be deleted)
  • Failing to treat Infrastructure as Code (IaC) as code. It is code, so put it in a repo, create tests where you can, and use it in a pipeline

3. What are Terraform templates best practices?

  • Apply modules when writing templates so you don’t put everything in one template
  • Be parameter agnostic
  • Build a TF template whenever you need to do anything twice
  • If you can automate it, you should. No infrastructure is too small to automate. Codify everything, everything is an API
  • KISS (Keep It Simple Stupid):
  • Don’t go overboard in building Terraform templates — It can be tempting to think, “oh what if down the road we need this” — but focus on what you need
  • Don’t reinvent the wheel for something that doesn’t yet exist
  • Spend your time wisely, do what you need to do, don’t add in too much, don’t make your Terraform templates so complex that you’re dealing with 2,000 lines of code per module. Time is money, so don’t make it complex to deploy
  • If you make it complex with layer upon layer and someone else has to maintain it, they’ll be knocking at your door asking why you did it this way

4. Who builds the Terraform templates in an organization and who customizes them?

  • Depending on the size of the organization, IaC is built, customized and maintained by small DevOps teams… (Think of the 2 pizza teams rule = individual teams shouldn’t be larger than what two pizzas can feed) to maintain a specific service
  • In large organizations, they practice Cloud Center of Excellence where the architects build out the building blocks and individual DevOps teams customizes and maintains the Terraform templates

5. What are small to medium-size organization best practices?

  • Have a central repository where the code lives — people commit their code and know where to find, edit and deploy it. Could simply be a git repo
  • Don’t host your code on file share

6. What are documentation best practices?

  • Any code you write should be readable
  • IaC is self-writing documentation
  • Someone should be able to look at your module and read it as a book and pull it apart and understand what it is
  • IaC is also self-evolving documentation

7. How can you make code understandable for non-technical people?

  • You don’t have to know code, you just need to learn how to read it
  • Dropbox or Atlassian tools for maintaining documentation

8. How do software developers who don’t know about cloud know how to use the Terraform templates?

  • You need to get educated on what the templates are for
  • In most scenarios, you use the commands Terraform plan and apply
  • But, if you want your development team to deploy a change for infrastructure, you want them to do it through a proper CI/CD pipeline, not through Terraform plan and apply (this is a critical point)
  • GitOps methodology for IaC developer side is super important
  • Tooling in the background that will recognize changes and deploy that change to an environment
  • Configuration management tools that will deploy that code without developers struggling with the existing infrastructure

9. What are strategies to deploy Terraform templates to different environments?

  • Apply the GitOps methodology → this is more of a developer mentality where you have your infrastructure configured in the background (templates and pipelines are all setup), you commit the code and things work in the background
  • When it comes to production, if you’re doing less releases per cycle, doing it manually is not bad. This is a scenario where everything else in between is automated but the final step is done manually. This also gives you time to do A/B testing
  • Pipelines orchestrate workflows towards staging, development, or production
  • Create different tfvar files for different Terraform templates (pick and choose which template you want for specific environments)

Final pieces of advice:

Darko: Start using Infrastructure as Code, do it early and often



Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store