I am falling in love with the Azure functions. It makes my life simple and its just so easy to integate it with other components. Service Bus, Blob Storage, API management and the list goes on and on. Its customizable and the Durable framework is just so awesome. On top of it, 1 million executions free every month, gives us a lot of space to experiment new things.

1 million executions are more than enough and if by any chance,it crosses the limit, we still have to pay a very small amount. But sometimes, we do forget (atleast I forgot :p), that there is a storage account behind the scenes, where all your function code is stored. And there is a cost associated with it, which does not come bundled with the costs of a fucntion.

We should also remember that, long running functions might lead to increase in costs and may cause performance issues.

From my experience, I have some tips to address the above. I assume, that we are using Consumption plan here:

1.) Use Azure local storage emulator

Use the local Azure storage emulator while running functions locally. You can basically test your functions even without touching Azure. If you want to read/write blobs from container, or log some information, its better to use local emulator which behaves exactly the same as an Azure mounted storage account. Microsoft has a good documentation for this, https://docs.microsoft.com/en-us/azure/storage/common/storage-use-emulator.

To use storage emulator, you will use the following setting in your local.settings.json file ( (AzureWebJobsStorage setting)

local.settings.json

Now, probably reading and writing from storage account does not costs so much, but if you have a team of many developers debugging and running codes locally, it might lead to some increase costs. Try avoiding Azure here :)

An added benefit is that you can access storage emulator in the same way as a Storage account, by using Azure Storage Explorer as below. Local emulator should be started before doing this operation, please refer to the Microsoft link above.

Connect to local emulator

Now, all the operations, like generating SAS keys, access keys can be done in the same way as you do it for an normal storage Account.

2.) Avoid AzureWebJobsDashboard function app setting

This settings basically writes the logs of the function to the specified storage account. Now, a function may generate so many logs and writing them to a storage account might be expensive. The situation might become worse in Production, where you write logs for tracebility. Avoid this. Don’t use this setting. Instead dump all logs to Application Insights. Its cheap, gives better analysis of logs and easy to use.

Logging in the App insights is easy, use ILogger interface, insert it into your code using Dependency Injection (default template code created by Azure for function already has this)and then use

log.LogInformation(“Msg to log”).

OR

log.LogError(“Error msg to log”) — It has many such methods

Configure the instrumentation Key for your app insights in APPINSIGHTS_INSTRUMENTATIONKEY function app setting.