AVM External Community Call - 21st May 2024

[jeanchg]

The Azure Verified Modules Core-Team is now running a quarterly Community Call, showcasing all of the great work the community and the team have done, alongside important updates, guest speakers and a community Q&A.
To sign up for the first occurrence, please use: Teams Webinar link
Please leave comments below on topics you'd like covered.

[MarcoJanse]

First of all, thank you all for the great work on this repository and for organizing this community call.

I have a question about prefixes and why they aren't used in the Azure Verified Modules.
Until now, I was using prefixes in my Bicep modules and orchestration files for readability and consistency like this:

Component	Prefix	Example
Module	mod	modMyModule
Resource	res	resMyResource
Variable	var	varVariable
Parameter	par	parMyParameter
Output	out	outMyOutput

I know I wasn't the only one that did this. For example: it's also extensively used in the ALZ-Bicep repository that has a couple of the same contributors as the Azure Verified modules.
Could you explain why prefixes are not being used in Azure Verified Modules?

[jurjenoskam]

Great to have a session like this! I'm interested in what the interaction and feedback loop looks like between the AVM module developers and the Resource Provider teams.

The release of Bicep resulted in quite a few improvements to the underlying ARM template language for example. I'm hoping that the AVM initiative will have a similar effect on the Resource Provider API's and what they expose via ARM. Currently there's more inconsistency between the behavior of different Resource Providers than we'd like, see for example Azure/bicep#387 (Resource Providers handle null in different ways) or Azure/bicep#4988 (Azure SQL is not idempotent when setting Entra ID administrators).

I hope the AVM initiative has a similar positive effect on Resource Provider behavior as Bicep does on ARM. I'm curious how the AVM team sees this and how they interact with the Resource Provider teams.