Introduction to Azure Functions

Azure Functions is the primary serverless application type available on Azure. Functions can be written by using a wide range of programming languages. They also support many different types of invocation. We can set up a function to be triggered by a standard HTTP request over the internet. Or we can have a function executed by a timer. Or the function can act as a subscriber to a messaging queue and get invoked when a new message is delivered.

Azure Functions supports generic types of trigger mechanisms. An HTTP request or a timer are examples of those. But as a first-class Azure citizen, Azure Functions also supports built-in integration with Azure-specific resource types and third-party services that are popular in Azure. Integration with Azure Service Bus is an example of interoperating with an Azure-specific resource. Integration with RabbitMQ is an example of interoperating with a popular third-party service.

As with any serverless application, Azure Functions is designed to be lightweight, stateless, and elastic. A typical function executes a single job within a short period. The exception to this is a durable function. The difference between standard and durable functions can be summarized as follows:

• Standard Azure function: A single stand-alone function that is triggered by a specific event.

• Durable Azure function: Multiple functions are orchestrated to run in a specific sequence to handle a complex computational procedure.

In a durable orchestration setup, the functions act as a single distributed application that can complete a complex task that might potentially take hours to execute. An example of this would be an ETL (extract, transform, load) job where a large volume of data is extracted from the database, summarized, and the results of the summary are added to the analytics data store.

Regardless of whether we are using a standard or a durable Azure function, some principles remain the same. For example, the function runs only when it’s being used and it hardly uses any chargeable cloud resources otherwise. The function can be configured to be elastic so it can scale itself as needed.

Developing Azure functions locally

Azure functions can be run on a local development machine with the help of Azure Functions Core Tools. This is a complete software development kit (SDK) for initializing, developing, and running Azure functions locally. This SDK also allows us to build and test our Azure functions inside the interactive code widgets in this course.

Some built-in tools for developing and running Azure functions are also available in IDEs and code editors. Both Visual Studio and Visual Studio Code have such tools.

In addition to this, some Azure-specific services can be relatively easily emulated in a local development environment, so we can test the bindings specific to these services. For example, the Azurite tool can be used to emulate Azure Queue Storage, Blob Storage, and Table Storage.

Azure function example

The following interactive setup represents an Azure function project based on an isolated Azure function template. There are other types of Azure functions available too and they have a different code structure. However, this setup is sufficient to demonstrate the core components that any Azure function has.

Our Function1.cs file contains an example of a function with an HTTP trigger. The content of this file can be summarized as follows:

• The trigger can be seen inside the Run method in line 18, which is represented by the HttpTrigger attribute.

• The function name is configured by the Function attribute in line 17. In our case, the name of the function is Function1, which is the default name in the project template.

The name of the function with the HTTP trigger sets the path to the function in the URL. It follows this pattern:

If our base URL is example.com and our function name is Function1, as in the example above, the full address of the endpoint that represents the function trigger would be as follows:

Calling this endpoint with one of the HTTP verbs specified in the HttpTrigger attribute will execute the method. Any HTTP verbs are supported, so we can have GET, POST, PUT, DELETE, etc.

A function with an HTTP trigger accepts a parameter that represents the request object. In our case, the name of the parameter is req. We create a response object from the request parameter in line 22 by calling the CreateResponse method. We add some data to the response object, and then we return it.

If we want to test this function, we can click the “Run” button. Once it’s built, we can open the application in a new browser window by clicking on the link that appears. The base URL will take us to the Azure Functions homepage, which will look as follows:

If we want to test the function, we will need to append /api/Function1 to the function app address that will be displayed in the playground once we build our application. The expected output of the function is the “Welcome to Azure Functions!” message.