azure.yaml has to describe your whole app itself. Anything your project already knows about itself gets copied into azure.yaml by hand, and then the two drift.
Right now a service entry wants a path, a host from a fixed set, and a language from a fixed set, and resources has a closed list of 14 types. If the truth about your app lives somewhere else (a project file, a framework config, an internal platform's manifest) you have two choices. Flatten it into our vocabulary and maintain it in two places forever, or don't use azure.yaml for it. Neither is good, and the first one is worse than it looks because the copy is only correct on the day someone wrote it.
What I want instead is to point at it:
services:
api:
project: ./src/api
provider: mycompany.platformWe load that, ask the named extension what's there, and it hands back services and infrastructure. The user never writes down what we could have asked for. This is the step where people stop describing their app to us and start pointing at it, and I think it's the single biggest reduction in "stuff you have to write for Azure" available to us.
Things that need to be right:
- There has to be a way to turn it into real text. If translated services and infra only ever exist in memory, we've made the whole thing opaque and unfixable, which is the same complaint I have about anything magic. "Show me what you translated, as
azure.yaml and infra I own and can edit" needs to ship with this, not after it.
- I'm worried about determinism. If the same repo translates differently depending on which extensions are installed, or on what a network call returned that morning, then
azd up isn't reproducible on a colleague's machine or in CI. A reference needs to pin the extension and its version.
- Cost. If figuring out whether an extension can handle a path means launching that extension, then startup cost scales with how many extensions you have installed, on every single command. Extensions should declare cheap match criteria we can evaluate first, and we only pay for a process when something plausibly matches.
- Anything the user wrote by hand wins over anything we translated, and we should say out loud (or error) when we dropped a translated value because an explicit one was already there.
azure.yamlhas to describe your whole app itself. Anything your project already knows about itself gets copied intoazure.yamlby hand, and then the two drift.Right now a service entry wants a path, a host from a fixed set, and a language from a fixed set, and
resourceshas a closed list of 14 types. If the truth about your app lives somewhere else (a project file, a framework config, an internal platform's manifest) you have two choices. Flatten it into our vocabulary and maintain it in two places forever, or don't useazure.yamlfor it. Neither is good, and the first one is worse than it looks because the copy is only correct on the day someone wrote it.What I want instead is to point at it:
We load that, ask the named extension what's there, and it hands back services and infrastructure. The user never writes down what we could have asked for. This is the step where people stop describing their app to us and start pointing at it, and I think it's the single biggest reduction in "stuff you have to write for Azure" available to us.
Things that need to be right:
azure.yamland infra I own and can edit" needs to ship with this, not after it.azd upisn't reproducible on a colleague's machine or in CI. A reference needs to pin the extension and its version.