Microsoft announced some changes to their Visual Studio Team Services production today, primary of which was a name change. VSTS now becomes Azure DevOps, which is made up of Azure Repositories, Azure Pipelines, Azure Boards, Azure Test Plans and Azure Artifacts. This update also included a new UI design and URLs. The full announcement can be found here The most exciting part of this for me, however, was the announcement of unlimited, free, Azure Pipelines for building open source projects hosted on Github.

Managed Identity (MI) service has been around for a little while now and is becoming a standard for providing applications running in Azure access to other Azure resources. We’re going to be taking a look at using MI in a few areas in the future, such as Kubernetes pods, so before we do, I thought it was worth a primer on MI. Managed Service Identity has recently been renamed to Managed Identity.

It’s been a while since I have posted in my series intended to help those coming from AWS to get to grips with Azure; however, I was reminded a few days ago about the post I planned to do on networking. If you’ve not yet read them, parts 1 and 2 can be found here: Part 1 – Identity Part 2 – Virtual Machines and IaaS When moving from AWS to Azure networking can seem reasonably straightforward, as there are a lot of similar concepts, however, there are enough differences to trip you up along the way.

Ever since they were released, ARM templates required you to supply the name of the Resource Group you want to deploy to as part the deployment command. This restriction meant that the Resource Group always needed to exist before running your deployment. I mentioned in my article on Terraform that one of the advantages of this is that you can create the resource group as part of your deployment template, no need to create it separately.

At some point, I imagine most people working with Azure VMs have hit issues with being able to connect to services running inside a vNet. A lot of the time these issues boil down to the configuration of Network Security Groups to allow traffic into the VM. The process of troubleshooting these issues and determining which NSG and which NSG rule is at fault can be time-consuming, especially with complex networks.

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.