• Step 1: Getting Started with Azure Command and Query
• Step 2 : Setting up the Azure Environment

Coding for the cloud can seem a mountainous challenge at the start. What resources do you need, how can you best use them, and just what will it cost to run your solution?

In our previous step we built an application that exposes a WebAPI to receive new subscriptions to a book club.

This is then stored in an Azure storage account queue, so that the user can continue whilst we process the request further using an Azure Function.

The Azure function is triggered by the queue, and writes the data to table storage in the same storage account for us.

To aid our development, and to allow us to focus, we used the Azure Storage Emulator to fake our storage account, and ran both the WebAPI and Function with 'F5' using the standard Visual Studio tooling to allow them to run locally.

This is great for development and experimentation. But we need to deploy at some point.

In this tutorial we are going to create an environment in Azure using the Azure Portal, and publish our code for testing.

Getting Started

You can find the starting point in the GitHub repo here

Clone the repo, if you haven't already and checkout step-two-start

The Azure Portal

Before we can make the changes that we need to in our code, we first need an environment to communicate with, and deploy to.

Note: For these steps you need a Microsoft Account. If you do not have one with access to Azure resources then you will need to create one. We are not covering that in this tutorial, but you can read more here

1. Open portal.azure.com
2. Login into your Microsoft Account

We are now on the home page of the Azure Portal. Amongst other things from here we can check the state of your account, navigate around current resources and create new resources. It's the later that is important for us today.

Resource Groups

The first thing that we need to set up is an environment is a resource group. As the name implies a resource group ties the resources together in one group.

This allows easy management of the resources. All related resources are located together, the costs for all related resources are grouped, and when the time comes to clean up your environment all are located together.

1. Click on the 'Resource Groups' icon

1. On the Resource Groups page click the '+ Create' button.

1. Select the subscription to attach the resource group to
2. Give your resource group a meaningful name
3. Select the region to store the metadata for your resource group

1. Click the 'Review and Create' button

1. Check that the data entered is correct and press 'Create'

Azure will now create your resource group for you

1. Refresh the Resource Group List and you should now see your resource group

Most resources take some time to create, the resource group is an exception to this and appears almost immediately.

Creating the Web App

Now we need to add something to it, the first thing that we need to be able to deploy our app is a Web App.

We need a Web App in order to deploy our Web API application. Think of this like the IIS of a Windows Server.

1. Go to the page for the resource group that we just made

1. Click on the Add

1. Click on `Web app'

Click on the Web App link, otherwise we'll find ourselves in the quick start page 😉

1. We should now be on the page to create a new web app - it should look like this

1. Make sure that the right subscription is selected
2. Make sure that the right resource group is selected (if you created the resource from the resource group this will be prefilled)
3. Give your Web App a name

This name cannot contain spaces, and needs to be unique, globally. If someone else has used this name already you will get an error message

1. For publishing click Code
2. Runtime stack is .Net 3.1 LTS
3. Select Windows for the Operating System

Note: There are limitations with Linux App Service plans when using consumption based Function Apps (as we will later in this tutorial), so we are using Windows. If we were to use two Resource Groups to separate this App Service plan from the Function App then we could use Linux for our hosting. For more information see this wiki

1. For region select the same as your Resource Group

Note: Depending on the subscription that you have you may not be able to select every region. In which case Central US - this one has always worked for me

App Service Plan

That is all of the settings that we'll be using today for the Web App itself, but you may have noticed that there are still some settings that we need to look at.

The Web App needs somewhere to run. This is the App Service. If you think of the Web App as IIS, then think of the App Service as the machine it runs on.

As we don't have an App Service in our Resource Group we are going to need to create one.

1. Click the Create New link

1. In the pop-up that opens fill in the name for your app service

1. Fill in a name (this does not have to be globally unique)
2. Click OK
3. Now we want to select the SKU and size of our App Service.
4. Click on Change Size

We should now have a new fly-in open, allowing up to pick what specifications we want for our App Service

Here we can find all of the options available to us for development, testing, production and isolated instances. Have a look around to see what is available

1. Pick Dev / Test

2. Pick F1 Shared Infrastructure. For our demo free is good enough!

For practice, and demonstrations I always use the Dev/Test F1 tier. This is free, has 60 minutes run time a day and is good enough for what we are doing today.

60 minutes a day does not mean it is only available for 60 minutes a day. It means you only get 60 minutes of actual compute time. If our service is only busy for 1 minute per hour then you would only use 24 in that day even though it was available for the whole 24 hours.

1. Click apply

We should now have a screen in front of us that looks a little like:

1. Click Review + Create
2. Check that everything on the review page looks OK

1. Click Create

Azure will now create the resources for us, this will take a few minutes.

Creating the Azure Storage Account

The Web App allows us to host our API, but now we need some storage for it to talk to.

1. Go back to the page for the resource group, now with an App Service and Web App

1. Click on the Add button to open the new resource blade

1. Search for Storage Account

1. Click on the Storage Account - blob, file, table, queue option

2. In the marketplace page that opens, click on Create

1. In the creation screen make sure that the subscription and resource group are correct

1. Fill in the `Instance Details' using this information as a guide

