[Initiative] 🏗️ App model for Azure

[kristenwomack]

Problem statement

Azure developers use a rich set of tools: CLIs, IDE extensions, dashboards, and infrastructure-as-code providers. Today, each has its own install path, UX patterns, and update cadence. There's an opportunity to tie these together into a more cohesive experience.

For example, azd tool can give developers a single command to discover and install everything they need, instead of following multi-page setup guides. A redesigned azd init can offer smarter template selection and let extensions participate in the flow. A lightweight local dashboard can show deployed services and health without switching to the Azure Portal. And Terraform users can get first-class support through the extension model.

This scope is the developer experience layer: the tools, surfaces, and UX patterns that make Azure development feel like one product instead of a dozen.

Vision

Azure developers have a seamless platform experience: one command to set up their toolchain, a consistent UX across every azd interaction, local visibility into their running apps, IDE extensions that build on azd instead of duplicating it, and infrastructure-as-code support that meets developers where they are.

Who this helps

• Developers setting up a new environment can run azd tool and get a guided walkthrough of what's installed, what's missing, and how to get it. No more following multi-page setup guides.
• Developers running azd init for a new project get a smarter experience: better template selection, collision detection, and the ability for extensions to participate in the init flow.
• Developers who just ran azd up can see their deployed services, resource health, and logs in a local dashboard without opening the Azure Portal.
• VS Code extension teams can use azd as the resource creation layer instead of maintaining their own ARM/Bicep calls, which means consistent behavior across extensions.
• Terraform users get improved azd support (through the extension model with community ownership of the Terraform-specific implementation?).

Goals (in scope)

• Ship azd tool as the unified entry point for Azure developer tooling
• Redesign the azd init experience with smarter defaults, agentic flows, and published UX guidelines
• Prove the VS Code re-platforming model with a PoC extension using azd for resource creation
• Deliver a local view for app resources and status
• Move Terraform support into the extension model via provisioning providers

Non-goals (out of scope)

• Building a package manager; leverage native installers (winget, brew, apt)
• Full re-platform of all VS Code extensions; this is PoC scope
• Building a custom local view from scratch; evaluate existing options first
• Feature parity between Terraform and Bicep in core azd
• Owning ongoing Terraform or VS Code extension-side maintenance; community and partner teams own that

Success criteria

• azd tool ships with discover, install, and manage commands across Windows, macOS, and Linux
• azd init redesign ships with smarter template selection and agentic init; UX guidelines published
• At least one VS Code extension PoC validates azd as the resource creation layer
• Local view approach decided and lightweight version shipped or integration validated
• Terraform extension prototype runs on provisioning providers framework
• azd tool and first-run completion rates tracked and improving

Dependencies

• Extension framework GA: Terraform extension and VS Code re-platform depend on stable extension APIs
• azd ai GA: Dashboard and init flows need to account for AI workloads
• VS Code extension team: Azure extension strategy change requires partnership and agreement from extension owners

[vhvb1989]

It would be good to see a comparison between the Docker approach v/s dev box v/s azd tool ...