Prometheus has become the default metrics collection mechanism for use in a Kubernetes cluster, providing a way to collect the time series metrics for your pods, nodes and clusters. This metric collection allows you to monitor for issues, review performance over time, and also provide metrics to be used by the scaling functionality in Kubernetes. Both the Pod and Cluster auto-scaler can take custom metrics from Prometheus and use these to determine if they can scale out.

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.

I recently delivered a session at Microsoft Ignite The Tour in London around governance in Azure. One of the critical points in this session is that before you try and implement any controls around resources, cost or security you need to have a good understanding of what your Azure estate currently looks like and what resources you are making use of, so you know where to focus your effort. There is no point spending lots of time implementing policies to restrict which size web apps you can deploy if no one is using them.

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.

I have a love/hate relationship with Windows containers. On the one hand, it is great that we have an option for containerising legacy applications that are dependant on things like the full .net framework or other Windows-only features. On the other hand, Windows containers have some many limitations and issues compared to Linux containers, that working with them becomes painful. These limitations include what options you have for hosting these contains when you want to run them in Azure.

From the early days of Azure, it has been possible to configure storage accounts to be geo-redundant. Geo-redundant storage is replicated 3 times in the local region and then a further 3 times in the paired region, so that should the primary region go down, data can be accessed in the secondary. The big problem with this, however, is that the failover to the secondary region is under Microsoft’s control. Microsoft are the ones to decide as to whether the primary region is impaired enough to require storage to be failed over to the secondary region.

Time for a bit of self-promotion. I want to bring your attention to a new YouTube series I’ve recently started publishing entitle Azure Snippets. In this series, each snippet is a 10-15 minute video looking at a specific Azure based topic with all the information you need to get started and no waffle. I aim to keep these videos as short and bite-sized as possible to your not wasting any time, and just getting the information you need.

We’ve looked previously at using the open source tool https://www.packer.io/intro/ from Hashicorp to automate the process of building Azure VM images, which can then be consumed using either single VMs or VM scale sets. By using this tool and some PowerShell DSC scripts, we have been able to automate the process of spinning up a VM in Azure, installing the required software and configuration, running Sysprep and capturing an image. So far we have done this by running our Packer script manually from the command line.

Generate SAS Tokens in ARM Templates Without much fanfare, MS recently updated the ARM template spec to allow the creation of SAS tokens inside a template. This is excellent news for anyone who is deploying resources with ARM templates that rely on storage accounts and need a SAS token to access them. For those not familiar with SAS tokens, you can read more on them here but essentially Shared Access Signatures (SAS) provide a way to generate a key to undertake operations on a storage account, without needing the actual storage account key.

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.