1. Click Review and Create

1. Check that the validation has passed, and that all of information is as you intended it to be

1. Click Create

Azure will now provision our storage account for us!

Whilst it's doing that lets take a quick look at those `Instance Details

Storage Account Name

The storage account name is a globally unique name within Azure.

The same as our Web App, this means that we need to pick a name here that no one else has used.

Unlike the Web App, we have more limitations with the name.

The only characters allowed are lowercase letters and numbers. No PascalCase, camelCase or kebab-case names are allowed.

Yes, this makes the name harder to read. Sorry.

Location

There are two rules of thumb here:

• Keep it close to the metal where it will be written and read.
• Make sure that your users data is compliant with local rules regarding data location.

Performance

For this example we do not need a high data throughput, or extreme response times, so the cheaper standard performance is good enough.

Account Kind

There are three account kinds:

• Storage V2 (general purpose v2)
• Storage (general purpose v1)
• BlobStorage

The Storage V2 accounts are general purpose accounts for File, Table, Queue and Blob storage. For general purpose use this is what we should always use. V1 accounts should only be used for legacy applications that need it. BlobStorage accounts are specialised for high performance block blobs, not for general purpose use.

Replication

Storage accounts always replicate data, but you can specify different levels of replication. This comes at a price, the further down this list you go, the more you pay.

• LRS: Cheapest, locally redundant in 1 data center
• ZRS: Redundant across multiple data centers in one zone
• GRS: Redundant across two zones
• RA-GRS: As above, but with read access across the zones
• GZRS: Redundant across multiple data centers in the first zone, and a single data center in the second
• RA-GZRS: As above, but with read access across the zones

Updating the WebAPI with the Storage Account

Now that we have an Azure Storage Account we can start to use it, to do so we need to make some changes to our WebAPI application.

Get the connection string for the Storage Account

1. Open the resource group
2. Click on the Azure Storage Account created in the last step to open the resource

1. Click on 'Access Keys'

The Access Keys are in the Settings section

1. On the screen that opens we can see two keys and connection strings. Copy one of the connection strings

You can do this easily using the copy button next to the connection string

Note: Do not post keys online, the storage account is open for attack with these keys available. The keys seen here are no longer valid, which is why they are shared for demonstration purposes 😉

Update the WebAPI with the copied connection string

1. Open the WebAPI code
2. Open the QueueAccess.cs file
3. Replace the _connectionString string literal with the connection string copied from the Azure Portal

It should look like this, but with your storage account connection string:

C#
public class QueueAccess
{
private const string _connectionString = "DefaultEndpointsProtocol=https;AccountName=mystor...";


Test the WebAPI and Queue

We are now ready to run!

1. Start the WebAPI in debug mode
2. Open the following folder in a terminal (command prompt, Windows PowerShell, Bash etc). The folder is relative to the base folder of the git repo for this tutorial)

<git repo folder>\front-end

1. Start the Angular front end application by running: ng serve

Note: For this you need to have npm and the angular CLI installed. We are not covering that in this tutorial, but you can find more information here Angular CLI and here npm and NodeJS.

1. Browse to http://localhost:4200 5 Fill in a name, email and preferred genre
2. Click Submit

1. Open the Azure Portal
2. Go to the Azure Storage Account we created
3. Open the Storage Explorer from the side bar

Note: The Azure storage explorer is still in preview, as such there may be some issues. But for our example here it works without a problem.

1. Open the Queues \ bookclubsignups
2. We can see our sign up data in the queue!

