Azure Functions

Azure Functions allow you to run small pieces of code without having to worry about infrastructure to run it on.

A function is “triggered” by a specific type of event

• Http request
• Timer ( e.g every hour)
• Queue ( e.g message put on azure queue from another application)
• Event Grid – Blob Storage & Cosmos DB ( e.g file uploaded to storage account and you want to send an email as a result)

Why use a function

Some key benefits of using functions

1. You don’t have to manage infrastructure (creating and managing a VM to run the application, patching the VM etc….)
2. If using consumption plan you only pay for time spent running your code – e.g dont need to have VM running all the time if you only want to run the job for 5 minutes every hour
3. Its easy to integrate with other Azure services (e.g azure storage, queues)
4. Its Possible to setup Continuous Integration (CI) and deploy functions through devops/git hub and other supported tool

Costs

As you can see from the many benefits of using functions, one key benefit is only paying for the time spent actually running your code. This is true if your use case is suitable to be ran under the consumption plan. If you require VNET integration for example then this is not available under the consumption plan and would require you to use the premium plan. Below is a look at some differences between the 2 plans.

Functions and Networking

In order to connect to VNET from azure function you need to use the premium plan and connect your function app to the virtual network, you will need to create a subnet with a valid size, the subnet size restricts the number of instances that your premium plan can scale out to.

Multiple function apps can be deployed to the same plan however, and using the premium plan tackles the issue of cold starts.

So for example if you have a function that needs to connect to a SQL database, but that SQL server doesn’t have a public endpoint, then you need this VNET integration feature. At this stage you will need to review if the cost of using the premium plan is worth the decision to use an azure function in this scenario? That depends on many factors

• If you have no existing resources (VM) able to run the function due to resources constraints ?
• or perhaps in the short term there isn’t a requirement for scale and the function could reside on a VM until the need for scale is required.

Restricting access

You can also use access restrictions on the function to limit inbound usage to just your VNET, but the function still has full outbound access. Implementing an Application Service Environment (ASE) within your network is the solution if require full control to function networking

If latency between the function app and VNET is an Issue, then deploying an ASE /ISE can also help.