Azure Functions
- A serverless solution to execute code based off conditions or triggers
- Maintain less infrastructure and save on costs
Azure Functions vs. Azure Logic Apps
- Azure Functions is a serverless compute service, Azure Logic Apps is a serverless workflow integration platform
- Orchestrations are a collection of steps executed to accomplish a complex task
| Topic | Azure Functions | Logic Apps |
|---|---|---|
| Development | Code-first (imperative) | Designer-first (declarative) |
| Connectivity | About a dozen built-in binding types, write code for custom bindings | Large collection of connectors, Enterprise Integration Pack for B2B scenarios, build custom connectors |
| Actions | Each activity is an Azure function; write code for activity functions | Large collection of ready-made actions |
| Monitoring | Azure Application Insights | Azure portal, Azure Monitor logs |
| Management | REST API, Visual Studio | Azure portal, REST API, PowerShell, Visual Studio |
| Execution content | Runs in Azure, or locally | Runs in Azure, locally, or on premises |
Azure Functions vs. WebJobs
- Azure App Service WebJobs with WebJobs SDK is a code-first integration service similar to Azure Functions
- Both support features such as source control integration, authentication and monitoring with Application Insights integration
- Generally, Azure Functions is better
- More programming language options
- More developer environments
- Azure service integration
- Better pricing
| Factor | Functions | WebJobs with WebJobs SDK |
|---|---|---|
| Serverless app model with automatic scaling | Yes | No |
| Develop and test in browser | Yes | No |
| Pay-per use pricing | Yes | No |
| Integration with Logic Apps | Yes | No |
| Trigger events | Timer | Timer |
| Azure Storage queues and blobs | Azure Storage queue and blobs | |
| Azure Service Bus queues and topics | Azure Service Bus queues and topics | |
| Azure Cosmos DB | Azure Cosmos DB | |
| Azure Event Hubs | Azure Event Hubs | |
| HTTP/WebHook (GitHub Slack) | File system | |
| Azure Event Grid |
Hosting options
- Options: Consumption, Flex Consumption, Premium, Dedicated, Container Apps (for Azure Container Apps service)
- For plans Premium and above, it has Linux container support
- Azure App Service infrastructure allows Azure Functions to be hosted on both Linux and Windows VMs, allowing you to dictate:
- How your function app is scaled
- The available resources to each function app instance
- Support for advanced functionality, such as Azure Virtual Network connectivity
- Support for Linux containers
- The host.json file in your project can specify a functionTimeout property for the timeout duration for functions applying to their executions
- After the trigger starts the execution, the function needs to respond within that duration
- Regardless of the timeout duration, an HTTP triggered function has a maximum time of 230 seconds to respond
- OS runtime and patching, vulnerability patching and scaling behaviours can cancel function executions
- When the minimum number of replicas is set to zero, the default timeout depends on the specific triggers used in the app
Consumption plan
- Default hosting plan
- Only pay for compute resources when functions are running
- Automatic scaling based off number of incoming events
- Timeout duration:
- Default: 5 minutes
- Maximum: 10 minutes
Flex Consumption plan
- High scalability with compute choices, virtual networking and pay-as-you-go billing
- Automatic scaling based on the configured per instance concurrency and the number of incoming events
- Can specify number of pre-provisioned (always ready) instances to reduce cold starts (also scales on demand)
- Timeout duration:
- Default: 30 minutes
- Maximum: Unlimited
Premium plan
- Automatically scaled based on demand using prewarmed workers
- No delay when running apps after being idle
- Can run on more powerful instances
- Can connect to virtual networks
- This plan is great in the following situations:
- Function app needs to run pretty much continuously
- Apply event-driven scaling, deploying and controlling multiple function app instances
- Lots of small executions but a high execution bill
- Need more CPU or memory options
- Code needs to run longer than the maximum execution time in previous plans
- Require virtual network connectivity
- Need to provide custom Linux image to run your functions
- Timeout duration:
- Default: 30 minutes
- Maximum: Unlimited
Dedicated plan
- Run functions within an App Service plan at the regular App Service plan rates
- Ideal plan for long-running scenarios where Durable Functions can't be used
- This plan is great in the following situations:
- You have predictable billing or need to manually scale instances
- Want to run multiple web apps and function apps on the same plan
- Need access to larger compute size choices
- Full compute isolation and secure network access provided by an App Service Environment (ASE)
- High memory usage and high scale (ASE)
- Timeout duration:
- Default: 30 minutes
- Maximum: Unlimited
Container Apps
- Allows you to create and deploy containerised function apps in a fully managed environment hosted by Azure Container Apps
- Can run your functions with other microservices, APIs, websites and workflows as container-hosted programs
- This plan is great in the following situations:
- Want to package custom libraries with your function code
- Migrate execution code from on-premises or legacy apps to cloud native microservices running in containers
- Avoid overhead and complexity of managing Kubernetes clusters and dedicated compute
- Need the high-end processing power provided by a dedicated CPU compute resources for your functions
- Timeout duration:
- Default: 30 minutes
- Maximum: Unlimited
Scale Azure Functions
| Plan | Scale out | Max # instances |
|---|---|---|
| Consumption | Event driven. Scales out automatically, even during periods of high load. Functions infrastructure scales CPU and memory resources by adding more instances based on the number of incoming trigger events. | Windows: 200, Linux: 100 |
| Flex Consumption | Per-function scaling. Event-driven scaling decisions are calculated on a per-function basis, which provides a more deterministic way of scaling the functions in your app. | Limited only by total memory usage of all instances across a given region. |
| Premium | Event driven. Scale out automatically based on the number of events that its functions are triggered on. | Windows: 100, Linux: 20-100 (depends on region) |
| Dedicated | Manual / autoscale | ASE: 100, Windows / Linux: 10-30 |
| Container Apps | Event driven. Scale out automatically by adding more instances of the Functions host, based on the number of events that its functions are triggered on. | Windows / Linux: 10-300 (set max. replicas if enough cores quota available) |
Develop Azure Functions
- A function app is a way to organise and collectively manage your functions
- Run in the same execution context
- Deployed and scaled together
- All functions share the same pricing plan, deployment method an runtime version
Develop and test Azure Functions locally
- Use your own code editor and development tools on your local computer
- Local functions can connect to live Azure services and debuggable using the full Functions runtime
- Local project files:
- In all root project folders:
- host.json: Contain configuration options that affect all functions in the function app instance
- Other configuration opions are managed depending on where the function app runs
- Deployed to Azure: In your application settings
- On your local computer: In the local.settings.json file
- local.settings.json: Stores app settings and settings used by local development tools
- Settings in this file are only used when running your project locally
- Other files depending on language and specific functions
- host.json: Contain configuration options that affect all functions in the function app instance
- In all root project folders:
- Any local settings required by your app during local development must be present in the app settings of the deployed function app
Connect functions to Azure services
- Azure Functions uses the app settings of the Azure App Service to securely store strings, keys and other tokens to connect to other services
- These settings are encrypted and can be accessed by the app through environment variables
- Configuring an identity-based connection:
- Support depends on the extension using the connection (can use identity or secret)
- Identity-based connections use a managed identity when hosted in the Azure Functions service
- System-assigned identity is used by default
- User-assigned identity can be specified with the credential and clientID properties
- Resource ID is not supported
- If hosted in other contexts, use your developer identity instead (customisable)
- Granting permission to the identity
- Assign role via Azure RBAC or specifying the identity in an access policy (depends on service you're connecting to)