Azure / ResourceModules

This repository includes a CI platform for and collection of mature and curated Bicep modules. The platform supports both ARM and Bicep and can be leveraged using GitHub actions as well as Azure DevOps pipelines.
https://aka.ms/carml
MIT License
725 stars 460 forks source link

Add documentation to qualify the comments on 'Anti-patterns' in module design #1180

Open MariusStorhaug opened 2 years ago

MariusStorhaug commented 2 years ago

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:

Suggestions to where this doc could be:

rahalan commented 2 years ago

Needs more refinement

MariusStorhaug commented 1 year ago

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.