Unlocking the Power of Azure Verified Modules for Infrastructure as Code and Platform Engineering - Part 1
Stephen Tulp
December 9, 2024
9 minutes to read
Infrastructure as Code (IaC) has become a cornerstone for efficient and scalable infrastructure management. Azure Verified Modules (AVM) are a game-changer in this domain, offering pre-built, reusable IaC components that streamline the deployment and management of cloud resources. Let’s understand the background of AVM, how it’s used for IaC, and its benefits within platform engineering.
Background
The diagram below outlines the journey that I have seen numerous times for customers, these challenges are not specific to Azure and would be common across the other hyper-scalers as well. I know of customers who are at their 3rd iteration of Landing Zones because operationalising day two activities and the continual improvement and deployments with IaC don’t occur.
The AVM initiative started about 3 years ago as the Common Azure Resource Modules Library the modules were regularly updated and curated but did have some challenges at scale.
- If you cloned the repo or used the module in IP or assets that you created they would always be a point in time copy.
- Using the same module across multiple repos and projects was basically copy pasta and over time the duplication would start to drift.
- You could use Azure Container Registry as a private Bicep registry and host the modules in the ACR that could then be consumed in a Bicep template but the customer was responsible for managing the CI/CD and process of pushing new changes from the upstream repo into the ACR.
Outside the most mature customers, it was a good start but didn’t get a whole lot of traction. The repo is now archived now and everything now points to the AVM. The old wiki is still there and worth a read if you want to see how the project evolved.
What are Azure Verified Modules?
Azure Verified Modules (AVM) is a Microsoft-led initiative designed to standardise Infrastructure-as-Code (IaC) modules. This initiative adopts a decentralized ownership model, encouraging contributions from both internal and external communities. AVM modules act as composable building blocks, each encapsulating a group of resources dedicated to a specific task. These modules ensure consistent deployment of Azure resources and their extensions. By incorporating Microsoft’s Well-Architected Framework (WAF) and best practice configurations, AVM accelerates the delivery of cloud-native or migrated applications and their supporting infrastructure. This approach ensures reliability, consistency, and scalability, with built-in resiliency and security by default.
AVM defines two module classifications, Resource Modules and Pattern Modules, that can be created, published, and consumed, these are defined further in the table below:
Module Class | Definition | Who is it for? |
---|---|---|
Resource Module | Deploys a primary resource with WAF high priority/impact best practice configurations set by default, e.g., availability zones, firewall, enforced Entra ID authentication and other shared interfaces, e.g., RBAC, Locks, Private Endpoints etc. (if supported). | People who want to craft bespoke architectures that default to WAF best practices, where appropriate, for each resource. People who want to create pattern modules. |
Pattern Module | Deploys multiple resources, usually using Resource Modules. They can be any size but should help accelerate a common task/deployment/architecture. Good candidates for pattern modules are those architectures that exist in Azure Architecture Center, or other official documentation. Note: Pattern modules can contain other pattern modules, however, pattern modules MUST NOT contain references to non-AVM modules. | People who want to easily deploy patterns (architectures) using WAF best practices. |
Why Should I use them
The above outlines why I think they are important and in terms of Platform Engineering the benefits include:
- Standardisation and Best Practices: AVM sets the standards for what a good IaC module looks like. By using these modules, you ensure that infrastructure adheres to best practices and is aligned with Microsoft’s Well-Architected Framework.
- Ease of Use: AVM modules are available from their respective language-specific registries, making it easy to integrate them into existing workflows. Whether you’re using Bicep or Terraform, you can find and deploy these modules with minimal effort.
- Consistency and Reliability: By leveraging AVM, you can achieve consistent and reliable deployments across cloud environments. These modules encapsulate groups of resources dedicated to specific tasks, ensuring that your infrastructure is both modular and maintainable.
- Community and Support: AVM is supported by Microsoft and the broader community. You can raise issues, request features, and contribute to the development of these modules, ensuring that they evolve to meet the needs of the community.
- Accelerated Deployment: AVM accelerates the deployment of Azure resources and architectural patterns, reducing the time and effort required to set up and manage cloud infrastructure.
- Improved Code Quality: By using AVM, platform engineers can ensure that their code is of high quality, reducing the risk of errors and improving the overall stability of the infrastructure.
- Scalability and Flexibility: AVM modules are designed to be flexible and scalable, allowing platform engineers to easily adapt their infrastructure to changing requirements and workloads.
- Enhanced Collaboration: With a common code base and standardised modules, platform engineering teams can collaborate more effectively, sharing best practices and solutions across the organisation.
How does it Work?
At a high level the process is:
- Each module has an owner, for example Route Table as changes are made to the module they are pushed into the Microsoft Container Registry. (The Microsoft Container Registry for Bicep is essentially the way that Microsoft hosts and manages Bicep modules using Azure Container Registry)
- Published modules are tagged as a version in time that can be consumed. For example, the Route table module *‘br/public:avm/res/network/route-table:
''*, where version is '0.2.2' for example - The consumer references the module from the MCR using a tag and defined parameters.
module routeTable 'br/public:avm/res/network/route-table:<version>' = {
name: 'routeTableDeployment'
params: {
// Required parameters
name: 'nrtwaf001'
// Non-required parameters
'Some Parameters go here'
}
}
The module is pulled from the ACR so while its good to understand how it works you don’t have to as you just need to know what parameters you want to pass in, there will be required parameters and optional parameters. We will go into this more tomorrow.
My Experience
At Insight we used CARML throughout our asset and IP to help standardise IaC and modularise our templates so when i first heard about the change I did a lot of reading and testing and over the last 12 months have refactored many of our assets to use AVM where possible. It’s not perfect (looking at you outputs) but the repo, community and monthly changes are continually improving the library and I’m looking forward to see what happens over the next 6-12 months.
Conclusion
These links will help you get started with learning more about AVM and how they can help with your Platform Engineering function.
- Introducing Azure Verified Modules
- Try out AVM
- Request new feature/report bug for existing module
Azure Verified Modules represent a significant advancement in the field of Infrastructure as Code. By providing standardised, reusable components, AVM simplifies the deployment and management of cloud resources, ensuring consistency, reliability, and scalability. For platform engineering teams, AVM offers a powerful toolset to accelerate deployment, improve code quality, and enhance collaboration. Embrace Azure Verified Modules to unlock the full potential of your cloud infrastructure. In part two tomorrow we will dive into the code and look at some refactoring of Bicep code to use AVM and see how it can help with your deployments.