In any application it is likely you are going to need access to some “secret” data, connection strings, API keys, passwords etc. It is essential that the applications that need them can access these secrets, but that they are also kept secure. One way of doing this is using Azure Keyvault; this is a secure store which can hold secrets, keys and certificates and allow applications to access them securely. Generally, Keyvault Secrets are accessed by the application making a call to the KeyVault API and providing the appropriate credentials (username/password, certificate or managed service identity).

Azure Key Vault is an excellent solution for storing secrets, be these simple passwords or certificates, and allowing applications to access them securely. This means however that Key Vault data becomes critical for your application and you need to make sure it is protected and available. Key Vault already includes some protections - version history for secrets, geo-redundancy for disaster recovery. However, these do not protect you against accidental deletion of secrets or the entire vault.

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.

I’ve been making fairly heavy use of Kubernetes on Azure of late, and this has been mostly done using ACS Engine to create the clusters. I need to make use of Windows clusters which is not supported in the AKS PaaS service, so I need to create a custom cluster using ACS-Engine. For those who don’t know, ACS engine is an open source tool, created by Microsoft, that helps generate ARM templates to deploy customer Kubernetes clusters in Azure.

The Open Service Broker API (OSB) project is an industry initiative to create an open, simple and generic way of creating services that can be consumed by cloud-native platforms like Kubernetes, Openshift and so on. Microsoft have released a preview of the Open Service Broker for Azure, which we are going to explore more in this article. First though, let’s understand what OSB and the broker for Azure actually gives us.

Earlier this month at Build Microsoft announced a new feature for ARM templates, the Terraform Resource Provider. If you’re not familiar with Terraform, it’s a way to define cloud infrastructure declaratively much like ARM templates, but one of its big benefits is that it works across cloud providers. If you’re interested in learning more about Terraform in Azure then take a look at my comparison of Terraform vs ARM templates. I’ve had access to the preview of this new feature for ARM templates and wanted to share my experience.

Some new functionality for ARM templates was announced at the recent Build conference, one of these was user-defined functions. What this lets you do is create re-useable functions that you can call inside your template. You’re still limited to using the built-in ARM functions inside your function, but you can use functions to help simplify your templates and reduce errors. Let’s look at an example, in a lot of my templates I am feeding in a “prefix” string which I then use for naming my resources.

If your looking to run Kubernetes in Azure then the Azure Kubernetes Service is what you’ll generally be looking at, it offers a semi-managed solution with PaaS based management nodes and is by far the simplest and easiest Kubernetes service to use in Azure. If AKS meets all your needs, then no need to read any further, but for some use cases, it may not. AKS is a new service, it’s not gone GA quite yet, and it is still missing some features like the ability to run Windows Containers, support for certain versions of Kubernetes, or maybe you don’t want to run Kubernetes at all and want Swarm or Mesos.

If you’re just getting started with containers and want to run them on Azure the number of options available can be overwhelming, especially with all the not so intuitive acronyms. There are many different options for hosting containers in Azure and all of them fill a specific need. Choosing the appropriate tool will all come down to understanding the benefits and use cases for each. In this post, we are going to take a look at the uses for each of the container hosting options in Azure.

Recently I came across a question on StackOverflow that was asking about how they could backup Azure Blob storage. They finished this question asking I can’t be the only one who needs to do this”. This struck a chord with me, as I recall feeling exactly the same when I had a need to do this. It feels like something that is so obvious, that should be built into the platform.