Comparing Azure Functions and AWS Lamba
If you are a software developer, or a DevOps engineer, you probably have heard of serverless computing, a service allowing you to run code without worrying about where or how it gets deployed. In Amazon AWS this service is called AWS Lambda, and in Azure.... Azure Functions. The principle is the same: write a function in the language of your choice, and run it (on schedule, or based on an event).
In this article I am going to compare at a high level some of the key features of each service and also look at pricing. Specifically I will compare the languages available, primary features and capabilities, and pricing as advertised by both vendors as of June 2018.
At a high level, serverless computing allows corporations to build scripts (or simpler programs) that can run on a schedule or when triggered by changes external to the function. As a consumer of this service, you are charged by the amount of time a function takes to execute, the amount of resources (such as memory) the function consumes, and and often it runs.
Azure Functions and AWS Lambda functions are perhaps the most prominent serverless computing models available today, so let's take a closer look at both services.
The first thing to note about serverless computing is that you can choose the language to write your logic in. The list of languages may change over time, but it is fair to say that most developers will find a language that works for them, making it easy to get started.
Experimental and preview languages are usually not supported for production workloads; however they give you a hint at what's coming.
Exp. stands for experimental.
Let's take a look at the platform specific capabilities of both environments.
Generally speaking it is possible to write your own functions on a local computer, and download/deploy the code to the serverless environment. The steps involved in making this work differs somewhat depending on the language.
The AWS online editor provides a standard application-like experience with a top menu (File, Edit...), whereas the Microsoft environment gives you a simpler and more concise interface. Both provide contextual menus that give you important shortcuts. Although the Amazon editor seems to provide more advanced options, such as the ability to collapse/expand code sections, it is limited to a couple of languages. Although I found the AWS editor a bit confusing with surrounding panels that provide options and configuration settings, it can be maximized if needed so that you can just focus on the code.
AWS Lambda Code Editor
Azure Function Code Editor
Configuration settings accessible by your function make it easier to modify application behavior without having to change your source code. For example you can store database connection strings in application settings.
Both AWS Lambda and Azure Functions give you the ability to store configuration settings externally; however it seems that Azure Functions provide additional capabilities. Lambda functions seem to be limited to Environment Variables for this purpose; perhaps this simplicity can be viewed as a strength.
Azure Functions provide multiple configuration settings, at the function level, or the application level. There is also a Json configuration file that can be used. As a result it is easier to share configuration settings with multiple functions. A nice feature of Azure Functions is that certain configuration settings are not readily visible when you first load the configuration screen; you can still inspect connection strings, but it requires you to click on the value first, which provides a basic form of privacy.
Triggers & Event Sources
One of the major features of serverless environments is the ability to trigger the execution of code based on external events, in addition to simple HTTP calls or a scheduler. For example, you can trigger a function to execute when a new message arrives in a message queue, or when a new blob is created. These triggers provide an efficient way of building event-based solutions. Both Azure and AWS provide a large array of events that can trigger execution of your functions.
Interestingly enough, not all triggers are available depending on the programming language you choose in Azure; on the other hand Azure seems to provide a slightly larger array of options compared to Amazon. Both solutions provide you a mechanism to trigger actions from IoT scenarios, Service Bus messages, simple HTTP triggers and NO SQL stores (such as Aurora and Cosmos DB). You can also trigger code from cloud provide events (Event Grid and Application Insights for Azure and Cloud Watch for Amazon). Of course Amazon gives you a handy trigger for all things Alexa.
Last but not least the pricing model for both solutions is very reasonable, allowing you to test at a very low cost since there is a significant amount of free usage.
In order to compare costs, I used the AWS costing samples and plugged the values in the Azure calculator. It is important to note that these costs are based on public information provided by Amazon and Azure, and as a result should be considered estimates. In both cases, pricing is calculated down to milliseconds (although the Azure calculator only offers seconds).
(*) the Azure calculator only provides seconds for execution time, so to obtain the cost I used 1 second for execution time, and 5 times fewer executions (6 million), and added an extra 24 million requests separately to see the increase on Requests cost to derive the total cost.
In summary, both AWS and Microsoft provides a strong serverless infrastructure that allows developers to build simple solutions and execute based on various triggers. And while Azure Functions appears marginally cheaper both offer a good amount of free usage.
Everything else being equal, it seems that the language choice can drive you to one platform or another. For example if you are comfortable with Python, AWS Lambda would probably be the platform of choice. However if you are a C# developer, the ability to use the online editor may drive you to Azure Functions.