Versioning of runtime and packages in Azure Automation has been a pain for a long time. All of your scripts in the same automation account will use the same version of PowerShell and have access to the same versions of any packages you install. If you update some package versions for one script, you risk breaking things for other scripts. If you want to use specific packages that can’t be used alongside other packages (such as AzureRM vs Az modules), then you can’t be sure you aren’t breaking other scripts that might rely on the other packages.
This is a relatively new feature in Azure Resource Manager Templates that I wasn’t aware of until someone mentioned it to me today. It is now possible to catch the failure of an ARM template deployment and then trigger running a previous version of the template when this happens. I’m hesitant to call this a roll-back (even though the docs do), as there are some limitations that mean it’s not really a full roll-back, but it could be a useful tool to deal with failed deployments.
Budgets are a feature of the new Azure cost management tool, which is primarily the integration of Cloudyn into the Azure portal. Budgets allow you to set a financial boundary for a subscription or a resource group, which you can monitor through cost management and trigger alerts when you are close to the cost set in your budget.
One thing you cannot do with budgets, and something that many people feel is an obvious requirement, is to stop people spending any more money when they hit the budget.
A few months back we looked at how we can use a tool called Packer to automate the creation of virtual machine images, which could then be used with VM Scale Sets. If this is something you are interested in doing, I would recommend taking a look at the original article, which walks you through the whole process.
At the end of that article, I said we were next going to look at how we can use continuous integration to build this image on a regular schedule, or when applications are updated.
I’m presenting a session this weekend at SQL Saturday Manchester on how to deal with lack of SQL agent when moving to Azure SQL. This session looks at options in Azure for running regular jobs against SQL databases and usually focusses on using Azure Automation and Azure functions. However, just a couple of weeks before the event Microsoft released a new service that could also be used to fill this gap, SQL Elastic Jobs, and so I needed to squeeze that into my presentation last minute.
