In a post on the Microsoft blog, Joy Chik, President, Identity & Network Access said that Entra ID will join Entra Permissions Management, Entra Verified ID, Entra ID Governance and Entra Workload ID.

“To simplify our product naming and unify our product family, we’re changing the name of Azure AD to Microsoft Entra ID,” Chik wrote.

“Capabilities and licensing plans, sign-in URLs, and APIs remain unchanged, and all existing deployments, configurations, and integrations will continue to work as before.”

Customers will begin to notice the rebrand start to roll out across Azure from today, as well as updates to documentation and on Microsoft materials.

Customers are not required to make any changes as a result of this announcement, though partners and resellers are advised to start updating marketing materials and replacing references to Azure AD.

Alongside the announcement, Microsoft also announced a preview of a new web security gateway called Entra Internet Access. Designed to protect access to software-as-a-service (SaaS) products and internet resources, the product takes conditional access policies one step further.

A second product was also revealed in preview, dubbed Entra Private Access. This product allows customers to connect to private apps no matter what network they’re on or where they’re located. It allows organisations to replace traditional, legacy VPNs and provides more granular conditional access policies.

Fortunately Microsoft makes enforcing policies relatively straightforward via a service called Azure Policy. It combines a number of best practice, out-of-the-box policies with the ability for you to also create your own custom policy definitions. You can setup guardrails and enforce compliance easily.

The best bit? Aside from Azure Arc resources, Azure Policy is available free of charge.

Setting up policies

Once you have an active Azure subscription, the first thing you’ll want to do is sign in to the Azure portal and open the ‘Policy’ service. You can find this by searching for ‘Policy’.

If you haven’t setup any policies and you have no provisioned resources, you should see a dashboard showing a 100% compliance rate. Otherwise the dashboard may show you issues that require attention with your provisioned resources.

The ‘Getting Started’ tab allows you to quickly setup policy assignments for your cloud environment. This includes things such as blocking the provision of various resource types or requiring tags on resources.

The ‘Getting Started’ tab for Azure Policy

Alternatively you can select “Definitions” under “Authoring” and browse the complete list of policy definitions that can be applied.

Before configuring a policy, consider whether you want to retrospectively apply a policy to existing Azure resources or whether it should only apply to new resources being provisioned.

By default policies only apply to new resources, but you can update existing resources after the policy has been assigned.

Once you select a policy, you can configure the following:

• Scope: The tenant, management group, subscription (optional) and resource group (optional) that the policy will apply to

• Basics: The policy definition, assignment name and brief description of the policy. You can also specify whether the policy is enforced or disabled, and see who assigned the policy

• Parameters: Some policies may require additional parameters. For example, the ‘Not allowed resource types’ policy requires you to select the types of resources you want to prohibit from being provisioned

• Remediation: If you’re deploying a policy with the deployIfNotExists and modify effect types you’ll need to provide a managed identity that can be used to edit tags and deploy resources where required. You may also need to configure role permissions

• Non-compliance message: Message to show when a resource or modification is denied due to the policy, or if a resource is presently non-compliant

Where needed, provide Azure policy parameters

Monitoring compliance

Once you’ve configured your policies, the “Compliance” tab will update to show resources and their compliance state.

The list of resources shown can be filtered by scope (management group, subscription, resource group or resource type), definition type (all, initiative or policy), compliance state (such as compliant, non-compliant, not registered) and by name or ID.

The pathway to Azure DevOps certification

The first certification you’ll want to get is for Azure Fundamentals (AZ-900). This covers the basics about Azure, including generic cloud concepts as well as more targeted Azure information such as pricing and a high-level overview of available services.

Note that the content for Fundamentals changed on October 25, 2021 so you might want to check the skills measured list to ensure you’re still studying the right materials.

Once you’ve completed the Fundamentals course, you should target either the Azure Administrator Associate (AZ-104) or Azure Developer Associate (AZ-204) exam.

These will give you a solid understanding of core Azure services, and how to put in place best practice solutions to meet the needs of your organisation.

Finally you can undertake the DevOps Engineer Expert certification (AZ-400), which will entail both hands-on lab work as well as an exam. Note that the content for this course changes on November 30, 2021.

AZ-400 requires you to have completed either AZ-104 or AZ-204 before you can attempt the exam.

Conclusion

In summary, there’s a clear pathway to becoming a certified Azure DevOps engineer.

While it will take time, and a lot of hard work - now that Microsoft have role-based certifications in place it’s much easier to work out what exams you need to sit to be considered an expert in your field.

When using the Azure Portal, querying multiple instances is straightforward.

How to query across multiple App Insight instances

First, login to the Azure portal using your Microsoft work, school or personal account credentials.

Navigate to one of the App Insight instances you’d like to run a query against.

Then, in the sidebar scroll down until you see ‘Logs’. Click on this menu item.

Application Insights logging screen

You should now see the Application Insights query screen. From here, click ‘Select scope’.

Application Insights scope selector

