Deployment Manager as native IaC in GCP - Time & Space Complexity
When using Deployment Manager to create cloud resources, it's important to know how the time to deploy grows as you add more resources.
We want to understand how the number of resources affects the deployment time and API calls.
Analyze the time complexity of deploying multiple resources using Deployment Manager.
resources:
- name: vm-instance-1
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: zones/us-central1-a/machineTypes/n1-standard-1
- name: vm-instance-2
type: compute.v1.instance
properties:
zone: us-central1-a
machineType: zones/us-central1-a/machineTypes/n1-standard-1
# ... repeated for n instances
This configuration creates multiple virtual machine instances, each defined as a separate resource.
Identify the API calls, resource provisioning, data transfers that repeat.
- Primary operation: Creating each VM instance via the Compute Engine API.
- How many times: Once per resource, so n times for n instances.
Each additional resource adds one more API call to create it, so the total work grows directly with the number of resources.
| Input Size (n) | Approx. API Calls/Operations |
|---|---|
| 10 | 10 |
| 100 | 100 |
| 1000 | 1000 |
Pattern observation: The number of API calls grows linearly as you add more resources.
Time Complexity: O(n)
This means the deployment time grows in direct proportion to the number of resources you define.
[X] Wrong: "Adding more resources won't affect deployment time much because Deployment Manager handles everything at once."
[OK] Correct: Each resource requires its own API call and provisioning, so more resources mean more work and longer deployment time.
Understanding how deployment time scales with resource count helps you design efficient infrastructure and explain trade-offs clearly in real projects.
"What if Deployment Manager supported batching multiple resource creations in a single API call? How would the time complexity change?"