Hello Azure Tools Tech Community!
Today I would like to introduce you to Azure Verified Modules (AVM), an exciting initiative that the AVM Team, Community and Product Groups have been working on that will change the game when it comes to deploying Infrastructure-as-Code modules.
Many of our customers start their cloud adventures by setting up and managing their resources directly through the portal. As they become more familiar with the cloud, they tend to move towards using Infrastructure-as-Code methods, using tools like ARM templates, Bicep, or Terraform, and automating deployments with services like GitHub Actions or Azure DevOps. However, this transition can lead to challenges when different teams within the same organization adopt different approaches to deploying resources. This mix of methods can create confusion and inefficiencies, often requiring teams to reassess their strategies to find a more unified approach.
What is Azure Verified Modules?
Azure Verified Modules (AVM) is a unified, Microsoft community driven aspiration, inside and outside of Microsoft to strategize and simplify Infrastructure-as-Code modules using the tool-sets our customers use today.
The AVM initiative is an evolution of lessons learned from previous Infrastructure-as-Code projects such as, Terraform Verified Modules and the CARML (Bicep) project. By that, AVM brings together a shared Infrastructure-as-Code module strategy and establishes a single source of truth across Microsoft. It aligns with the well-architected framework, ensuring deployments are secure and reliable by default.
With this unified collection of modules, our goal is to make deploying resources simpler and more familiar, reducing the need for users to build everything from scratch for each project. This can be done using resource modules or pattern modules, these modules enable users to accelerate the progress, regardless of your current stage in your Infrastructure-as-Code journey. You don’t have to build, maintain and support them yourself, AVM does this for you.
The main advantage of AVM is that it's made to be user-friendly for developers and engineers allowing them to use these modules to quickly set up their environment to help speed up the development process and simplifying the management process.
AVM is targeted towards customers wishing to build, construct and deploy workloads into their application landing zones (subscriptions). Whether self-constructed from resource modules or using pre-built pattern modules.
Modules
The current AVM Framework is utilizing the same technologies our customers use today. In our initial release we are currently focused on Bicep & Terraform, with a mind of future expansion into other tool-sets as required by the customer base.
As part of the AVM Framework modules are currently supported in the following scopes:
|
Resource Modules: These are like building blocks to set up a single Azure service for you. For example, if you need a virtual machine, the resource module gives you a fully operational VM along with everything it needs to run, like network connections.
Pattern Modules: These are like bigger blueprints that group together several services to create a complete solution. For instance, if you're building an app, a pattern module could set up the whole environment for you, including things like load balancer's, VMSS and security features. |
For more information visit Resource Modules and Pattern Modules.
If you're looking for modules, check out the Module Indexes for an overview of currently available and planned for future release in both Bicep and Terraform languages. You can easily access the published modules on their specific public registries.
- For Bicep modules: Bicep Public Module Registry
- For Terraform modules: HashiCorp Terraform Registry
How can the community contribute?
Anyone in the world can contribute to AVM, it is just to submit an issue or a pull request to the repository you'd like to help with. When a new AVM Module is created there are to key roles which are provisioned to support the modules:
Module Owners
- Microsoft FTE's Only to enable continuity and support throughout the module lifecycle.
- Responsible for creating, managing and maintaining the module.
- Microsoft FTE can act as a owner to support development from the community.
Module Contributors
- Anyone, Anywhere.
- Can support the module owner with managing and maintaining the module.
Become a Module Contributor from any corner of the globe or step up as a Microsoft FTE to lead as a Module Owner!
Curious about what’s brewing in our development kitchen?
Check out the Module Triage Board that is our publicly available backlog view of all ongoing developments, including proposed modules and their current progress. If you're keen to contribute, drop a comment and we'll gladly connect you with the team!
Further resources
If you're curious to learn more about AVM, the official documentation is a great place to start. Also, consider watching this great video from Matt White and Jack Tracey for a deeper dive:
Keep a look out on this feed, another blog post will be published shortly explaining how to consume AVM Modules
Visit our support page: aka.ms/AVM/support to see how we maintain and update our modules to ensure they work well for you.
For any issues, submit a ticket directly via our support page, where you can also learn how we maintain and update our modules to ensure they work well for you!