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.
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 may assume developers are using the module to standardize, but how can you track or enforce that?
If they are using it, do you know they are using the right version to avoid conflicts?
Are you certain that if you make an update to the module it won’t impact their existing Terraform deployment?
Do they know when new versions are released or when old versions are deprecated?
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.
Module Registry to the Rescue
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:
Create a list of approved modules
Create versions of the modules to allow users to pin
Deprecate old modules
Avoid impacting existing deployments through the versioning
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?
Hierarchical Inheritance Module Registry
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:
Global scope: If created here, all organizations and environments will inherit the module.
Organizational scope: All environments within the organization inherit the module.
Environment scope: That environment is the only place the module can be used.
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: