AWS Lambda & Azure Functions
Amazon’s AWS Lambda and Microsoft’s Azure Functions are very similar in many ways. They’re both FaaS (functions as a service) or “serverless” services. They have similar pricing models and support many of the same languages. Still, there are significant differences between them, which could influence which one is better for your needs.
The most basic difference is the underlying operating systems. Lambda, like most AWS services, runs on Linux. Azure Functions runs on Windows. Perhaps this shouldn’t matter in a serverless environment, but you’ll normally want to call other services from your functions, and the available choices reflect the underlying software. The operating system environment affects many aspects of deployment, configuration, and debugging. If your development team has a strong commitment to one operating system or the other, that could make a difference.
Lambda was launched in 2014, Azure Functions in 2016. Lambda is ahead in market share and has an edge in maturity and stability, though Azure Functions isn’t far behind.
AWS Lambda vs. Azure Functions: Pricing
The pricing models for both services are similar, and there’s very little difference in how much you pay. In both cases, the cost is based on two factors: the number of function invocations and the number of gigabyte seconds used. With Azure, you pay $0.20 per million executions, plus $0.000016 per GB second. The first million executions and first 400,000 GB seconds are free. There’s no charge while the code is lying idle between executions.
With Lambda, prices are so close that they’re obviously watching each other. The first 400,000 GB seconds are free, a million requests cost $0.20, and GB seconds are a shade more expensive at $0.00001667.
In both cases, storage is a separate service, which you have to pay for. Functions don’t maintain any persistent storage or state by themselves.
It’s possible to pay for Azure Functions under an Azure App Service plan, but that approach is more like a PaaS model. A VM is dedicated to your functions, and you pay to keep it. For this article, we’re comparing the serverless offerings. The one for Azure Functions is called the Consumption plan.
AWS Lambda & Azure Functions: Design Differences
The basic FaaS concept is the same for both services. The developer creates and deploys functions. Events invoke or “trigger” them. Calling them by HTTP is the most common scenario. But there are differences in the elaboration of the concept.
In Lambda, each function is a separate unit. You can install any number of functions in a single operation, but each one has its own environment variables. You can build applications out of them, to a limited extent, with AWS Step Functions, which implement a state machine.
The only way to deploy software to Lambda is to upload a zip file with the code. In an automated development process (such as we use at Entrance), this is a transparent step. Azure Functions offers a richer set of deployment options, including integration with code repositories such as GitHub and Bitbucket. On the other hand, Lambda supports versioning of functions, which isn’t available with Azure.
AWS Lambda and Azure Functions: Supported Languages and Environments
The choice of languages could be an important factor in choosing between the services. Microsoft’s service supports C#, JavaScript (Node.js), and F#. It lists other languages as “experimental,” including Python, PHP, TypeScript, Bash, and PowerShell. Java is in the works.
Lambda lists JavaScript (Node.js), Python, Java, C#, and Go as its supported languages. Developers on Lambda can use .NET Core, so they aren’t completely divorced from the Microsoft world.
The biggest difference is in the associated services which are available. With Lambda, developers can use S3 storage, use Elastic Beanstalk and EC2 where virtual machines are necessary, and access databases through RDS. Azure functions developers will use Azure Storage, supported databases such as Azure SQL, and Windows or Linux virtual machines. Each environment has its own flavor, and AWS has the greater breadth of services. For many developers, familiarity with the available services may be as important as their inherent technical qualities.
Kinds of applications in AWS Lambda and Azure Functions
Leaving aside support for languages and services, the most important difference between these two FaaS services is the organizational philosophy.
Azure’s function apps encourage thinking of the “application” as the unit. The configuration files apply to the whole app, and resources are allocated to a function app. Lambda promotes a more atomistic approach, with each function being its own entity and getting its own resources. This could encourage an approach in Lambda where each function is largely independent of the others, while Azure Functions may promote an approach where the functionality overlaps heavily. However, both allow calls to libraries, objects, and subroutines from top-level functions, so there really isn’t that much difference. For more discussion of the differences, see our introduction to AWS Lambda.
Each service has a distinct approach to triggering functions. Azure is somewhat simpler, while Lambda’s approach is more versatile.
The important distinctions are going to be in the language which the developers prefer (if it’s only available on one of the services) and, above all, the related services which are available. Amazon has the advantage here, with a powerful set of services that Lambda functions can invoke.
Let’s say you want to implement a system to retrieve and update information in an employee database. It will process requests from a Web page, with each request type being a function. Only authorized users can access it, so it will use AWS Identity and Access Management or Azure Active Directory for authentication. It will need access to a database server. Azure strongly encourages the Microsoft SQL Database, while AWS offers a variety of database software. It works either way, but AWS often offers more options.
Are you looking to set up services in AWS? Get in touch with us to learn how we can help.