In utilizing code to perform Azure deployments, a few lessons have been learned, regardless of the language or the tools being utilized.
- Process – Use Azure DevOps to track tasks, commit code (frequently) and structure complex multi-step deployments. Start putting good habits in place early!
- Scale – Not all simple templates are able to be scaled without going back to the drawing board a few times. Don’t be afraid to think out of the box and leverage the capabilities of IaC to improve efficiency in testing and developing Azure solutions.
- Modularization – Simplify complex deployments by modularizing template resources using nested templates, linked templates and Azure DevOps.
Before touching a keyboard, it’s essential to have a detailed understanding of the Azure resources to be deployed and their dependencies. For example, to deploy an Azure Virtual Machine, it may be helpful to perform this process via the Azure Portal and document the process and requirements. It’s also important to track these tasks in Azure DevOps. Create Work Items to track progress and keep the development process on track.
Scaling out a deployment may require adjustments to the template structure. Azure imposes limitations and constraints on templates and the resources which can be deployed via ARM templates.
Some key factors to consider in scaling a template deployment include:
- Naming convention
- Access to new or existing subscription resources
- Integration with multiple toolsets and/or third-party tools
- Deployment of multiple resources
- Resources which cannot be deployed via an ARM template
It’s recommended to modularize templates for readability, portability and scale.
Debugging a template which has thousands of lines of code and multiple dependencies results in inefficiency and frustration. Porting and integrating existing templates into customer environments is not always seamless. Scaling a template to meet customers’ specific requirements may not be repeatable or easily replicated.
Complex deployments often require the use of linked templates. For example, deploying Azure Monitor in a multi-customer environment required using nested templates, linked templates and Azure DevOps CI/CD pipelines.
The main template deploys the Log Analytics workspace as the top-most resource under which performance counters and event logs are nested. The folder structure organizes the linked templates.
Some components of Azure Monitor require only a single template. Saved Searches and Solutions are deployed to the workspace at the same time. Solutions are deployed via a copy array and include only one resource which iterates the solution names in the parameters section. Saved Searches are deployed as individual resources which declare the specific properties of each Saved Search.
Deploying Azure Monitor Alert resources via template required multiple templates, one template per alert. For each alert, the number of parameters were excessive due to the number of required properties, values and thresholds. If each Alert template required a minimum of 10 parameters, just 5 Alerts added hundreds of lines of code to the template. This did not meet the objective of being scalable. It was expected that an initial production deployment may range from 15-20 alerts but the number of alerts was expected to grow month-over-month.
Templatizing and automating the deployment of Azure Monitor has reduced the time to deploy or adjust a deployment if needed. The time required to deploy the workspace in this deployment was reduced from 4-5 days to less than an hour. It’s repeatable, consistent and can be further expanded to include other services which are required when onboarding customers.
The next part of the series will cover how Azure DevOps was utilized to further orchestrate this deployment process in a multi-customer environment.