A new modal will appear, allowing you to select multiple Application Insights instances to run your query against from through out your subscription and across multiple resource groups.

Once you’ve clicked the checkbox next to your selected Application Insights instances, click ‘Apply’ to close the modal and persist your selection.

Now type your query, and click ‘Run’. It will execute the request against all your selected scopes (in this case your Application Insights instances) and return the results.

It’s an improvement on writing Azure Resource Manager (ARM) templates directly by better supporting features such as type safety and code modularity and reuse.

That said, Bicep still has a very close relationship with ARM templates. In fact, it’s an abstraction over ARM templates with templates written using Bicep able to be transpiled back to ARM templates. And if you have a bunch of existing ARM templates, they can be transpiled and converted into Bicep files.

Let’s now take a look at how you can get started using Bicep.

Preparing your environment

There’s a few things you’ll want to install in order to start using Bicep.

First you’ll want to download Visual Studio Code (free) and install the Bicep extension (also free). This will give you an editor in which to write your Bicep files, and the extension adds handy features such as Intellisense code suggestions and template validation to ensure the correct syntax.

You’ll also need to install the Bicep command line interface (CLI). The easiest, cross-platform way to do this is by installing the Azure command line interface. But if you’re after an alternative, see this list.

Become a Bicep guru

Dive deeper into Bicep with our getting started with Bicep course on Udemy today!

Start learning

Writing your first Bicep file

Open Visual Studio Code, and create a new file called HelloWorld.bicep. In it, paste the following code:

1
2
3
4
5
6
7

resource appConfig 'Microsoft.AppConfiguration/configurationStores@2020-06-01' = {
  name: 'bicepDemoAppConfig'
  location: 'westus2'
  sku: {
    name: 'standard'
  }
}

In this template, we’re creating an App Configuration service in Azure. Lets breakdown the template:

appConfig provides a local resource name for use within the template if you need to refer to this resource as a dependency, or from within another resource.

Microsoft.AppConfiguration/configurationStores@2020-06-01 refers to the resource type and the values that can be configured. See this Microsoft documentation for a full list of resource types.

As such, name, location and sku are all values that can be set for the resource type.

Next steps

To learn how to deploy this template, or to find out about more advanced Bicep topics including for loops, conditional statements and modularised templates check out our Udemy course on getting started with Bicep.

Microsoft is now previewing a new blade in the Azure portal that lets you quickly spin up an Azure app service with an associated database.

Supported database engines for the preview are Postgres or serverless Azure SQL server.

To get started using the new blade, click here or search the Azure Marketplace for “web app database”.

The blade - currently in preview - is fairly basic compared to the normal app service blade, but allows you to specify the app name, runtime and database engine. You can also set the server name and database name.

By default it’ll spin up an app service using the Premium V2 tier, but you can scale this down (or up if required) once the service is created using the regular Azure scale up settings.

The database connection information will automatically be set as environment variables for your app service.

An ARM template is essentially a JSON file that describes the infrastructure you want to create in the Azure cloud. It can be run as many times as you like to spin up identically-configured environments.

Create the template

The first step when using an ARM template is to create the template file. If you’d rather start with an example template, Microsoft has an entire Github repo with some templates that you can clone.

The base template - normally called azuredeploy.json - is made up of the following structure:

1
2
3
4
5

{
  “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
  “ContentVersion”: “1.0.0.0”,
  “Resources”: []
}

The elements can be described as follows:

• $schema: Refers to the properties that can be used within the template. If you were to load the URL in your web browser, it would return the elements and a description of each that you can use within your template. When uploading a template, these get validated to ensure you haven’t made any mistakes.
• contentVersion: This is an internal version number for you to use to reference the current template. It should be in the format X.X.X.X, with X being any integer. You should only change this value in your template when a significant change is made.
• resources: This is an array that will contain a description of all the Azure resources that your app or service needs. For now it’s empty.

Add resources to the template

As mentioned above, within the resources section of the template you need to describe the Azure services that you wish to provision. Each Azure service has a set of properties that can be set, with some mandatory. By default, a resource requires:

• type: The type is a string that refers to a namespace of the resource provider and the name of the type of resource that you wish to provision. For example, Microsoft.DocumentDB/DatabaseAccounts implies you want to create a DatabaseAccount from the Microsoft.DocumentDB namespace
• apiVersion: Similar to the template $schema version, each Azure resource type also publishes versions of their schema. This property allows you to specify which schema or version of the resource type you’d like to use and is mandatory
• name: The human-readable string name that you’d like the resource to be called

While not mandatory, a location element is normally provided as well to specify the location where you want the resource to reside (eg. Australia East).

Luckily Microsoft publishes a full list of properties for each resource type. But if you’re still not sure, for most resources you can manually create the resource using the Azure Portal and go to the “Export Template” tab for the resource, and Microsoft will generate a template for you.

