Speaker notes

01 / 04Context

Strongly Typed Deployment Topology for Global Cloud Releases

Context: replacing fragile text-based infrastructure orchestration with a typed deployment platform

Project context

A new globally distributed cloud service needed a repeatable way to deploy both application code and Azure infrastructure across regions and release rings.

  • Deployment scope included compute, databases, DNS, public IPs, Traffic Manager, Front Door, Redis, data pipelines, identities, and access boundaries.
  • The team’s application code was only part of the problem; the deployment platform had to express and sequence the whole regional topology.
  • The target operating model: ~20 global scale units, four release rings, and a path to broader adoption by other services.
Release model
Canary
›
Light
›
Heavy
›
Rest
scale units worldwide
~20
Why not ARM-as-text?

Text templates hid deployment risk until late in the release path.

1

Mistyped resource references

Compile-time safety was weak; failures often surfaced at deployment time.

2

Dynamic value propagation

Runtime outputs from one resource were awkward to pass to another.

3

Manual dependency maintenance

dependsOn and ordering logic lived separately from the actual resource references.

4

High-cost changes

Adding or reshaping resources meant editing multiple templates and validating late.

Technical Discussion · Deployment Platform01
Open with the business / engineering context. The point is not that ARM was bad; ARM was the standard. The problem was that our domain had repeated, regionalized topology with many dynamic references, and text templates pushed too many mistakes to deployment time. The narrative is: I used this new project to change the abstraction, not just automate an existing manual process.
02 / 04Architecture

Architecture: turn deployment into a typed object graph

The core design: resource references are configuration, runtime value flow, and dependency declarations at the same time

refs Typed topology model DeployableResource ASU01 container VMSS DNS Redis Front Door DB Traffic - - › typed reference = edge ASU02 ASU03 ASU04 ASU05 ASU06 ASU07 ASU08 STAGE 1 Object graph scan Follow resource references to build target DAG STAGE 2 Deployment planner Topological order + parallel waves + cycle errors STAGE 3 Execution engine Azure SDK calls, retries, idempotent re-runs AZURE Target region Create/update/delete desired resources Container Scoped resource Scale unit Reference edge Graph input Cloud target

Everything is a DeployableResource. Containers hold scoped resources; references between objects form edges.

Design thesis

Make invalid deployments harder to express.

  • Use C# type system and IDE navigation to make resource composition explicit and discoverable.
  • Infer dependencies from object references instead of asking engineers to manually maintain a second dependency list.
  • Keep dynamic values typed: an endpoint, identity, or output remains a structured value, not a string fragment in a template.
  • Deploy a target resource or scale unit by walking only the relevant subgraph, not the whole service every time.
Technical Discussion · Deployment Platform02
Emphasize that the model is not just a cleaner API. The key design is that the same object reference is used for composition, runtime value propagation, and dependency inference. This is stronger than just saying C# is easier than JSON. If asked about generated ARM, explain that it would preserve some native deployment tooling, but it would duplicate resource mapping and add a two-layer debugging path.
03 / 04Execution

Execution semantics: targeted, safe, and resumable

The platform had to behave predictably under partial failure, retries, and repeated deployment attempts

idempotent re-run 01 Target resource entry point 02 DFS graph build relevant DAG only 03 Cycle detection DFS coloring 04 Parallel waves independent nodes 05 Azure SDK deploy retry + idempotency 06 Reconcile delete absent resources
Retry policy
429

Follow server-provided retry/backoff hint

400

Do not retry; surface configuration/request error

5xx

Retry transient failures, default max 3 attempts

Why it matters

The platform could be safely re-run after fixing a failed resource rather than requiring a full manual unwind.

Partial failure

The platform does not pretend to solve application compatibility magically.

  • Non-destructive failure: fix root cause and re-run deployment.
  • Destructive dependency change: dependent resources must be backward-compatible.
  • If compatibility cannot be guaranteed, deployment must use the rollback path.
State & deletion

Desired graph vs actual Azure state

  • Resource identity comes from Azure resource IDs; Azure provides idempotent create/update semantics.
  • Deletion compares the desired DAG with existing resources and removes resources no longer present.
  • Cycle detection uses DFS coloring and returns the cycle path for actionable diagnostics.
Technical Discussion · Deployment Platform03
This slide is for depth. Don't try to explain every bullet if time is short. The important signal is that the platform had concrete execution semantics: targeted graph generation, parallelism, cycle detection, retry classification, idempotent re-runs, and explicit handling of partial failure. For Q&A, be ready to say that destructive compatibility is not hidden by the deployment platform; services must maintain compatibility or use rollback.
04 / 04Judgment

Trade-offs, impact, and hindsight

The decision was worthwhile because the pain was real—but the custom platform also introduced ownership cost

Alternatives considered

ARM / Bicep

Best for

Native platform integration, broad samples, and day-one resource support.

Cost

Text references, late validation, manual dependsOn, weaker IDE flow.

Generate ARM

Best for

Could keep native deployment backend while adding a typed wrapper.

Cost

Duplicates resource mapping and ARM expression semantics; harder debug path.

Azure SDK platform CHOSEN

Best for

Typed models, runtime references, inferred DAG, domain-specific developer experience.

Cost

Custom execution runtime, SDK support lag, ongoing platform maintenance.

Outcome signals
0

live-site issues caused by infrastructure orchestration mistakes

~20

global scale units supported by the initial service rollout

4

release rings for staged global deployment

Dozens

of services / systems later adopted the platform pattern

HindsightRetrospective

I would keep the strongly typed topology, but make the deployment backend pluggable earlier—allowing SDK-backed and ARM-backed resources to coexist when Azure SDK support lagged or when native release integration mattered more.

Technical Discussion · Deployment Platform04
Close with judgment. The mature answer is not that the custom platform was universally better than ARM. It was better for our domain because it encoded the product topology and reduced orchestration mistakes. The hindsight point is important: separate the domain model from the execution backend earlier. If pushed, explain that native ARM/Ev2 integration would have been valuable for some resource types and that SDK availability lag created real friction.