Terraform Best Practices with Atmos
These are some of the best practices we recommend when using Terraform with Atmos. They are opinionated and based on our experience working with Terraform and Atmos. When followed, they lead to more reusable and maintainable infrastructure as code.
Physics is the law, everything else is a recommendation. Anyone can break laws created by people, but I have yet to see anyone break the laws of physics.
Also, since Terraform "root modules" are components, be sure to review the Component Best Practices for additional guidance on using components with Atmos.
Cloud Posse publishes their general Terraform Best Practices, which are more general and not specific to Atmos.
Never Include Components Inside of Other Components
We do not recommend consuming one terraform component inside of another as that would defeat the purpose; each component is intended to be a loosely coupled unit of IaC with its own lifecycle.
Furthermore, since components define a state backend and providers, it's not advisable to call one root module from another root module. As only the stack backend of the first root module will be used, leading to unpredictable results.
Use Terraform Overrides to Extend ("Monkey Patch") Vendored Components
When you need to extend a component, we recommend using Terraform Overrides. It's essentially a Terraform-native way of Monkey Patching. This way, you can maintain the original component as a dependency and only override the parts you need to change.
Use this technique cautiously because your overrides may break if the upstream interfaces change. There’s no contract that an upstream component will remain the same.
To gain a deeper understanding of how this works, you have to understand how Terraform overrides work, and then it will make sense how vendoring with Atmos can be used to extend components.
Comparison to Other Languages or Frameworks
Swizzling
In Objective-C and Swift-UI, swizzling is the method of changing the implementation of an existing selector.
In Docusaurus, swizzling a component means providing an alternative implementation that takes precedence over the component provided by the theme.
Monkey Patching
You can think of it also like Monkey Patching in Ruby or React components, enabling you to override the default implementation. Gatsby has a similar concept called theme shadowing.