An availability zone is a unique physical location within one Azure region, and provides high-availability for your application and infrastructure. Each zone is independent and has physically isolated power, cooling, and networking from other zones within the same region.

Different Azure services have varying levels of support for availability zones. Some will automatically replicate between zones, while others will require you to choose the zone to connect to.

Availability zones aren’t available within all Azure regions - in fact, currently there are only 10 regions across the United States, Asia and Europe that support availability zones:

• Central US
• East US
• East US 2
• West US 2
• North Europe
• UK South
• West Europe
• France Central
• Japan East
• Southeast Asia

On the other hand, an availability set is a concept that only applies to virtual machines. A set allows you to isolate virtual machine (VM) resources from one another when deployed, meaning your VMs will run across multiple machines and racks. This will help to avoid a hardware failure bringing down your entire application, and also means that outages from Microsoft updates won’t cause your application issues.

Unlike an availability zone which applies at the data centre level, an availability set only applies within the same data centre.

As of September 2019, in most cases you can now retry a failed stage without the need to retry the whole pipeline - but there’s a catch. You’ll need to enable the Multi-stage pipelines preview feature, if you haven’t already. Note that this still doesn’t allow you to retry failed steps within a stage - rather it relies on the new multi-stage support to allow you to retry a collection of steps within a stage.

You can check if this is enabled by clicking your avatar in the top-right corner of the Azure DevOps portal, and then “Preview features”. Select “for this organisation [<your organisation name]” from the drop-down menu at the top of the screen, and scroll down until you see “Multi-stage pipelines”. If this is toggled off, you’ll need to turn this on before you can retry failed stages - you will need administrator rights to change it though.

Once you’ve enabled this, navigate back to your release pipelines and you should see the ability to re-rerun individual stages that fail throughout your pipeline.

Note that as this is still in beta, there are some limitations. Perhaps one of the biggest is that you can’t retry stages that are explicitly cancelled - only those that fail as a result of the task being run having an error can be retried today.

Microsoft offers its own Azure CDN solution, or you can use Akamai or Verizon. However, for the purposes of this tutorial we’ll be using Cloudflare - a third-party vendor who offers a free tier that should meet most people’s needs. Cloudflare can cache files based on the caching headers you apply when you upload files to blob storage, or you can apply default caching values. As a side note, Cloudflare also offers other services such as DDoS protection and edge workers.

Note that you’lll need to have your own domain name for this to work - you need to associate a custom domain name with the blob storage account. To use Cloudflare services, you also need to point your domain to Cloudflare’s name servers.

Setup Cloudflare
If you have a Cloudflare account already, you can skip this section. Otherwise, create an account at Cloudflare. The free account will be fine for this tutorial.

Once your account has been created, click “Add a site” and follow the instructions to verify and add your domain to Cloudflare. If you want to use a sub domain (eg. cdn.example.com) for the Blob Storage custom domain, this should be the root domain (eg. example.com).

This will also require changing your domain’s nameservers, so you’ll require admin permissions with your DNS registrar.

Getting started
If you haven’t already done so, create an Azure Storage resource by clicking “Create a resource” in the Azure Portal. Search for “storage account”, and choose the Microsoft service by clicking “Create”. Fill in the settings as required for your storage account.

Once your account has been provisioned, head to the “Storage accounts” tab and choose the account you want to setup.

Create a custom domain
The first step in setting up Cloudflare with Blob Storage is to map it to a custom domain name that you own (such as example.com). In the Azure Portal for your storage account, go to “Custom domain” under the “Blob service” tab.

You should see some Microsoft instructions about configuring a CNAME record with your DNS provider, which should now be Cloudflare. Follow these steps first, by logging into your Cloudflare account and adding the CNAME record to validate your ownership of the domain with Microsoft. Note that this will be the URL that people will see and use when accessing your content, so CNAMEs such as cdn.example.com or static.example.com are commonly used.

In Cloudflare, make sure the proxy status for your domain or subdomain is set to DNS only. If proxied is enabled, verification with Microsoft will fail.

Once you’ve added the required record to your domain name, enter the URL in the text field below in the Azure Portal. Click “Save”, and if the DNS changes have propogated (this can take up to 24-48 hours depending on your provider and configuration) then the custom domain should be added successfully. Otherwise, try again later once the changes have propegated.

Enable the Cloudflare proxy
Once you’ve verified your domain, you can enable caching on Cloudflare. Go back to your domain or subdomain in the DNS tab, and click the cloud icon until it’s orange and “Proxied” shows.

Then go to “Caching” and set the “Caching level” to standard.

