For the last several months Pete Zerger, Tao Yang, Kevin Greene, Anders Bengtsson and me have been working hard to update Inside OMS book. With the latest changes we are now on version 3 of the book and with new name: Inside Azure Management
Lately you haven’t seen new blog posts by me due to diverting my community time and efforts towards Inside Azure Management book. As now I have finished most of my work on the book I can focus again on blogging.
I very often work closely with the ARM team by giving them feedback and features like Azure Resource Manager template language additions are appearing because of that feedback and I am sure the feedback by many other MVPs, partners and customers. Because of that I never settle for workarounds where you can do something natively within ARM template. I have previously blogged about an issue with deploying Azure Policy definitions via ARM template:
For the last a couple of years many Azure services has started to produce diagnostic logs and metrics. These two allows you to monitor and troubleshoot the Azure Services. Unfortunately still there are some services that are missing those. To pull diagnostic logs and metrics Azure Monitor has capability called Diagnostic settings which allows you to place them on Azure Storage, Event Hub or Log Analytics. Microsoft has done a good job to document many of diagnostic logs available but still I find some services that haven’t be documented. Luckily there is a way to find what diagnostic logs are available for a service (resource) and this blog post will focus on that.
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.