Bicep syntax and modules in Azure - Time & Space Complexity
When using Bicep modules, it is important to understand how deployment time grows as you add more modules.
We want to know how the number of modules affects the total deployment operations.
Analyze the time complexity of deploying multiple Bicep modules sequentially.
module storageModule './storage.bicep' = {
name: 'storage'
params: {}
}
module networkModule './network.bicep' = {
name: 'network'
dependsOn: [storageModule]
params: {}
}
module appModule './app.bicep' = {
name: 'app'
dependsOn: [networkModule]
params: {}
}
This sequence deploys three separate modules: storage, network, and app.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Deploying each Bicep module triggers resource provisioning API calls.
- How many times: Once per module included in the main Bicep file.
Each added module causes a new deployment operation, so the total deployment steps grow as you add modules.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 3 | 3 deployment operations |
| 10 | 10 deployment operations |
| 100 | 100 deployment operations |
Pattern observation: The number of deployment operations grows directly with the number of modules.
Time Complexity: O(n)
This means deployment time grows linearly as you add more modules.
[X] Wrong: "Adding more modules does not affect deployment time because they run in parallel."
[OK] Correct: Modules are deployed sequentially in this scenario due to dependencies, so each module adds to total deployment time.
Understanding how module count affects deployment helps you design scalable infrastructure templates and shows you can reason about deployment costs.
"What if modules were deployed in parallel? How would the time complexity change?"