One module per repo?

Terraform
1

Hi,
I am new terraform, and trying to setup private modules.
what is recommended approach to setting up repo’s for module ?
should it be one module per repo ?
if that is the case then let say if I have 100’s of modules then ill be managing 100’s of repos ?

2

Hi @vinodhum,

This isn’t a question that can be answered generally, because the answer depends on some tradeoffs. Instead, I’m going to try to list some of the things to think about when making the decision, although I’m probably going to miss some things because I don’t know details about how your team works.

  • Will a particular module be called by many configurations that are not thematically related? If so, keeping it in a separate module may be preferable, similarly to how you might keep a generic shared library separate from the applications that use it.
  • Do you have a family of modules that are all coupled together either functionally or conceptually, and are therefore likely to all change together when the requirements change? If so, keeping at least that family of modules together in one repository might make your life easier. (This is a Terraform-specific application of the principle that it’s better to keep things that change together in the same repository, and split things that typically change independently.)
  • Are you using modules as an organizational tool rather than as a reuse tool? If you’ve split something out into a sub-module mainly because the calling module was getting quite large and so it felt useful to decompose it, but that sub-module is still intended only for use in the context of its original caller, then it can be fine to keep it in another directory in the same repository as its caller. (A modules/module-name directory under the calling module is the documented idiom for this sort of module that is coupled to its parent.)
  • Does your broader engineering team already follow a “monorepo” approach for code outside of the infrastructure realm? If so, you might prefer to go with the flow and add your Terraform modules alongside the other code so that teams can follow the workflows they are comfortable with and enjoy the same benefits that attracted them to using monorepo style in the first place.
  • Are you really going to have hundreds of modules? I don’t know how big your organization is and how much infrastructure you are managing, but if you’re talking about a standard that will apply throughout a large and complex organization then I expect you’ll end up wanting to decompose the problem in more granular chunks built from smaller sub-modules, in which case perhaps you’ll have one repository per “big problem” that contains a family of related modules. If you’re working at a smaller organization that has one main product and all of the infrastructure is in service of that product, I wouldn’t expect to decompose the problem enough to have hundreds of modules.

I hope that helps! Once you’ve thought through this tradeoffs, it’d be helpful if you could describe what you decided here and what problem-specific information led you there, as an example for those who might find this topic in future.