Finally, by default Cloudflare will only cache certain types of files. If you’re serving predominantly static HTML or CSS files, this might be OK but if you’re sending other content types such as JSON you’ll need to add a page rule so that the files are cached.

Go to the “Page Rules” tab, and choose “Create Page Rule”. Enter the domain/subdomain you’re using for blob storage (eg cdn.example.com) and then click “Add a setting”. Choose “Cache Level” and select “Cache Everything”. This will now cache everything served on this domain, using either the Cloudflare defaults or the cache-control headers applied to the individual files.

Upload files to Blob Storage with cache-control headers set
Now, upload some files to your blob storage account in the Azure Portal. Depending on how you upload the files, you’ll need to set the cache-control headers. The .NET SDK has built-in support, or you can use these instructions to use PowerShell.

Conclusion
By enabling Cloudflare for your domain, you’re now saving money each month on bandwidth costs (Cloudflare will only request resources once the cached copy expires) and protecting yourself from a variety of security attacks.

DevOps is a paid product (although there is a free tier available) that many software development companies use - particularly those within the Microsoft ecosystem. It used to be called Visual Studio Team Studio (VSTS).

DevOps is made up of 5 core areas of functionality:

• Boards: Boards are used to track your teams work, and work best for teams using Agile methodologies to deliver work. Cards (or issues) can be created and tracked on boards, and linked to work as it gets delivered and released. Think of this as an equivalent to the likes of Atlassian Jira.
• Repos: Employ version control for your code by creating a Git repository within DevOps. DevOps supports Git repositories in a similar manner to the likes of Github and Bitbucket.
• Pipelines: Create continuous delivery pipelines that allow you to build your app and then release it automatically. Run your tests, deploy your code and store your build artefacts using Pipelines - DevOps has a whole host of tasks supported out of the box, or you can easily create your own.
• Test Plans: Depending on your account level (paid or free) you can use test plans to track the progress of your test activities including both manual and automated tests, and easily analyse reports including passed/failed tests and defects raised.
• Artifacts: Finally, DevOps will store your artifacts that are generated as part of your pipelines. This allows you to easily rollback to a previous version of your app if required, or the ability to re-deploy to new servers if required. You can also create package feeds with public sharing now in preview for public projects.

The icons - which are made available as images - can be generated for both build pipelines and release pipelines on the Azure DevOps website. They change based on the outcome of the latest run, allowing you to place them in places such as your project’s Readme files.

They aren’t particularly flexible, but you can choose the branch and scope of the success/fail status.

How to generate a badge icon

Login to the Azure DevOps portal. Navigate to Pipelines, and then choose the release or build pipeline that you would like to generate an icon for.

In the top right-hand corner, select the three dots and then choose “Status badge”.

This brings up a modal window that allows you to customise the badge, and choose a branch, scope for the status (pipeline or per job), and then a URL is generated for the image.

Microsoft also provides the markdown text which allows you to immediately copy and paste the badge into a markdown file such as your project’s Readme file.

Love it or hate it, Jira is among other things one of the most widely used issue tracking tools, and in July 2019 Microsoft rolled out a new Jira app that can be used to sync issues between DevOps and Jira, enabling end to end traceability between both platforms from when an issue is reported to when a deployment is released fixing it.

There are a number of limitations. At present, the official plugin doesn’t support DevOps repositories. Only GitHub repositories are supported, although Azure Repos support is planned soon. Build information also isn’t available - the app will only show deployments made in the Jira issue.

The integration also doesn’t change much from DevOps - there’s no UI integrating with Jira reporting or issues, and you can’t easily view a summary of Jira cards from pull requests commit messages.

That said, to get started, you’ll need to:

• Be a Jira administrator, or have the ability to request a Jira app be installed within your organisation’s Jira installation
• Use Jira Cloud - on-premise installations aren’t supported
• Use GitHub for your source code

It’s also worth noting that for now this app only supports showing deployment traceability in Jira - other information such as build numbers or tasks will not show.

Getting started

First you’ll need to install the Azure Pipelines for Jira application, available for free in the Atlassian marketplace.

Then, once you’ve installed the app you’ll be prompted to add your DevOps organisation. Click “Add organisation”, and you’ll be prompted to enter your credentials. It should then list all your organisations in a table view.

Enabling support in DevOps

Now we need to add the Jira integration to our DevOps release pipeline. Open the DevOps portal, and navigate to your project and release pipeline.

Click “Edit” on the release pipeline you’d like to integrate Jira with, and then click “Options”. Click “Integrations” and you’ll see the option to “Report deployment status to Jira”.

