The Azure App Service landing zone accelerator is an open-source collection of architectural guidance and reference implementation to accelerate deployment of Azure App Service at scale.
[x] [Bicep-Multitenant] (Importance: High) The current implementation is one huge file. We need to adhere to best practices and break down this file into smaller, reusable modules. This will make it easier to understand and maintain the deployment and will also facilitate re-usability of big portions of the code (i.e. from ASE Scenario etc.) (Guidelines: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules)
[x] [Bicep-Multitenant] (Importance: High) All Resources are being deployed in one Resource Group. There should be two Resource Groups (one for Hub, and one for Spoke)
[x] [Bicep-Multitenant] (Importance: Low) It would be nice to have some kind of sanitization and guidelines for the names and params of the resources. This can be achieved with Bicep Param Decorators (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameters#decorators). On top of that, some variables might be properly sanitized to avoid deployment errors. For instance, a Storage account's name has strange rules (name must #be max 24 chars, globally unique, all lowercase letters or numbers with no spaces).
We could have a variable for that name that would impose those rules (i.e. var storageNameValid = toLower(replace(name, '-', '')) and then var uniqueStorageName = length(storageNameValid) > maxNameLength ? substring(storageNameValid, 0, - maxNameLength) : storageNameValid)
[x] [Bicep-Multitenant] (Importance: High) Bicep implementation still lacks consistent coding style and human readability best practices (comments, etc.) A good starting point for best practices is this doc: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/best-practices
[x] [Bicep-Multitenant] (Importance: High) The current implementation is one huge file. We need to adhere to best practices and break down this file into smaller, reusable modules. This will make it easier to understand and maintain the deployment and will also facilitate re-usability of big portions of the code (i.e. from ASE Scenario etc.) (Guidelines: https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/modules)
[x] [Bicep-Multitenant] (Importance: High) All Resources are being deployed in one Resource Group. There should be two Resource Groups (one for Hub, and one for Spoke)
[x] [Bicep-Multitenant] (Importance: Low) It would be nice to have some kind of sanitization and guidelines for the names and params of the resources. This can be achieved with Bicep Param Decorators (https://learn.microsoft.com/en-us/azure/azure-resource-manager/bicep/parameters#decorators). On top of that, some variables might be properly sanitized to avoid deployment errors. For instance, a Storage account's name has strange rules (name must #be max 24 chars, globally unique, all lowercase letters or numbers with no spaces). We could have a variable for that name that would impose those rules (i.e. var storageNameValid = toLower(replace(name, '-', '')) and then var uniqueStorageName = length(storageNameValid) > maxNameLength ? substring(storageNameValid, 0, - maxNameLength) : storageNameValid)