Before Ignite 2018 Azure Resource Manager (ARM) and specifically ARM templates are the only deployment option available. I am excluding Azure CLI, AzureRM PowerShell, SDKs, etc. from this list of course. At Ignite 2018 Microsoft has announced two other options – Azure Blueprints and Azure Deployment Manager (ADM). This blog will express my opinion on this matter. You are free to express your opinion as well and to disagree with me. I will not focus on comparing heavily those 3 nor trying to bash one service over another instead I will write the reasons why I think still Azure Resource Manager deployments should be your first choice as they are mine.
Microsoft recently release the new Logs experience with this also removing the link to the Advanced Analytics Portal which was separate portal. My friend and fellow MVP Stefan Roth opened a e-mail discussion to some of us asking if there is a way to reach his workspace again from the Advanced Analytics Portal as that portal offered cleaner experience where Logs is a little bit cluttered due to being general portal for Azure services. I had some tips on how to use better the Logs experience in Azure Portal and my friend and fellow MVP Cameron Fuller thought that we should share this with the community thus this blog post.
Not so long ago in Azure we only had resource group level deployment but a couple of months ago subscription level deployments were implemented. On resource group level we deploy resources like Azure VMs, Service Apps, Azure SQL databases, etc and on subscription level we deploy policy definitions and assignments, resource groups (yes they are resource as well), custom RBAC roles, etc. Because of that it the schema in the ARM templates for resource group and subscription level deployments is different. This is something I haven’t thought about it around the excitement of this new deployment method but my good friend Kristian Nese tipped me. So here are the schemas you should use depending on your deployment:
In my blog post Defining Input Parameters For Policy Definitions in ARM Template I’ve showed you how to use deploy policy definitions with parameters via ARM template. I didn’t described completely on why such workaround is needed but I think now it is good time to explain that as well. The topic is a little bit complex so I hope my explanation will help you understand it.