This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Azure Functions with the link here. This article continues to discuss Azure Functions best practices.  

When we want code to be triggered by events, Azure Functions become very useful because it is a compute-on-demand experience. It extends the existing Azure App Service platform with capabilities to implement code triggered by events occurring in Azure, in third-party service, and in on-premises systems. Functions can be built to be reactive, but they are also useful to process data from various data sources. Functions are hosted in environments that like VMs are susceptible to faults such as restarts, moves or upgrades. Functions may also have the same reliability as the APIs it invokes. But functions can scale out so that they never become a bottleneck. The previous articles discussed the best practices around security and concurrency. This article continues with some of the other best practices such as availability and monitoring. 

The steps to managing the Function Applications include the following:

1.       A function app provides the execution for the individual functions, therefore, any connection strings, environment variables and other application settings must be tightly controlled for smooth running and scaling. Any data that is shared between function applications must be stored in an external persisted store

2.       The portal is the right place to set the application settings and the platform features. Any number of settings can be added but there are also predefined settings. These settings are stored encrypted.

3.       The hosting plan in which the application runs must be properly chosen to suit the scaling and pricing for one or more function applications.

4.       The eventual migration of a function application between plans must be taken into account as the loads increase and age over time. Only certain migrations are allowed but each migration involves creating a destination plan and deleting the source plan. Forward and backward migrations are permitted in certain cases.

5.       The function access keys are required to support REST calls. The url will be in the format https://<App_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?code=<FUNCTION_ACCESS_KEY> for authorized calls. These keys must be shared with the caller after they are generated from the portal.

6.       The platform features such as App Service editor, Console, Kudu advanced tools, deployment options, CORS, and authentication can be leveraged for operational needs. For example, the App Service editor allows json configuration to be spot edited and it enables integration with the git repository which can trigger the CI/CD pipeline steps. The console is an ideal developer tool to interact with the function application via command line interface. Kudu is an administrator friendly app service administration tool that helps with setting system information, settings and variables, site extensions and HTTP headers. It can be browsed with https://<FUNCTION_NAME>.scm.azurewebsites.net. The deployment center can help automate the deployment from source control. The Cross-origin resource sharing lets an “Access-Control-Allow-Origin” to be declared where origins are allowed to call endpoints on the function application. When functions use HTTP triggers, those requests must be authenticated. The App Service provide Azure Active Directory authentication and allows configuring specific authentication providers.