Deploying the WebAPI to Azure

So now we have all of the resources that we need in Azure to host our WebAPI and to hold our queue, and we have a WebAPI that can send messages into our queue.

It's time to deploy our code and see it work in the wild!

1. Open the SignupApi solution in Visual Studio
2. Right click on the SignupApi project

1. Click Publish

Note: There are several notable public speakers who use the phrase friends don't let friends right click publish. But for experimentation and a quick deploy it's very useful!

1. In the window that opens select 'Azure'

1. In the 2nd step select Azure App Service (Windows)

1. In the 3rd step select the resource group inside your Azure subscription, and pick the WebApp from the tree view.

1. We now have our publish profile set up. We also have the option for setting up our storage account, which has been detected, and even a pipeline for CI deployments. But for now we are simply going to press the Publish button

Visual Studio will run some checks to ensure that our code will run in the cloud, build, publish and push our code to Azure, and when everything is complete open a browser with the URL of the service.

Don't worry that this shows an error, we only have one route set up for our WebAPI, so the root won't show anything...

But do copy the URL!

Testing the Azure Service

We can test that our API is working using our front end application.

1. Open the front end angular project folder in VS Code

<git rep folder>\front-end

1. Open the SubscriptionService class

src\app\service\subscription.service.ts

1. Change the URL for the API from localhost to the deployed web app