For this tutorial, let’s create a simple functions app. Add the following to your resources section in your azuredeploy.json file:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

   "resources": [
        {
            "type": "Microsoft.Web/sites",
            "apiVersion": "2018-02-01",
            "name": "[parameters('siteName')]",
            "kind": "functionapp,linux",
            "location": "[parameters('location')]",
            "dependsOn": [
                "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]"
            ],
            "properties": {
                "name": "[parameters('siteName')]",
                "siteConfig": {
                     "appSettings": [
                        {
                            "name": "FUNCTIONS_WORKER_RUNTIME",
                            "value": "python"
                        },
                        {
                            "name": "FUNCTIONS_EXTENSION_VERSION",
                            "value": "~2"
                        }
                    ]
                },
                "serverFarmId": "[resourceId('Microsoft.Web/serverfarms', variables('hostingPlanName'))]",
                "clientAffinityEnabled": false
            }
        },
        {
            "type": "Microsoft.Web/serverfarms",
            "apiVersion": "2018-02-01",
            "name": "[variables('hostingPlanName')]",
            "location": "[parameters('location')]",
            "kind": "linux",
            "properties":{
                "reserved": false
            },
            "sku": {
                "Tier": "Dynamic",
                "Name": "Y1"
            }
        }
    ]

The above creates a Linux App Service hosting plan. It uses the consumption function tier (Y1) and isn’t a reserved plan.

The template also creates a function app (Microsoft.Web/sites) that dependsOn the hosting plan.

If you look closely, you might notice that some elements refer to variables and parameters. Let’s dive deeper into what they are.

What are parameters?

Parameters allow you to specify a value each time you deploy a template. For example, if you had a template and wanted to create a production and staging environment with it, you could create a environment parameter that would allow you to specify staging or production in resource names without modifying the template file each time.

If you didn’t use a parameter, you’d need to change the hard-coded string value in your azuredeploy.json file each time you wanted to change to a new environment.

Similarly if you wanted to be able to deploy your template to a different Azure location quickly, you could specify a location parameter. Then you could deploy to any Azure region by simply providing a new location parameter value - with no change to the template file required.

Within the template file, parameters sit in a top-level parameters element as follows:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13

{
  “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
  “ContentVersion”: “1.0.0.0”,
  “Resources”: [],
  “Parameters”: {
    “hostingPlanName”: {
      “type”: “string”,
      “DefaultValue”: “”,
      “Metadata”: {
           “Description”: “The name to give your hosting plan”
      }
   }
}

Parameters support a number of elements, but the most common include:

• type: The type of value provided (eg. String)
• defaultValue: A default value to use if one isn’t provided when the template is deployed
• metadata.description: A description of what the parameter represents

Parameters can be set when deploying using the Azure CLI or PowerShell. Here’s an example of how you would provide a location parameter using the Azure CLI:

1
2
3
4
5

az group deployment create \
  —-name mytemplatename \
  —-resource-group yourResourceGroup \
  —-templateFile $templateFile \
  —-parameters environment=staging

Referencing the parameter is done using the following syntax - you can see a full example in the template we defined earlier with resources:

1

"location": "[parameters('location')]"

What are variables?

While parameters allow you to specify values when _deployin_g a template, variables allow you to reuse values internally within your template file without duplication. For instance, if you had a value that you use in 3 different resources (such as a location or in the example above the hostingPlanName) that you didn’t want to expose to those running your template you could use a variable.

Like parameters, variables are also top-level elements. They’re simpler to specify, as you don’t need to provide descriptions, types and default values. They look like this:

1
2
3
4
5
6
7
8

{
  “$schema”: “https://schema.management.azure.com/schemas/2015-01-01/deploymentTemplate.json#”,
  “ContentVersion”: “1.0.0.0”,
  “Resources”: [],
  “Variables”: {
     “HostingPlanName”: “yourHostingPlanName”
  }
}

You can then reference the variable within your resource definitions using the following syntax as seen in the resources section in the template we created earlier:

1

"name": "[variables('hostingPlanName')]"

Summary

In this post, you’ve learnt about how a template is structured, and what each element means. Stay tuned for our next post on deploying your template.

If you’ve configured a slot then you’ll want to swap deployments at a minimum between a production and pre-production environment. Microsoft cover in depth what happens when you commence a swap, but what they don’t cover is what happens to any managed identities that you have setup for the app service.

In short, managed identities are tied to the slot in which you first create or assign them, and do not change when you initiate a swap between two or more slots.

You might recall that for an App Service you can have both a system-assigned or a user-assigned identity. These are configured to allow your App Service to access other Azure resources, without the need for sharing secrets and passwords.

When swapping slots, both system and user-assigned identities remain tied to the slot. They don’t swap - so if you need to change these, you’ll need to intervene separately.

Once you’ve generated or assigned an identity, don’t forget to then add it to any Azure resources your app needs access to.

Also keep in mind the lifecycle of a managed identity. User assigned identities won’t be removed whenever you delete a slot. On the other hand, system assigned identities will be deleted as soon as you delete a slot. Depending on your situation, you may prefer one of these approaches.

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.

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.

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.

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

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.