Nona Blog

Setting up a nodeJS cloud function POC with Microsoft Azure

At Nona our primary cloud infrastructure choice over the last few years has been AWS. However, we believe it is important to keep up to date with technologies competing in the same space. Which in this case would be Google Cloud and Microsoft Azure.

In the following article I will be looking at Azure and creating a node cloud function deployment proof of concept.

Initial Setup

From my own setup perspective there were a couple things that I needed to do:

Create a Microsoft azure account –, being a developer this was pretty straight forward as I was able to do this through my Github account. One of the gotchas here is that you will need access to valid credit card details in order to complete the signup (much like AWS), however there is quite an extensive, visually and functionality intuitive Free trial. In my experience with AWS, billing has been a particularly confusing and frustrating pain point, so to see everything laid out so precisely was a pleasant surprise (especially since the inherent nature of cloud infrastructure makes billing quite complicated).

Once my account was created I installed the Azure CLI, this functions similarly to that of AWS’s CLI, in that it is basically just a command line interface into your account dashboard. Azure also states that all account functionality can be accessed through the CLI (much like AWS).

At this point I had access to the az command within my terminal and the next step was to login:

az login

An interesting note here is that azure intuitively tried to log me into my account through my browser. As opposed to AWS which requires credentials to be saved locally. There are, however, also more programatic ways to do this –

Because I wanted to deploy cloud functions I also needed to install the functions core tools. Once this was complete I now had access to the func command in my cli.

Going forward all cloud function related functionality will be called with the func command, and all azure resource related functionality called with the az command.

Creating a cloud function

We can setup a cloud function project locally using:

func init {project-name} --javascript

You can also similarly create a typescript project if preffered.

Alternatively you can just create a new function – which will do the project setup in that folder if no project currently exists using:

func new --name {function-name} --template "HTTP trigger"

You can now test your function locally using:

func start

The initial startup (for me at least) took some time, as I assume it needed to setup some dependencies for local function execution under the hood. Once complete you should be able to execute the HTTP function locally. This was surprisingly simple for me, as within the AWS infrastructure local execution is not something that is automatically shipped and configured in an intuitive way.

Creating Azure resources

In order to deploy our function we will need to do a few things:

  1. Create a resource group that will be affiliated to our function, and all related resources.
  2. Create a storage account that will hold the files of our cloud function, as well as other resources such as configuration files and logs.
  3. Create an app service that will be responsible for building, deploying and scaling our cloud functions.

Creating the resource group

az group create --name {group-name} --location {location-name}

We can use the following command to get the list of available locations:

az account list-locations

Locations work similarly to aws-regions.

We can confirm that our resource group has been created by viewing it in the dashboard within the browser

or within the cli itself –

az group list

Similarly, we can also remove the group with the following command –

az group delete --name {group-name}

Creating a storage account

There are a few important points to note before attempting to create a storage account:

  • Storage account names must be lower case letters and numbers only
  • Storage account names need to be unique – because of this I prefixed mine with the word “nona” to ensure it was unique

Bearing this in mind we can go ahead and create our storage account (the equivalent in AWS being S3):

az storage account create --name {storagename} --location {location-name} --resource-group {group-name}

Once again we can verify that our resource was created by either visiting the dashboard or through the cli:

az storage account list

We can also delete our storage app using

az storage account delete --name {storage-name}

It it not recommended to delete resources that function as dependencies as this will likely cause your app to break. In my experience debugging a problem like this is particularly difficult. This is one of the reasons to use a deployment pipeline approach that takes dependancy management into consideration.

It is interesting to note though that you can view all of your resources through the dashboard in a single view –, which for me meant the burden of managing dangling unused resources was massively reduced – specifically when compared to the AWS dashboard. It should however, be noted that this applies specifically to resources and not resource group or resource group related services, which means these will need to be managed separately.

Creating the app service

We can create the app the function will be executed in with:

az functionapp create --resource-group {group-name} --consumption-plan-location {location-name} --runtime node --functions-version 3 --name {app-name} --storage-account {storage-name}

Similarly you can delete the app with:

 az functionapp delete --name {app-name} --resource-group {group-name}

Once the app has been created you can publish it with the following command:

func azure functionapp publish {app-name}

Once this is complete you should be presented with a url that can be invoked to run your newly created cloud function in the could! e.g.


You can also visualise the app resource within the cli using:

az functionapp list


For the most part this article is a summary and comments on existing documentation, which I found to be pretty intuitive in nature, because of this I highly recommend checking this out (especially the tutorials) for yourself-

I would like to note though, that this article also functions as an introduction to a more complicated consideration of an Azure cloud function deployment – the deployment pipeline using ARM, a subject that I will be covering in an upcoming article.

Nona designs and builds intuitive software for FinTech businesses. If you’d like to accelerate your FinTech project, book a consultation with us!

Richard Miles

Fullstack Developer - Nona