Modify Directory structure to reflect shareable components and dependencies

[shawngib]

Benefit/Result/Outcome

Current structure has all 'modules' and core resource files located in single directory. Recommendation would be to place core modules (those that represent the basic Azure component like resource group and network into a 'modules/core' folder and specific MLZ opiniated modules in a 'modules/mlz' folder allowing for add on's and extension builders to use either the core module or the modified opiniated module where needed while also allowing them to add 'core' modules and a folder representing the add on/extension for their opiniated version.

Acceptance Criteria

All modules in easily understandable directory structure and extensible when needed without need to modify core, or MLZ opiniated versions. Example:

[glennmusa]

I see what you mean. "This hub network is what makes MLZ" is different than "this is a generic reusable virtual network".

I see the benefit, but do think this could wait and is lower priority then some of our other current needs, though.

My two cents, if I were to layout "what is MLZ" and "what is generic and reusable" it looks like this:

missionlz
└── src
    └── bicep
        ├── mlz
        │   ├── addons
        │   │   ├── appService
        │   │   ├── newWorkload
        │   │   └── remoteAccess
        │   ├── core
        │   │   ├── centralLogging.bicep
        │   │   ├── hubNetwork.bicep
        │   │   ├── policies
        │   │   │   ├── CMMC.json
        │   │   │   ├── IL5.json
        │   │   │   └── NIST80053.json
        │   │   ├── policy.bicep
        │   │   └── spokeNetwork.bicep
        │   ├── main.bicep
        │   └── main.json
        └── modules
            ├── bastionHost.bicep
            ├── firewall.bicep
            ├── resourceGroup.bicep
            ├── subnet.bicep
            └── virtualNetwork.bicep

[shawngib]

Seems visually impactful and future code writing impactful but in reality its low effort and light impact in potential regressions. The goal is allow for an understanding of creating additional LZ's (extensions), modifying LZ, adding to (add-ons) and potentially adding core features. In @glennmusa 's example above, for instance, almost any and all Azure resources can be easily represented in 'modules' directory and the opinions live in MLZ\core modules that call those generic modules. Only change I would suggest is instead of 'policies' living in the root, since they are MLZ core specific I would suggest an 'artifacts' directory in core and move the policy folder there. I foresee in the near future needing scripts also as a directory in artifacts folder. This can also be a place for add-ons/apps to be created that customers can use to upload artifacts to a storage account that is required in the overall workload or MLZ proper, like PowerShell az modules, az cli and other requirements.

[glennmusa]

Removed my assignment and any progress to any project, was experimenting with the new GitHub Projects Beta. Like your idea @shawngib that policy as it's defined today is MLZ-specific and updated the tree with that.

[brooke-hamilton]

The next step is to analyze and implement this after #543 and #544

[brooke-hamilton]

Closing - created #561 for this work.