From:
ts
const url =https://localhost:44343/api/bookclubsignup`;
`

To:
ts
const url =https://.azurewebsites.net/api/bookclubsignup;


1. Run the Angular app and add a new sign up the the book club
2. Recheck the Azure Storage Account and check that your new signup is saved, below you can see Rory has signed up for book club now as well

Creating the Azure Function

We now have a working WebAPI, deployed and sending requests to the queue. Now we need to read that queue and store the data in a table.

To do that we need to deploy our Azure Function, so we need a new resource.

1. Open the Azure Portal
2. Go to the Resource Group
3. On the Resource Groups page click the '+ Add' button
4. Click on the Function App link (not Quick starts + tutorials)

1. In the Create Function App Basics make sure the correct subscription and resource group are selected

2. Give the function app a name, this has to be unique in Azure

3. For Publish select Code

4. Pick .NET Core for the Runtime Stack

5. Select 3.1 for Version

6. Make sure that the Function App is located in the same Region as the Storage Account and Resource group

1. Click 'Next: Hosting >'

1. For the Storage Account pick the one we created in this tutorial

Note: If this isn't available then double check your regions - you can only pick storage accounts in the same region as you are creating the Function App

1. Pick Windows for the operating system

Note: As said earlier, there are limitations with Linux App Service plans when using consumption based Function Apps, so we are using Windows. If we were to use two Resource Groups to separate this App Service plan from the Function App then we could use Linux for our hosting. For more information see this wiki

1. For the Plan Type pick Consumption (Serverless)

1. Click Review + Create

1. Check the details of the Function App and if all are correct click Create

Azure will now deploy the resources needed for our new Function App

Once deployed, our resource group is now complete, and should look like this

The function app creation also created the Application Insights resource, but we are not going to be using that for this tutorial, so we can ignore it.

We can also see the new App Service Plan that has been created for the Function App. This will be spun up when the Function App is called, and the code for the function deployed to it from the Storage Account.

Note: This does mean that there is a delay when calling a consumption based Function App from cold before it responds. This is why we have used a regular WebAPI hosted in a Web App for our API layer.

Updating the Function App with the Storage Account

Now that we have our Function App available we can update our Function App code to to triggered from our queue, and to write our data to the queue.

Updating the Function App trigger to use the Storage Account

There are three changes that we need to make to change the trigger

1. Open the Function App solution
2. Open the serviceDependencies.local.json file

1. Copy the JSON below into the file

json
{
"dependencies": {
"storage1": {
"resourceId": "/subscriptions/[parameters('subscriptionId')]/resourceGroups/[parameters('resourceGroup')]/providers/Microsoft.Storage/storageAccounts/<Storage Account Name>",
"type": "storage.azure",
"connectionId": "AzureWebJobsStorage"
}
}
}


Note: The resourceId ends with the Storage Account of our queue. In our example we used mystorageaccounttutorial, that is what we would use here. Whatever the name of the Storage Account is should be used.

1. Copy the connection Azure Storage Account connection string from the Azure Portal, as we did earlier
2. Open the local.settings.json file

You may need to recreate this file due to .gitignore settings. If so create it in the root of the Functions project

1. Replace the value of AzureWebJobsStorage (currently "UseDevelopmentStorage=true") with the value copied from the Azure portal

It should now look like this, but with your storage account connection string:

json
{
"IsEncrypted": false,
"Values": {
"AzureWebJobsStorage": "DefaultEndpointsProtocol=https;AccountName=mystor...",
"FUNCTIONS_WORKER_RUNTIME": "dotnet"
}
}


Note: This setting allows us to run the solution locally, but using the Azure Storage Account rather than the Storage Emulator

1. Finally, open the StorageTableAccess.cs file
2. Replace the _connectionString string literal with the connection string copied from the Azure Portal

It should look like this, but with your storage account connection string:

C#
public class StorageTableAccess
{
private const string _connectionString = "DefaultEndpointsProtocol=https;AccountName=mystor...";


Test the full application locally

We can now do a full local test! From web application, through our WebAPI, Azure Function running locally and into our Storage Table.

1. Start the function in Debug mode

NOTE: Function Apps run in specialised environments in Azure, when you run your app in debug mode Visual Studio spins up an Azure Function Tools application to create this environment locally.

1. Run through the same same steps as our previous test - but don't look in the Queue section!
2. Instead, look in the Table section, where we should now see our latest test:

Deploying the Function App to Azure

Now on to the last step, deploying our BookClubSignupProcessor to Azure!

This flow is similar to deploying the WebAPI to azure

1. Open the BookClubSignupProcessor solution
2. Right click on the BookClubSignupProcessor project

1. Click Publish

1. In the window that opens select 'Azure'

1. In the 2nd step select Azure Function App (Windows)

1. In the 3rd step select the resource group inside your Azure subscription, and pick the Azure Function from the tree view.

1. We now have our publish profile set up. We also have the option for setting up our storage account, which has been detected, and even a pipeline for CI deployments. But for now we are simply going to press Publish

Note: Here we see a big difference from the WebAPP deploy. The Azure Function has a dependency on the Storage Account, which has a warning. We are going to ignore it for now

1. Click the Publish button

Now it's deployed, we can take a look at the function in the Azure Portal to ensure that it worked correctly.

Check that the function has been deployed and is available

Now that we have deployed our function app we can see it in the Azure portal

NOTE: Functions take time to spin up, it may be that after you have deployed it doesn't appear straight away

1. Open the Azure Portal
2. Go to the Resource Group
3. In the list of resources click on the Function App created

1. In the side menu of the Function App click Functions in the group Functions

1. In the blade that opens we can see all of the functions within the Function App, the type of trigger and if they are enabled

Now that we know our Function is deployed and available we can run our final test!

Test the deployed Function App

We now have a full environment deployed and can do one final test to make sure that everything is set up as it should be.

We are going to use the same test as we did running the Function locally. The only thing we need to run locally now is our front end!

Closure and Next Steps

You can find the end point in the GitHub repo here

Clone the repo, if you haven't already and checkout step-three-start

Files will need editing to run - ensure that the correct connection strings and storage account names are set. Due to the nature of publish profiles and their access tokens these files are not included - you will need to follow the publish steps yourself to deploy this repo.

Our solution is now deployed, and running in the cloud. Using a Web App, Azure Storage Account and Azure Function to run in the wild.

As with our previous work, this has been a quick skim through, and is just the start of making a maintainable cloud solution. In the following posts, over the coming months, we'll be

• Taking a look at the Azure cost calculator so that we can check what the associated costs of that environment will be
• Taking a deeper dive into each of the Azure resources we need for this experiment
• Taking a deeper dive into each of the APIs that we are using to access them!
• Finally, we'll be automating the deployment, using Azure DevOps, and quickly throwing a static Angular site into the air so that we can interact with our API

Further Reading

Azure Web App

• Microsoft Learn App Service
• Microsoft Docs App Service

Azure Storage

• Microsoft Learn Storage Accounts
• Microsoft Docs Storage Accounts

Azure Functions

• Microsoft Learn Azure Functions
• Microsoft Docs Azure Functions

Cover photo by Philipp Birmes from Pexels