Azure Functions: 

This is a continuation of a series of articles on Azure services from an operational engineering perspective with the most recent introduction to Azure Function core tools with the link here. This article discusses 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 article details some of the best practices for designing and efficient function apps. 

Security is best considered during the planning phase and not after the functions are ready to go. Planning for the security considerations of the Azure function is much like that of a cloud service or an application Azure App Service provides the hosting infrastructure for the function applications. Defender for cloud integrates with the function application via the portal and provides a free quick assessment of potential vulnerabilities. Activity monitoring and logging analytics also boost security. Functions integrates with Application Insights to collect log, performance, and error data for the function application. Application Insights automatically detects performance anomalies and includes analytical tools. Functions also integrate with Azure Monitor Logs to enable us to consolidate function app logs with system events for easier analysis. Enterprise level threat detection and response automation involves streaming log events to Log Analytics Workspace.

Clients can connect to function endpoints by using both HTTP or HTTPS but HTTP should be redirected to HTTPS. The use of SSL/TLS protocol provides a secure connection. Functions lets us use API access keys to make it harder to access the endpoints during development. Function-level authorization scopes are available at two levels: at function level and at host level. API access keys at function level allow access only to those functions while host level keys allow access to all functions within the function app. There is also an admin level master key called _master which provides host level access to all the functions in the app. When the access level is set for an admin, requests must use the master key. Specific extensions may require a system-managed key to access webhook endpoints. System keys are designed for extension-specific function endpoints that are called by internal components. Keys are stored in a blob storage container in the account provided by the AzureWebJobsStorage setting. The AzureWebJobsSecretStorageType setting can be used to override this behavior and store keys in a different location. Last but not the least, authentication and authorization decisions can be based on identity. Azure API management can be used to authenticate requests.

Function Applications must be run with the lowest permissions. Functions support built-in Azure RBAC. Function apps can be split based on the credentials and connection strings stored in the application settings.