Check the box, and you should see your Jira software cloud account listed from the previous step. If you don’t see it, check your Jira account to make sure you’ve added the organisation successfully in the DevOps app.

You’ll also see the ability to map your stages to a set list of deployment types. These deployment types are set by Microsoft, and you’ll have to pick from the list and match them as best you can to your stages. At present, there are 5 deployment types:

• Production
• Staging
• Testing
• Development
• Unmapped

These deployment types then show in your Jira cards as commits which contain your story numbers move through your deployment process.

Referencing Jira issues

The app works by searching your commit history (both commit and pull request messages) for Jira issue keys. If you’re not sure about how to find an issue key see this article on Atlassian’s website.

To enable the linking, once you’ve followed the above steps simply add the issue number into your commit messages when you write them. We tend to stick to the format “[ISSUE-KEY] Fixed an issue with something” as the short message title, but the exact format is up to you.

The app then searches your commit history and will automatically update the issue when you create and deploy a release in your pipelines. It’s that simple.

First, you’ll need to login with your account to the DevOps portal. Choose the organisation that contains the project you want to delete from the left-hand sidebar, and then select the project you want to delete.

Then, once you’re on the homepage for the project you wish to delete, click “Project Settings” in the bottom left-hand corner. If you don’t see this option you may not have the required permission to manage the project.

Navigate to the General > Overview screen in Project Settings and scroll to the very bottom. A big red “Delete” button should appear at the bottom.

Click “Delete” and you’ll be asked to enter type your project name to confirm the deletion. Type the name of the project in the textfield, click “Delete” and your project removed.

Note that it won’t actually be deleted immediately - it will be placed in a temporary recycling bin for 28 days before being permanently removed. This gives you time to change your mind about the deletion, for example if you removed the wrong project or need access to the information again. After the 28 days the information will be permanently erased.

What you’ll need

In order to follow along, you’ll need to make sure you:

• Install JetBrains Rider (free 30-day trial available here) 2019.1 or later

Getting started

First you’ll want to install the Azure Toolkit for Rider. Open Rider then navigate to Preferences (JetBrains Rider > Preferences on a Mac) and Plugins.

In the Plugins screen, go to the Marketplace tab  and search for “Azure Toolkit for Rider”. Click install.

This will now allow you to manage and deploy a whole bunch of Azure services from within Rider, such as App Services and SQL databases.

Let’s open a new Functions app. Now that you’ve installed the Azure Toolkit, a new template for AzureFunctions has been added to your new project window. From within Rider, click File > New and choose Azure Functions from underneath the .NET Core section.

Enter a solution name, project name and choose a directory and language, and then click Create. If you’re using this as a test project, you can probably leave these values as is.

Running the Functions app

And that’s almost all there is to using Functions apps in Rider now! The toolkit will automatically detect that it’s a function app, and provide the necessary scaffolding to allow you to run and debug the app.

Gone are the days of hacking the project settings and configuration to make it work - it’s a seamless experience now.

To verify that the config is correct, click the run configuration in the top right-hand side of Rider, and edit the configurations. You should see a default Azure Functions host configuration, complete with all the settings required to run a functions app. You can see in this example that the function will run on port 7071, and pause on error.

Even better, is that if you don’t have the required Functions command line tools to run the app (which Rider relies on behind the scenes) then you’ll even get prompted to install them - which Rider will do automatically on your behalf. You’ll also get prompted if your tools are out of date.

And that’s how easy it is now to get started using Azure Functions in Rider!

I say currently, because in the next update to the Azure Toolkit plugin for Rider Functions support has been added. This’ll make running and debugging function apps a breeze.

Until then though, here’s how you can run a functions app from Rider.

How to run Azure functions in Rider

First, you’ll need to install the function CLI (see creating an Azure function for the Mac).

Then, open your functions app in Rider by selecting the project or solution.

Create a Properties folder in the root directory if you don’t have one already, and then inside of that create a new JSON file called launchSettings.json.

Inside the JSON file, place the following object:

1
2
3
4
5
6
7
8
9

{
    "profiles": {
        "functions": {
            "commandName": "Executable",
            "executablePath": "func",
            "commandLineArgs": "start --port 7071 --pause-on-error"
        }
    }
}

You should see Rider now refresh, and add the configuration profile to your configurations with a little rocket icon. Click run, and your function app should start running within Rider.

Note that debugging is a little tricker for now. On Windows, once your function app is running you can go “Run” > “Attach to process” and choose your function app to listen to. But on a Mac, this has had mixed results.

In February 2019, Microsoft announced a new service called App Configuration - which, currently in preview - allows you to easily centralise your app settings across multiple resources.

