This reference architecture illustrates multiple local branches of an organization that's spread out geographically. Each location is using a Microsoft Azure Function App that's configured with the Premium plan in a nearby cloud region. The developers in this architecture are monitoring all the Azure Function Apps by using Azure Monitor as a single pane of glass.
Download a Visio file of this architecture.
Typical uses for this architecture include:
- Organizations with many physical locations that are connected to a virtual network in Azure to communicate with Azure Functions.
- High-growth workloads that are using Azure Functions locally and maintaining the option to use Azure for any unexpected bursts in work.
The architecture consists of the following components:
- Azure Functions. Azure Functions is a serverless platform as a service (PaaS) in Azure that runs small, single-task code without requiring new infrastructure to be spun up. The Azure Functions Premium plan adds the ability to communicate with Azure Functions privately over a virtual network.
- Azure Virtual Network. Azure virtual networks are private networks built on the Azure cloud platform so that Azure resources can communicate with each other in a secure fashion. Azure virtual networks service endpoints ensure that Azure resources can only communicate over the secure virtual network backbone.
- On-premises network. In this architecture, the organization has created a secure private network that connects the various branches. This private network is connected to their Azure virtual networks by using a site-to-site connection.
- Developer workstations. In this architecture, individual developers might work on code for Azure Functions entirely on the secure private network or from any remote location. In either scenario, developers have access to Azure Monitor to query or observe metrics and logs for the function apps.
The following recommendations apply for most scenarios. Follow these recommendations unless you have a specific requirement that overrides them.
Designing for a serverless architecture
Traditional enterprise applications trend toward a monolithic application architecture in which one code "solution" runs the entire organization's business logic. With Azure Functions, the best practice is to design for a serverless architecture in which individual functions perform single tasks. These single tasks are designed to run quickly and integrate into larger workflows.
Serverless architecture on Azure Functions has many benefits, including:
- Applications can automatically scale by individual business functions instead of scaling the entire solution. This can help keep costs down by scaling only what's needed for each task to serve existing workloads.
- Azure Functions provides declarative bindings for many Azure services, reducing the amount of code your team needs to write, test, and maintain.
- Individual functions can be reused, reducing the amount of repeated code that's necessary for large enterprise solutions.
Running Azure Functions on-premises
You may choose to have Azure Functions run on-premises rather than in Azure; for example:
- Your team might want to run Azure Functions within an existing on-premises Kubernetes installation.
- In development, your team may find it easier to develop locally using the command line interface instead of the in-portal editor.
- Your functions will run locally with the toolset installed on on-premises VMs.
You can run Azure Functions on-premises in three ways:
- Azure Functions Core Tools. Azure Functions Core Tools is a developer suite that typically installs from node package manager (npm). It allows developers to develop, debug, and test function apps at the command prompt on a local computer.
- Azure Functions Docker container image. You can use this container image as a base image for containers that run Azure Functions on a Docker host or in Kubernetes.
- Kubernetes. Azure Functions support seamless event-driven scale within a Kubernetes cluster using Kubernetes-based Event Driven Autoscaling (KEDA). To review best practices for managing Azure Kubernetes Service clusters and Azure arc enabled Kubernetes clusters, review the Run containers in a hybrid environment reference architecture.
Creating function apps by using the Premium plan opens up the possibility of highly secure cross-network connectivity between Azure virtual networks, Azure and on-premises networks, and the networks for each on-premises branch.
You should use either a site-to-site or an Azure ExpressRoute connection between Azure Virtual Network and on-premises networks. This allows the on-premises branches to communicate with the function apps in Azure by using their service endpoints.
Additionally, each virtual network in Azure should also use virtual network peering to enable communication between individual function apps across regions.
- Azure Functions code should be designed so that it can scale out endlessly. Consider race conditions, leased files, and other workloads that might cause one function run to block another. Also consider writing all Azure Functions code to be stateless and defensive in its design.
- For function apps that use Azure Storage accounts in triggers or bindings, don't reuse the same account that's used to store metadata about the function apps and their runs.
- Typically, Azure Functions on the consumption plan can scale down to zero instances. When a new event triggers a function app, a new instance must be created with your code running on it. The latency that's associated with this process is referred to as a cold start. The Azure Functions Premium plan offers the option to configure pre-warmed instances that are ready for any new requests. You can configure the number of pre-warmed instances up to the minimum number of instances in your scale-out configuration.
- Consider having multiple Premium plans in multiple regions and using Azure Traffic Manager to route requests appropriately.
- Azure Functions must be in an empty subnet that's a different subnet than your other Azure resources. This might require more planning when designing subnets for your virtual network.
- Consider creating proxies for every on-premises resource that Azure Functions might need to access. This can protect your application integrity against any unanticipated on-premises networking changes.
- Use Azure Monitor to observe analytics and logs for Azure Functions across your entire solution.
- Ideally, deployment operations should come from a single team (Dev or DevOps), not from each individual branch. Consider using a modern workflow system like Azure Pipelines or GitHub Actions to deploy function apps in a repeatable manner across all Azure regions and potentially on-premises.
- Use your workflow system to automate the redeployment of code to Azure Functions as the code is updated and tagged for release.
- Use deployment slots to test Azure Functions prior to their final push to production.
- Use the Azure pricing calculator to estimate costs.
- The Azure Functions Premium plan is required for Azure Virtual Network connectivity, private site access, service endpoints, and pre-warmed instances.
- The Azure Functions Premium plan bills on instances instead of consumption. The minimum of a single instance ensures there will be at least some monthly bill even without runs. You can set a maximum instance count to control costs for workloads that may burst in size.