azd composability

[savannahostrowski]

We need to invest in supporting developers beyond their initial onboarding to Azure, as they are iterating on their project. This includes both application source code and infrastructure.

We should add capabilities to allow the CLI to support developers as they make updates to existing infrastructure in a scaffolded project (e.g., the ability to swap out a database, update a configuration etc.).

Not only is this valuable for those who understand the ins and outs of Azure offerings enough to want to switch or update a resource but it also lessens the cost to developers (in terms of time etc.) to try out a template or piece of technology. A la carte infrastructure means that a developer has true flexibility beyond day 0 and reserves the right to change their mind or update infrastructure they are using for their project if their requirements change etc.

[savannahostrowski]

Some demand for similar via #1218

[aaronpowell]

Additional use-case Feature request - add template to existing project

[ahelland]

@weikanglim Thanks for the demo on composability during today's community call! (Having published a blog post earlier today about customizing the azd & .NET Aspire duo I find it an interesting timing coincidence.) @gkulin Should I open a separate issue/discussion on tweaking as a whole or is this the "generic" customization thread?)

Anywho, while I obviously haven't experimented with composability modules they could be a good feature. The DX would require some modules to be provided by MSFT, but I think it's also important to enable a decent "module developer story". The app developer could for instance add an "OpenAI module" to the azure.yaml to add logic I have pre-created that will create both the OpenAI deployment in Azure and an APIM instance with AI throttling rules and policies. (Or set up the AI simulator container image or something else for that matter.) Basically creating infra in the context of the org the developer works for. Is this in scope or is this currently about "adding to the azd black box"?

[weikanglim]

@ahelland Thank you for being there on the community call and the very insightful questions here!

We have indeed heard from multiple iterations of user studies on how important it is for enterprises to be able to control the actual resource implementation of Azure. The very high-level scenario we are thinking is the along the lines of:

• As an app developer, I want to define high-level app components I want to use.
• As a platform/infra developer, I want to control every knob of the infrastructure definition that the components are generated from.

There are two ways we can do this:

1. Allow enterprises to define new components that will work for specific use-cases
2. Allow enterprises to control generation rules of infrastructure definition from Microsoft provided components.

Both 1. and 2. are possible that we're working towards in the near long term. 1. is something that will be possible once we have enough user adoption to help guide us lay down enough formality/standardization of what a component/module is that best serves users and enterprise needs. 2. is something that is possible since azd controls the generation flow that I'm currently working on and would love to share some work on this in the near future.

[ahelland]

Sounds like you're not too far off from what I'm thinking about this feature on the high level :)

If you align the MS provided modules with Azure Verified Modules I think that covers a lot of use cases. (At least the resource modules. The pattern modules sounds like they would step out of scope for "plain" composing.) Depending on what kind of "glue" you're using behind the scenes further customization would be nice to offer, but delivering on both 1 & 2 at the same time isn't necessary.

I don't know how hard it is to align things between what flows from .NET Aspire and the code analysis azd does itself. I find it slightly tricky to tweak across the Bicep I write, inline in the Bicep azd generates and running azd infra synth to parse Aspire - having components available should hopefully not introduce another breaking point :)

[TWolversonReply]

@weikanglim Very interesting presentation on composability, and thanks to yourself and the rest of the Azd team for the transparency into your thoughts :)

One thing I couldn't glean from the presentation was: how do modules become discoverable by azd add? My thinking around this was that the business' solution architecture team would define a range of feature templates; for example a Standard Logic App with two workflows implementing a publish/subscribe orchestration 'done right' (i.e. the way we would like the development teams to implement them, with our naming conventions, tracked property metadata and so on). The development team's workflow would be to start a new feature by using a feature template, which I would think would be made available via a private template source. Is the intention that azd add discovers private templates in the same way azd init does?

@ahelland's remark on Verified Modules is a good one, I am also thinking in that direction, and I am also considering whether it would be valuable to define our own pattern modules on our own private module registry, probably 'inheriting' from AVM modules by adding some market-specific specialisations. Those would - I guess - be a level below the add semantics, where add would refer to some template source, the templates served by the template source would refer to (in main.bicep) modules from a module registry and those modules could themselves refer to AVM.

At the moment I'm of a mind that synthetic infra would be too abstract/not enough detail for me to have confidence in it, I would always want to store Bicep in source control. Fine as a bootstrapping tool, but I'm going to want to drop into the infrastructure definition right away. Many resources are already difficult enough to configure correctly without the added challenge of not being able to see exactly what provision intends to do. With this in mind I would hope that some care is taken that azd infra synth minimises churn; I don't want it to trash Bicep that I've already customised when I run it again to add the infra for a new feature.