Why is App Settings a problem?

App Settings are great - if you only need those settings for one resource (eg. an app service). But if you’re working with, say, a microservice that might be made up of many resources including an app service and maybe a functions app that all share similar configurations, keeping track of what settings were made where can quickly become problematic.

Amongst other things, there’s no easy way to do things like point-in-time replays of settings, so you can see what changed or keep the settings the same if you need to rebuild or deploy a specific version of your app.

What does App Configuration offer that App Settings doesn’t?

App Configuration is a fully managed service that offers the ability to store all your app configuration values in one location, with the ability to compare settings at specific times and with specific labels.

Operating in a similar fashion to Key Vault, it’s a separate resource from your app service (although you can configure it immediately by going to the new preview tab in your app services), and there are a number of SDKs available to integrate with it for .NET core,  .NET and Java.

You can think of App Configuration as a counterpart to Key Vault for properties that don’t need to be stored as secrets. Connection strings would likely still go in Key Vault, but properties that aren’t secrets should be stored in App Configuration.

First you’ll need to setup a connection string which you can find under the “Settings” → “Access Keys” section of your App Configuration resource. Then, within App Configuration, you set a number of key value pairs, which you can then access in a similar fashion to the way you get environment variables in App Settings:

1
2
3
4

var configBuilder = new ConfigurationBuilder();
var config = Environment.GetEnvironmentVariable("YourKeyNameFromAppConfiguration")
configBuilder.AddAzureAppConfiguration(config);
var config = configBuilder.Build();

You can also import and export settings easily, and can use JSON, YAML or a Properties file. You can also export the settings for a specific time and date.

At present, because the service is in preview there are no additional charges. Microsoft hasn’t yet stated its intentions for charging for this service, but given the similarities with Key Vault (which is a paid service) it’s easy to see how a similar model could apply if they decided.

The JsonToken documentation for Newtonsoft is relatively sparse - in part because once you understand it, it’s a relatively simple concept.

Effectively, when you’re attempting to deserialise a string representation of a JSON object, such as in the ReadJson method of a custom JsonConverter, the JsonToken represents each element or component (token if you prefer) of the object as it’s deserialised.

So for example, if you have the following JSON and implement the ReadJson method:

1

{	"message": "Hello world"}

