Skip to content

Practical Journey

The Practical Journey turns the architecture guidance in this repository into a staged deployment path. Each stage is independently deployable, teaches one production concern at a time, and uses the same Practical Storefront sample so you can focus on architecture changes instead of app rewrites.

Use the journey when you want a hands-on progression from a public MVP to a resilient multi-region baseline, with a clear trigger for when each stage becomes worth the extra cost and complexity.

Journey progression

flowchart TD
    S1[S1 — MVP<br/>Adds App Service, Azure SQL, App Insights, Log Analytics]
    S2[S2 — Production Baseline<br/>Adds Key Vault, managed identity, staging slot, alerts]
    S3[S3 — Scale / Edge<br/>Adds Front Door, WAF, autoscale]
    S4[S4 — Network Isolation<br/>Adds VNet integration, private DNS, SQL private endpoint]
    S5[S5 — Resilience<br/>Adds secondary region app stack, second SQL server, failover group]

    S1 --> S2 --> S3 --> S4 --> S5

Stage guide

Stage When to use it Trigger Cost Time
Stage 1 — MVP Get a real public app online fast "We need a real public web app online this week." ~$0.09–$0.13/hour 20–30 min
Stage 2 — Production Baseline Add release safety, secret custody, and alerts "The app now matters to the business." ~$0.14–$0.20/hour 25–40 min
Stage 3 — Scale / Edge Add edge protection and autoscale "Traffic is growing and internet exposure is a concern." ~$0.20–$0.30/hour 35–50 min
Stage 4 — Network Isolation Make the data path private "Compliance requires private data access." ~$0.24–$0.36/hour 35–55 min
Stage 5 — Resilience Add active-passive regional resilience "Business needs regional outage tolerance." ~$0.45–$0.80/hour 50–75 min

How to use the journey

  1. Start with Getting Started to prepare your Azure account, CLI tools, and required environment variables.
  2. Use Cost and Time Model to choose the stage that fits your budget and delivery window.
  3. Deploy only the stage that matches your current production concern. The stages are designed to teach one concern at a time, not to be kept running together by default.
  4. Use Verify and Destroy after each deployment so the architecture is proven and the spend is cleaned up.
  5. Use Module Map when you want to trace a stage back to the Bicep modules that compose it.

What this section is not

  • It is not a single linear lab that must leave all five stages deployed at once.
  • It is not a replacement for the deeper reasoning in Platform, Patterns, and Workload Guides.
  • It does not hide trade-offs: later stages cost more because they solve more production risks.

See Also

Sources