Azure
Add documentation to qualify the comments on 'Anti-patterns' in module design
We should describe or document a design decision with rationale and reasoning on our module design, assuring we address the 'anti-pattern' comment on:
Paraphrasing A module should never only deploy a single resource.
We should describe how our modules are rigged to deploy a single parent resource + its extensions, and tightly connected resources.
Document reasons we have single "resource" declarations in separate bicep files:
- [x] Deploy multiple instances via loops (nested loops)
- [x] Deployments happen on a different scope
Suggestions to where this doc could be:
- [ ] an FAQ page
- [x] the module design page
We still do not clearly state why we deploy single main resources with our modules. We define our modules as "building blocks" without stating clearly what we mean. A single module deployment of a CARML module = one resource with all its extensibility and child resources available by default, basically adding that layer on top of the API for a given resource type and doing the alignment that is missing across RPs where some allow to deploy/declare the child resources like vNet and subnets, while some do not like storage account and file/table/blob/queue.
On another note: Nate and I ticked the boxes for the additional doc requested.
- [x] Deploy multiple instances via loops (nested loops - Covered in Module design - child resources
- [x] Deployments happen on a different scope - Covered in Module design - Patterns