A web app in Azure actually consists of two things, an App Service Plan and an App Service, what is not always clear is why they are two things and what the purpose of the plan part is. The App Service is fairly easy to understand, it’s the actual instance of your web application, it’s where you deploy your code, set up SSL certificates, connection strings etc. The App Service Plan is a little less clear, when you create your app you select a plan and this determines what you pay, but it’s not entirely obvious what it is for, why it’s a separate things, or what you can do with it.

Monitoring your resources is vital to being able to detect issues or opportunities for performance improvements. When it comes to Azure the monitoring story can be a bit confusing with multiple different services seeming to offer similar or related solutions. In particular there is often confusion between two services, Azure Monitor and Log Analytics (part of the OMS suite). We’re going to take a look at these two services and when you would use them.

If you’ve been to any cloud or devops conference or meetup in the last year, you’ve probably heard about Terraform, the Infrastructure as Code tool from Hashicorp, it’s been one of the big talking points of the devops community for some time now. Terraform is a proprietary language for creating infrastructure as code deployment solutions, and one of it’s biggest selling points is that it supports multiple different cloud vendors including Azure.

Managed disks brought a number of benefits to Azure VM’s over thee previous method of manually managing storage accounts used for VM disks. One of these features that is often overlooked or misunderstood is snapshots. In this article we’ll explore what benefits snapshots give you, and how to use them. Before we delve into how to use snapshots, there are some key points to be aware of when using them:

When your learning a new technology, like Azure, documentation is key and find inaccurate, out of date or just plain wrong documentation is incredibly frustrating. Microsoft have taken an interesting approach to this issue by storing all Azure (and many other MS services) documentation sources on Github and allowing the community to submit pull requests. What this means is that if you spot an error in a document or you feel it needs updating you can make this change your self and get the document updated very quickly, rather than waiting for product teams to spot the issue and make corrections.

Don’t forget to check out the other parts in this series: Part 1 – Version Control Part 2 – Testing Part 3- Build Initially this might seem like a bit of an odd topic, “Build” in a software development process usually refers to the process of compiling an application and preparing it for distribution (creating MSI files etc.). Whilst we are writing infrastructure as code, there’s no compilation involved, no creating of installers, so what are we doing here?

Historically Azure Network Security Groups (NSG’s) have only allowed you to enter a single value for things things like source or destination IP and source or destination port. This has meant that for complex setups you end up with a very large amount of NSG’s. This is especially if you are trying to filter a large amount of IP’s, for example the Azure Data Center IP ranges, which is a common requirement if you want to restrict outbound access but allow access to PaaS resources.

Back a few years ago it was not uncommon to see a requirement for VMs to be rebooted when maintenance to apply updates to the underlying host was required, every few months. Fortunately this is now mostly a thing of the past, with most updates now being applied using Azure’s in place upgrade process which just pauses for a few seconds while the VM whilst the host is updated. Up until recently I had not seen a maintenance window that require VM reboots for over a year.

Pester is a versatile testing framework built using PowerShell. In this article we are going to look at using Pester to audit our Azure infrastructure for security compliance. We’ve previously discussed using Pester to test Azure resources in our infrastructure pipeline. In that article we used Pester to run against a deployed Azure environment to check what we thought we had deployed had actually been deployed. In this article we’re going to take this a bit further and look at using Pester to validate that we have setup our environment in a secure manner and look for areas of concern, essentially a security audit.

Don’t forget to check out the other parts in this series: Part 1 – Version Control Part 2 – Testing Part 3- Build In part 1 of this series we took our first step in building an Infrastructure as code pipeline by moving our infrastructure files into source control. Now that we have this code in a central repository we can use this as a base for the next steps in this process.