FaaS Comparison: AWS Lambda vs Azure Functions

#lambda #azurefunctions #serverless

In this post we’ll explore the different features and capabilities of AWS Lambda and Azure Functions.

Intro

FaaS (Function as a Service) is a cloud computing service model where cloud providers allow users to run individual functions or pieces of code in response to specific events. These events may include changes in state or an update, such as a user placing an item in a shopping cart on an ecommerce website. These functions, also known as serverless functions or serverless compute, are small units of compute that are designed to perform a specific task. They are event-driven and executed in stateless environments. When a specific event occurs (such as an HTTP request, database change, or file upload), the function is automatically invoked, and the cloud provider manages all the necessary infrastructure, including server provisioning, scaling, and maintenance.

The serverless functions were first introduced in November 2014 when Amazon Web Services introduced AWS Lambda. Since then, other cloud providers like Microsoft Azure (with Azure Functions) and Google Cloud Platform (with Google Cloud Functions) offer similar services.

Setup

To create a new AWS Lambda function is very simple and intuitive, you just need to select the Runtime (programming language you want to write the function code) and architecture (x86_64 or arm64). Additionally it is important to choose a memory size for the function. The default one is 128 MB and the max is 10GB. The memory size determines the computing power of the function. Lambda allocates CPU power in proportion to the amount of memory configured. And that’s all you need to do to create your first function!

To create a new Azure Function, first you need to create a Function App. A Function App can hold many Azure Functions, letting you group functions as a logical unit for easier management, deployment, scaling, and sharing of resources. At the time of creation of the Function App, beside specifying the runtime, you need to specify Operating System Linux/Windows, choose the Hosting Plan and choose a storage account. The chosen Hosting Plan is created as an additional resource in your Azure infrastructure. Multiple Function Apps can share the same plan.

Azure offers the following hosting plans

Consumption, this is the only fully serverless hosting plan, where instances of the Azure Functions host are dynamically added and removed based on the number of incoming events. The max memory per instance is 1.5GB.
Functions Premium, offers scaling and network isolation, ideal for workloads running continuously. With the Premium plan there is at least one always active instance. The max memory per instance is 3.5–14 GB.
Dedicated, fully isolated and dedicated environment. These dedicated compute resources are analogous to the server farm in conventional hosting. The max memory per instance is 1.75–14 GB.

Function organization

In AWS Lambda, you define and deploy individual functions. Each function is a separate entity, and you manage them individually. Each function operates independently, and they do not share a common state unless you integrate external services for that purpose. AWS Lambda provides granular control over individual functions, allowing you to set specific memory allocations, timeouts, and environment variables for each function.

In Azure Functions, functions are organized into Function Apps. A Function App is a logical container for functions. Functions within a Function App can share common resources, such as application settings and connection strings. Functions within a Function App share the same resources allocated to the Function App, which includes memory and CPU.

Triggers (and bindings)

A trigger is a resource you configure to allow another service to invoke your function when certain events or conditions occur. Common use cases are: invoke the function on new upload in object storage, HTTP request, incoming messages in a queue, run function on schedule etc. Triggers are common for both AWS Lambda and Azure Functions.

What is different at Azure Functions is bindings. Binding to a function is a way of declaratively connecting another resource to the function; bindings may be connected as input bindings, output bindings, or both. Data from bindings is provided to the function as parameters. Triggers and bindings let you avoid hardcoding access to other services. Your function receives data (for example, the content of a queue message) in function parameters. You send data (for example, to create a queue message) by using the return value of the function.

Scaling

The Lambda service runs your function only when needed and scales automatically. You only pay for the compute time that you consume — there is no charge when your code is not running. When your function is invoked more quickly than a single instance of your function can process events, Lambda scales up by running additional instances. When traffic subsides, inactive instances are frozen or stopped. You pay only for the time that your function is initializing or processing events.

There is a default quota of 1000 concurrent Lambda instances on Account level, that can be extended to tens of thousands. If there is a sudden short period of high activity AWS Lambda allows temporary bursts of concurrent executions above your specified concurrency limit. AWS Lambda automatically scales function concurrency in response to the incoming load. Burst concurrency is a feature that enables your functions to handle temporary increases in traffic efficiently without the need to manually adjust your concurrency limits.

For Azure Functions, the scaling depends on the hosting plan:

Consumption, scales out automatically, to 200 instances for Windows and 100 for Linux
Premium, both manual and autoscaling, max to 100 instances Windows/Linux within a single plan (differs per region)
Dedicated, both manual and autoscaling. Using an App Service plan, you can manually scale out by adding more VM instances. You can also enable autoscale.

Duration

Duration refers to the amount of time that your function code spends processing an event, and it does not include the cold start time.

AWS Lambda functions can be configured to run up to 15 minutes per execution. You can set the timeout to any value between 1 second and 15 minutes.

For Azure Functions, the duration also depends on the hosting plan:

Consumption, the default is 5 minutes, and maximum is 10 minutes
For Premium and Dedicated, the default duration is 30 minutes, and the maximum duration is unlimited (interruptions may occur, up to 60 minutes guaranteed)

Logs and monitoring

When using Lambda, you are responsible only for your code. Lambda manages the compute fleet that offers a balance of memory, CPU, network, and other resources to run your code.

Lambda performs operational and administrative activities, including managing capacity, monitoring, and logging your Lambda functions. Lambda automatically monitors Lambda functions on your behalf and reports metrics through Amazon CloudWatch.

For Azure Functions, logs and monitoring dashboards are not available out of the box. You need to enable App Insights when you create the Function App or enable it afterwards. With this you add additional resources, App Insights, to your infrastructure, which comes with additional costs as well. Also you will have to get familiar with Kusto, the query language for the App Insights Logs.

Pricing

With AWS Lambda you only pay for what you use. Charges are based on the number of requests and the duration of code execution. Duration is calculated from the time your code begins executing until it returns or otherwise terminates. The price depends on the amount of memory you allocate to your function.

For Azure functions, charges are based on the number of executions and execution time, with different pricing tiers based on the plan chosen:

Consumption Plan, Billing is based on number of executions, execution time, and memory used. Usage is aggregated across all functions within a function app.
Premium Plan, Billing for the Premium plan is based on the number of core seconds and memory allocated across instances. This billing results in a minimum monthly cost per active plan, regardless if the function is active or idle.
Dedicated Plan, You are billed only for the plan, regardless of how many function apps or web apps run in the plan.

Summary

The above outlines the major features and capabilities of both services. The services have some similarities in features common for serverless functions, but on the other hand they are designed in very different manners.

AWS Lambda is a pure serverless service and setting it up is really straightforward, the user just needs to select the proper memory size.

For Azure Functions the available capabilities depend on the hosting plan you choose. If you are looking for a serverless option then it is the Consumption plan, unless you hit some limitations and have to go for the non-serverless plans.