When you first get the reader.TokenType value you’ll get JsonToken.StartObject back - this represents that the { implies that you’re first reading an object element.

If you were to then call reader.ReadAsync(), and then subsequently request the reader.TokenType again now you’ll get JsonToken.PropertyName in response. This is because the next element within the JSON string is the property name (in other words, the “message” key).

Lastly, if you were to call reader.ReadAsync() for a third time, you’d get back JsonToken.String as the value of the property is a string (“Hello world”). NewtonSoft will try and parse the value into a representation of a type - so for example, if that was a number, you’d get back Integer of Float, and if it was a Boolean you’d get back Boolean.

What are the key differences between versions?

Version 1 of the runtime was introduced back in 2016, when functions were first announced. At launch it supported JavaScript, C#, Python and PHP.

In late September 2018 Microsoft made the Functions 2 runtime generally available and with it bought a number of significant development, deployment and performance improvements including the ability to use the runtime anywhere - on a Mac or Linux machine too! It’s worth noting that as of March 2019, Python support for Functions 2 is still in preview.

There were significant under the hood changes made to improve performance - and .NET Core 2.1 support was added, alongside a move to .NET Core powering the functions host process instead of .NET.

Big changes were made to the way that bindings work - as part of 2.0 they became extensions instead of being bundled into the runtime itself (aside from HTTP and timer support which are deemed core to the experience). This means that some bindings didn’t make it over yet to the new 2.0 runtime - your mileage may vary, but the Microsoft bindings docs have a clearer comparison between the two.

There are also a bunch of new integrations with Functions 2 - for instance, Application Insights is supported with minimal configuration required, while you can easily use deployment centre to add code from other sources such as Github repos into your functions app.

How can I tell what runtime I’m using?

If you’re running a functions app on a Mac or Linux machine - there’s a fair chance you’re using the 2.0 runtime, as that’s what the functions command line tools support. You can verify this by opening the host.json file within the root directory of your app, which should look something like this:

1

{    "version": "2.0",    "extensions": {      "http": {        "routePrefix": ""      }    } }

The version field directly references the version of the functions runtime you’re using. If it says 2.0, you’re using version 2 - if it’s 1 or missing completely, you’re on the first version of the runtime.

Similarly, you can also view the runtime for your app through the Azure Portal - open your app in the portal, then navigate to “Function app settings” where you’ll see the below “Runtime version” setting.

In short, there is a difference. You can think of the f_unctions app_ as if it refers to a workspace that contains one or more functions. It’s essentially a wrapper (or in .NET terms, project), holding all your Azure functions in one place and allowing for easy deployment and management of them as one.

On the other hand, a function refers to a single, isolated piece of functionality. Typically in .NET this results in a class that performs one discrete piece of behaviour.

There are a number of ramifications for function apps that don’t apply to individual functions. For instance, it’s at the function app level that the pricing plan, runtime version and more are set in Azure. Microsoft refers to this as providing the execution context for your functions.

So keep in mind that when you first create a function resource in the Azure Portal, you’re creating a functions app. Once you navigate inside that resource, you can then start to add individual functions.

Dive deeper into Azure AD service principals and managed identities in our new detailed ebook about Azure AD

What is a service principal or managed service identity?

Lets get the basics out of the way first. In short, a service principal can be defined as:

An application whose tokens can be used to authenticate and grant access to specific Azure resources from a user-app, service or automation tool, when an organisation is using Azure Active Directory.

In essence, service principals help us avoid having to create fake users in Active Directory in order to manage authentication when we need to access Azure resources.

Stepping back a bit, and its important to remember that service principals are defined on a per-tenant basis. This is different to the application in which principals are created - the application sits across every tenant.

Managed identities are often spoken about when talking about service principals, and that’s because its now the preferred approach to managing identities for apps and automation access. In effect, a managed identity is a layer on top of a service principal, removing the need for you to manually create and manage service principals directly.

There are two types of managed identities:

• System-assigned: These identities are tied directly to a resource, and abide by that resources’ lifecycle. For instance, if that resource is deleted then the identity too will be removed

• User-assigned: These identities are created independent of a resource, and as such can be used between different resources. Removing them is a manual process whenever you see fit

One of the problems with managed identities is that for now only a limited subset of Azure services support using them as an authentication mechanism. If the service you use doesn’t support MI, then you’ll need to either continue to manually create your service/security principals.

So what’s the difference?

Put simply, the difference between a managed identity and a service principal is that a managed identity manages the creation and automatic renewal of a service principal on your behalf.

Update 31/1/20: If you’re using Azure Web Apps, check out our new post on using managed identities with deployment slots

Why would you use a variable group instead of the key vault task? If you know you require access to the secrets from across multiple stages within a pipeline using a group allows you to easily manage access without having to include the task in every single stage by scoping the group to the release or specific stages.

However, if only one stage requires access to the secrets it might be easier to just include the task in that particular stage and follow our previous post.

Getting started

First you’ll need to setup your key vault so that your service principal or managed identity has GET access to your vault. Then, follow our previous post on creating a variable group with a key vault to setup DevOps for this integration.

Once you’ve done the above, it’s time to get started. Navigate to your release pipeline in Azure DevOps.

Connecting the variable group

From your release pipeline, click “Edit”. Go to the “Variables” tab at the top of the screen, and choose “Variable groups”.

Select the variable group you created in the above section, scope it to either the entire release or a stage of your pipeline (depending on where you need to have access to the secrets, keeping in mind the more restricted you can make it the better from a security perspective) and click “Save”.

Now from within your tasks, if you need to reference the secrets you can use the $(your-variable-name) syntax. For instance, in the Azure Function App Deploy task, if we wanted to specify an app setting under “Application and Configuration Settings” we could use the following syntax:

1

-NOTIFICATIONHUB_CONNECTIONSTRING $(your-connection-string-secret-identifier)

The benefit of this is that the syntax is identical to that used with the key vault task (they both set the secrets as task variables) so if you need to, you can swap between using a variable group or key vault task with ease.

Summary

In summary, this is an alternative approach to using the key vault task in a pipeline. Depending on your needs, this may be a better approach than the other lesson, but mileage may vary.

In most cases, it’s best to rethrow the existing exception, such as below:

1

try {	var networkResponse = await someNetworkService.GetAllPosts();}catch (Exception ex){	Log.Warning("An exception occurred", ex);	//Now lets rethrow this same exception	throw;}

By doing so, you ensure that the original stack trace for the exception is maintained. If you were to instead do something like this:

1

try {	var networkResponse = await someNetworkService.GetAllPosts();}catch (Exception ex){	Log.Warning("An exception occurred", ex);	//Now lets throw ex again	throw ex;}

You’ll now see that the exception stack trace only goes as far back as this line of code - not to the raw source of the exception.

In short, that’s why its normally better to just throw again, instead of specifying the exception when re-throwing.

Want to secure your Azure DevOps application secrets in Key Vault? Find out how in  our short e-book guide on Amazon

Setting up your Azure Key Vault

Before you can add the secret to your pipeline, you first need to make sure that there’s a key vault setup in Azure, and that you have given either your pipeline managed service identity or account GET access to the secrets within the vault. Note that you need to ensure this is set under your key vault’s “Settings” → “Access Policies” section.

If you haven’t already, add your secrets into the “Secrets” section, and take note of the names used for the secrets - you’ll need these a bit later on.

Adding the Azure Key Vault pipeline task

Now that you’ve got your secrets stored and accessible from key vault, it’s time to configure the Dev Ops pipeline. Open the visual pipeline editor for your pipeline by clicking “Edit”, and choose the stage in which you need access to the secrets.

Then, click the “+” button next to “Run on agent” (or whatever the first step of your pipeline may be) and search for “Azure Key Vault”. Note that you’ll want to add the “Download Key Vault Secrets” task that appears first - this is the official task from Microsoft.

Then, click on the new “Azure Key Vault” task you just added to your pipeline, and set a display name. Choose the Azure subscription in which you created your key vault, and then select from the “Key vault” dropdown list the name of the key vault you stored your secrets in.

If you can’t see it listed, it’s possible you managed service identity doesn’t have the correct permission, so be sure to check it’s been added to your key vault with GET permission.

Now drag the key vault task up your pipeline task list (if applicable) so that it runs before any other task that requires a secret stored within your key vault.

And that’s it!

Accessing a Key Vault secret from other tasks

Now other tasks can access the secrets, by using a task variable. The key vault task will make all your secrets available using the $(<your secret name here>) syntax, such as $(api-secret).

Summary

This is just one of the various ways that you can access key vault secrets from a Dev Ops pipeline task. Stay tuned for more posts where we explore other ways of accessing the secrets in tasks.

If you want a more in-depth guide and comparison between alternative approaches to storing secrets in DevOps, you can also get our book on Amazon today.

What is Application Insights?

In short, Application Insights is a performance and monitoring tool that forms part of the Azure Monitor suite. It allows you to access detailed telemetry on requests made to your function, while observing real-time performance and failures. It works across App Service apps, Azure Functions and more - practically anywhere you can install the available App Insights SDKs.

You can find the full pricing information here, but you effectively get charged per GB of ingested data (5GB included free per month).

How can I enable this for my Azure Function App?

For Azure Functions, it’s super simple to enable App Insights. You don’t even need to add the SDKs - Microsoft handles that for you.

First, you’ll need to create an Application Insights instance. Open the Azure Portal, click “Create a resource” and search for “Application Insights”.

Enter a friendly and unique name for your instance, and depending on the language you write your functions in, choose General or Node.js for the “Application Type”.

Choose a subscription and resource group (ideally matching those of your Azure Function app) and a location. Note that App Insights is only supported in a limited number of regions worldwide, so you might need to choose a different region to that of your functions app.

Once that’s been created, open the App Insights resource. On the “Overview” page, you’ll see in the top section an “Instrumentation Key”. Copy this - it’s essentially the identifier that will allow you function app to report data back into this App Insights resource.

Now navigate to your function app in the Azure Portal. Select the app name in the sidebar, and choose “Platform Features” on the right-hand side of the screen.

Next, open “Application settings”. Scroll down until you see the “Application settings” header. At the bottom of this section, you’ll see a “Add new setting” button - click this to add a new row.

Now in the “App Setting Name” column, type “APPINSIGHTS_INSTRUMENTATIONKEY”. In the “Value” column, paste the “Instrumentation Key” that we copied in the earlier step from your App Insights resource. Scroll back to the top of the page, and click “Save”.

Summary

And that’s it! That’s how easy it is to enable App Insights for Azure Functions. If you want to see metrics coming through straight away, navigate to your App Insights resource and click “Live Metrics”. Make an API request to your function (assuming it’s HTTP based - otherwise trigger it however you can) and you should see the request come through instantly.

Getting started

Before you can create a function, you’ll need to install the Azure Function command line tools. But before you can continue, you need to make sure that you have installed Brew. If you’re not familiar with it, Brew is a package manager for the Mac - similar to NPM for Node.Js projects.

Once you’ve installed Brew, make sure you have the latest .NET Core SDK installed. If you’re not sure, open Terminal and run:

1

dotnet --version

If you do get a version back, make sure it’s at least 2.0.0 or above. If you get an error, you’ll need to install it using the following Brew commands:

1

brew tap caskroom/caskbrew cask install dotnet

Run the same dotnet version command again to ensure the install was successful.

Now we need to install the Azure Function Core Tools:

1

brew tap azure/functionsbrew install azure-functions-core-tools

Once the install has finished, you’re now ready to go creating your first function!

Creating the function app

Now that we’ve got all the dependencies installed, it’s time to create our function app. Open Terminal, and navigate to a directory where you’d like your app to be created (in our case, we’re going to create it from the root Documents folder).

1

cd ~/Documents

Now let’s get started creating the app! First lets initialise the project:

1

func init MyFirstFunctionApp --source-control true --worker-runtime dotnet

This will create a folder called MyFirstFunctionApp inside your Documents folder. It will be initialised as a git repository (the source-control parameter) and have a dotnet runtime. If you’d prefer a Node.Js function or a Python function, you can replace dotnet with either node or python respectively.

You’ll now have your project - but at this point, it’ll be empty with no functions. To add your first function, we need to run the following command to generate a function called MyFirstFunction:

1

 func new --name MyFirstFunction

It’ll then ask you what type of template you’d like to use. A template is effectively a trigger - what will cause your function to start running? We’ll choose #2 (HttpTrigger) for now, as this will enable you to easily run your function via Curl, Postman or by visiting a page in your web browser. You can provide this in the previous command as —template, or select from the list.

You’ll now have your first function and function app created! You can run it by entering:

1

func start

Once it’s started, you should see the a message with the function URL, like this:

The sample function expects a name parameter to be provided, so open up your web browser and go to http://localhost:7071/api/MyFirstFunction?name=Bob. You should get a response like:

1

Hello, Bob

Summary

So that’s how easy it is to get started with an Azure Function app on a Mac. Microsoft has done a lot of work around the tooling to make it as straightforward as possible.

What is a service bus queue or topic?

When configuring a service bus, you have two options for configuring how messages are processed - a queue, or a topic.

Lets start with a queue. A queue has a one-to-one relationship between each message and its consumer, and is a way to ensure reliable first-in-first-out (FIFO) delivery to one processor from many sources. For example, you might have one WebJob that processes requests that get placed in the queue from many different sources. In most cases, the processor (or receiver) receives the messages in the same order that they were placed on the queue. The key to a queue is that each message from the queue is only ever processed by a single consumer.

In contrast, a topic follows the publish/subscribe pattern and can have many consumers who can each subscribe to receive notifications when a message is sent to the topic. In effect, this means you can have a one-to-many relationship between messages and consumers although this does depend on how you configure your filter rules (you can opt to have each message delivered to only 1 subscriber if you wish).

What’s the difference?

In effect, the difference between a queue and topic can be described as follows:

• A queue can only be listened to by one consumer, whereas a topic can have multiple subscribers.
• Topic subscriptions can enable powerful filtering capabilities, such that you can define certain parameters that messages must meet in order to be copied into a subscriptions virtual queue. This can be handy if you need to handle different types of messages, or messages with variable data structures in the same topic.
• Topics can be more scalable than queues, as more than one consumer can listen for messages. If you need to scale a queue, you’re still limited to having the one consumer listening, so aside from horizontal scaling you’re out of luck.
• Both queue and topic subscriptions support PeekLock and ReceiveAndDelete modes, so you can ensure a message is processed before being dismissed if required.

When should I use a topic or queue?

This is a trickier question to answer, and ultimately depends on how much you’re willing to spend on your service bus. If you’re using the basic tier, then you only have the one option - queues. Topics are only supported in the standard and premium tier.

By moving to the standard or premium tier, you incur an hourly base charge as well as the per million operations fee which is charged in the basic tier.

Pricing aside, it also depends on the type of data that you’re ingesting into your service bus. If its time-sensitive and high volume, topics would be the ideal approach as you can more easily scale your downstream consumer to handle the larger volume of messages.

If on the other hand you receive a relatively stable or low volume of messages which aren’t necessarily time-critical (ie. they may sit on a queue for some time until the processor reaches them if the load is higher than anticipated) then you can probably get away with using a queue.

Want to secure your Azure DevOps application secrets in Key Vault? Find out how in  our short e-book guide on Amazon

What is a variable group?

A variable group is a logical collection of environment variables (or properties) used throughout your build and/or deployment pipelines. They are essentially key value pairs, that can include things like API keys, database connection strings or configuration items such as downstream API endpoint URLs.

Variable groups can store both plain text variables and secrets, which should never be committed into your source code repository. Note that if you want to use DevOps’ Azure Key Vault integration, you’ll need to create a separate variable group as you can’t mix and match Key Vault and DevOps variables in the same group.

How do I create one?

Creating a variable group is simple. Login to Azure DevOps and navigate to “Pipelines” > “Library”. You’ll see in the top navigation bar the option to “+ Variable Group”. Clicking that will take you to a “New variable group” screen, that asks for a number of properties:

• Variable group name: A friendly name used to refer to your new variable group. Use something that has meaning to you and the types of properties that will be stored within the group (ie. My App - Production)
• Description: Provide a short description that describes a bit more about the types of variables that should be placed within this group (eg. This group contains build settings and environment variables for production builds only)
• Allow access to all pipelines: Enable this toggle to ensure that you can access all the variables from all of your pipelines. If you don’t enable it, you’ll need to authorise pipelines defined in YAML manually in order to let them access your properties.
• Link secrets from an Azure key vault as variables: Enable this toggle if you want to use Azure Key Vault to store your secrets instead of DevOps. Note that by enabling this, you’ll need to then provide key vault connection details, and enter your secrets via the Azure Portal instead.

If you left the key vault integration disabled, you’ll now be able to click “Add” below the “Variables” section to begin creating new properties. Each property can have a name and a value, and can be marked as clear text or secret by clicking the padlock icon at the end of each row.

If you need to customise security permissions, click “Security” at the top of the screen. This will bring up a modal window where you can add or remove user groups from being able to access this variable group.

Once you’re done, hit “Save” and your variable group will be persisted.

How do I use it?

If you selected “Allow access to all pipelines” when creating the variable group, linking it with your build pipeline through the DevOps website is simple. Navigate to the pipeline you want to link the group with, click “Edit” in the top-left corner and then click “Variables” underneath your pipeline name.

You should see on the left-hand side “Pipeline variables” and “Variable groups”. Navigate to the latter, and click “Link variable group”. This brings up a modal that lists all the variable groups that your role has access to - if you can’t see a group that you know exists, check to make sure you have set the right permissions in the “Security” window for that group.

Choose the group you want to link with the pipeline, and then the scope that the group applies to. If the variables are used throughout the pipeline, then you can choose to make it visible to the entire release, or if you know only a few scopes require access you can also choose specific scopes.

Click “Link” and you’ve now made the variable group be accessible from your pipeline!

Alternatively, if you’re using a YAML file to describe your pipelines and builds, you can also add a variable group by adding the following section in your YAML file:

1

variables:- group: your-new-variable-group-name

One thing worth noting is that when you run a pipeline, DevOps will create an immutable snapshot with the values of the variables within your group so that your release remains in the same state. This ensures that it isn’t influenced by future changes or modifications that you might make to the values, and means you can redeploy a release later if needed.

Summary

Variable groups can be powerful tools for logically grouping properties and secrets that you need for build pipelines, and are simple to configure and use.

Want to secure your Azure DevOps application secrets in Key Vault? Find out how in  our short e-book guide on Amazon

By using Azure Key Vault you get the same enhanced data protection that your other cloud apps can enjoy including activation and expiration dates, and the DevOps integration allows for the centralised management of keys used across apps or pipelines. Keep in mind if you decide to use key vault, you will be charged according to the Azure Key Vault pricing for storing your secrets.

Setting up Key Vault access in Azure DevOps

Getting started is easy. Open Azure DevOps, and navigate to the project you wish to integrate with. Open the Pipelines section, and then go to Library.

If you already have secrets and values stored in an existing library, the easiest way to integrate with key vault is to create a separate variable group. If you don’t, you’ll get a message warning you that when you enable key vault in your existing group, it’ll blow away all your existing variables saved within the group. This is because you can’t use key vault variables side by side with Dev Ops variables within one group.

Open the new variable group, and you should see a toggle to link secrets from an Azure key vault as variables. Turn that on, and you’ll see the option to set the Azure subscription to be used, and a field to specify a key vault name.

You’ll need to ensure that you’ve previously setup a connection to your Azure subscription within Azure DevOps, and added an Azure Resource Manager service connection using an Azure Service Principal to the resource group where your key vault is located. If you haven’t, the management links next to each field will help you to setup these connections.

Once connected, pointing DevOps to your key vault is as easy as choosing the correct subscription from the drop down list and then selecting your key vault by name in the second drop down. If your service principal doesn’t have get and list secret management permissions, you’ll be prompted to automatically authorise it or manually do so in the Azure Portal.

If successfully connected, you’ll be able to then see a list of secrets from your key vault by clicking the add button. Choose the secrets you want to make available to your pipeline and click OK.

Add your new variable group to your pipeline, and that’s all there is to adding key vault secrets to an Azure DevOps pipeline.