Terraform modules are a great way to simplify your Terraform code by writing it once and then reusing the modules in your templates. The module can contain a single resource or multiple resources with the result being a standard way of deploying infrastructure across your cloud ecosystem.
Create the module:
Use the module in your templates:
Creating and using the module is the first step to simplification and standardization, but how scalable is it?
So you have created your module, you told your developers to use it and management of your Terraform code has become much simpler, but has it?
You could build or develop a way to control the management of the module, but this will potentially require more work for you with peer reviews. Many teams also implement the idea of a monolithic repository which holds all of the modules, which is an easy way to reference them in code, but introduces issues around dependencies, ownership, unwanted changes and more.
If you are using modules across multiple teams these challenges will become very real, very quickly. The more modules you use and developers you have the bigger the problem. Users will always push for more modules and more services, but in the current state it will be hard to keep track of what you have and who is using it.
If these challenges apply to you then you would likely benefit from the Scalr Infrastructure as Code Platform module registry. The registry allows you to:
Scalr allows you to store your modules in VCS, tag the module with a version, and then import it into Scalr for your users to view. The person writing the Terraform template simply needs to copy the code block from Scalr and will be aware of what version to use through the README that is imported as well.
A module registry greatly simplifies the management of modules, but what if it could be even easier?
Scalr has created a hierarchical inheritance module registry to save the administrator from an operations headache. The last thing you want is for teams to step on each others feet when deploying, in Scalr you can create environments and organizations to give each team or app its own dedicated space to manage their deployments or workspaces. It would be a real pain to have to go into every single environment and/or organization to import the module, which is where the hierarchical inheritance model comes into play:
A module registry can be created at each level in the diagram above:
Create and maintain the module in one place and share with many organizations, teams, and environments. This allows you to create organizational standards, but also lets your individual teams add more modules at their respective scope if their permissions allow for it, but not change or remove modules from a higher scope. Introducing the hierarchy starts to enforce policy on modules, but can be taken even further with the Open Policy Agent integration.
With the Scalr hierarchical module registry you can easily and safely manage modules going forward. Scalr is the only solution that provides the various levels to reduce the operational overhead, while giving you the following benefits :