nesting modules: how deep do you go?

[azMantas]

I really like the idea of building solution based on bicep modules. Start with a dummy Azure resource then add one or two smart functions and consume this module in another module... But if I add one more function in next layer... and the story goes on. I can see that possibilities grow together with complexity. But are there any good/bad practises, success story or any technical limitations? (like max 10 nested levels)

[alex-frankel]

There is no technical limitation on the bicep language side. There may be a deployment runtime limitation lingering out there somewhere, but in practice, I have not heard of folks hitting any limits on this.

The main best practice to follow is those of any good software project -- keep files small enough to be maintainable and reusable. If we do our jobs right, you shouldn't need to care how deep you go. That's being optimistic though, I'm sure others have more practical advice on this one.

[brwilkinson]

I have found the layering and nesting of modules to be super useful.

On average I go 3 layers, however I think my maximum is about 6 layers.

One thing I find useful, is to give your Modules meaningful names, since they become deployment names. So you will want to trace them say in the portal (or with PowerShell) as you dig into the layers/deployments. Plus they have to be unique.

I also found that for things like below I want to call them from more than 1 place. I started naming these: x.modulename.bicep

• NIC

• Public IP

• DNS A Record

• File Share or Container

• PrivateLink

  e.g.
  

• As an example I call the public IP x module from all of these.
  

I also have some templates that just generate objects that I use in other places, they don't create resources, so I called them y.name.bicep

• y.disks.bicep
  

Describing the layers

1. orchestration e.g. 01-ALL-RG.bicep - deploy a whole resource group of resources

   • I have feature flags if() to enable or disable some of the stages in this Module (from a parameter file) depending what an environment needs, this stage also runs in my pipelines.
     

2. The main resource layer, always take an array of X type resources e.g.

   • StorageAccounts
   • CosmosDB
   • Website

   I name this file with the shortest name, since these are the ones i actually call to deploy (i.e. layer 1 or 2), this also gets called from layer 1 but I can call it directly as well.
   
   

3. By this layer I am deploying a single X resource such as a single storage account or Cosmos DB.
   

4 and 5) Etc are just nested properties of that resources.

• Resource properties
  
  

  • sometimes I create resources there or sometimes just do nested variables loops then retrieve that a layer up via outputs.

I have found this all works great with no complaints.

I don't nest if I don't have to, just for the sake of it, e.g. I start building layer 2, that iterates over a single resource type, then when I get stuck, I call the nested layer as needed. I have some templates that are just layer 1 and 2. Usually as i extend functionality they often turn into more layers over time.

This is actually the same method I used with ARM templates, I never changed any of my parameter files when I converted over (also they are backwards compatible with my ARM templates, however I am archiving the ARM templates). I have found SIGNIFICANT ways to cleanup and streamline things since moving to Bicep, which I think is obvious. Also since I always used this model anyway, Modules just match up exactly what I was already familiar with.

[azMantas]

as I understand you refencing bicep modules to read data from 'master' config file ?

[brwilkinson]

I do put some Global settings in specific global/master files, however that it not the main point of the current design.

The main point is to have a single parameter file that maps directly to an Environment/Resource Group.

• All resources for that environment are in that single parameter file.