Deployment at scale

[erwinkramer]

Let us know the feedback or general question

Some modules in this repo, like roleAssignmentSubscriptionMany assume you specify at least a couple subscriptions, while other assume you just stick to one landingzone/subscription, like hubPeeredSpoke.

What actually scales?

1. having the hubPeeredSpoke module being called from 100 different yaml tasks in my pipeline, or
2. calling the module 100 times as a submodule.

Seems like the first one isn't really an option, because who would create (even in a loop construction), 100 tasks in a pipeline?

Seems like the last one isn't really an option, since i got this reply a while ago from Microsoft support, on a similar setup:

Regarding your concern, we want to inform you that the "800 resources" limit in Bicep refers to the maximum number of resources that can be deployed in a single Bicep file. This limit includes all the resources declared within the Bicep file, including any linked or nested deployments. Each resource declaration in Bicep represents a single resource, and the total count of these declarations should not exceed 800. A subdeployment in Bicep is not considered a separate resource, but rather a way to deploy multiple resources together.

Also see template limits.

Not being able to update all at once doesn't seem an option either, there are enough scenario's to deploy a change to all subscriptions

Is there an opinionated approach?

Code of Conduct

• I agree to follow this project's Code of Conduct

[oZakari]

Hi @erwinkramer,

Instead of using the Hub Peered Spoke module within ALZ-Bicep, we recommend using the SubVending module from the Bicep registry, which has recently become part of the Azure Verified Modules.

You wouldn't need to create 100 separate tasks within a pipeline. One efficient approach is to use a single PowerShell script (or another scripting language) to loop over the parameter files for each Hub Peered Spoke deployment. Alternatively, you can use loops within Bicep to deploy the module as many times as needed.

To avoid the 800-resource deployment threshold per deployment, consider breaking out the deployments based on where the landing zone subscriptions reside. For example, you can organize the deployments by specific management groups, such as the Corp Management group or the Online Management group, and any other hierarchies you may have.

Also, to add, typically customers deploy subscriptions on an as-needed basis, which is automated through a series of steps as documented here. There could be circumstances where you'd need to adjust deployment settings for pre-existing Hub Peered Spokes, but that's generally not the norm.

Will close this for now, but if you need any additional clarification, please feel free to just respond back here.