AWS Lambda vs. Microsoft Azure Functions

Let’s compare two FaaS: AWS Lambda and Microsoft Azure Functions. We’ll look at the brief history of each, and compare and contrast their features.

Let’s start with a simple question: Why work with multiple FaaS providers?
One of the crucial components of any application’s reliability plan is what to do when a provider goes down. If AWS is unresponsive, or Google Cloud has a bug, how will your application be affected? Applications that take this into account in their design will often need to rely upon federating third-party functionality in order to ensure maximum reliability. When developing Function-as-a-Service apps, the federation options are limited to a small number of providers. As you might have guessed, in this post, we’ll examine AWS and Azure.

AWS Lambda

AWS Lambda is a Function-as-a-Service serverless code execution platform launched at re:Invent in 2014. Building upon the concepts of containerization, AWS Lambda uses the AWS Machine architecture to reduce the scope of containerization, letting you spin up and tear down individual pieces of functionality in your application at will. Functions run on Amazon Machine Instances, which are immutable web server objects that can be instantiated quickly in response to dynamic API requests. By leveraging multiple AWS services and functionality, you can build an entire application without having a true “server-side” set of code to manage.

Microsoft Azure Functions

Microsoft is one of the newer players in the serverless realm. While they have offered significant Platform-as-a-Service functionality for several years, it wasn’t until March of 2016 that they entered the serverless app environment with the launch of Microsoft Azure Functions. The addition of these on-demand server-side functions augmented the Azure platform with the ability to run arbitrary code in temporary execution environments.

Supported Platforms and Languages

One of the first items in any evaluation of a serverless provider is what languages are supported. Both AWS Lambda and Microsoft support Node.js, Python, and C#, for example. However, AWS Lambda provides further support for Python and Java, while Azure Functions provides support for F# and PHP. Additionally, both run on different execution platforms – AWS Lambda is built from the AMI, which runs on Linux, while Microsoft Azure Functions run in a Windows environment.

Which language you choose is a question of which languages your development team will be productive in, and as such, the cross-section of Node.js, Python, and C# support should meet the needs of the majority web development teams. However, it is important to note that both Amazon and Microsoft are continuing to expand their language support offerings, and this likely won’t cease until all providers are pretty close to language parity. As such, if your chosen vendor doesn’t support your chosen language, then it may not be as drastic of a setback as you’d imagine in a more traditional server-based application. For the purposes of federation of third-party functionality, though, it’s important to pick a language that all platforms in your application’s architecture support so that you can minimize the work necessary to port the code between different FaaS providers.

Supported Function Triggers

Both AWS Lambda and Microsoft Azure Functions offer dynamic, configurable triggers that you can use to invoke your functions on their platforms. With AWS, these are sent from other AWS services – you can configure an API trigger using API Gateway, a dynamic trigger on a DynamoDB action, a file-based trigger based on Amazon S3 usage, and so on. With Microsoft Azure Functions, you’re given a similar set of triggers. They allow access via a web API, as well as invoking the functions based on a schedule. Microsoft also provides triggers from their other services, such as Azure Storage, Azure Event Hubs, and there is even some support for SMS-triggered invocations using Twilio.

There’s no clear winner here, since what is a deal breaker for one application could be a desired trigger feature for another. As such, it’s important to be aware of what options you have available and, when working with federated services, it is doubly important to ensure you can enforce similar patterns of behavior between the disparate platforms. Addressing this problem comes at the design stage and should be taken into account when building out your application’s architecture.

Other Differences

As with any comparison of offerings between two different companies, there is never going to be complete overlap of functionality and approach. When comparing AWS Lambda to Azure Functions, this is no different. One difference is in the availability of the functions. AWS Lambda spins up a new instance if a function has been inactive for a period of time (usually around 10 minutes). While future calls within that 10-minute inactivity window will use the same instance if they are able, that first call after a long period of inactivity will result in a noticeable delay before the function responds, as AWS needs to spin up a container with the appropriate resources to execute your application. Microsoft Azure Functions, being built on top of Azure Web Jobs, are also subject to this restriction, but due to the underlying architecture this hot/cold divide seems to be less pronounced in the Microsoft ecosystem.

Another difference is in organization. AWS Lambda functions are built as standalone elements, meaning each function is essentially its own independent program. Azure Functions, on the other hand, are grouped together in an application. This allows multiple Azure Functions to share a single set of environment variables, for example, while AWS Lambda functions need to specify their environment variables independently. However, this also affects how application resources are allocated to functions – AWS Lambda provisions memory per-function, while Microsoft Azure provisions memory per application group. Again, there’s no “right” or “wrong” here – just two different approaches to what is essentially the same feature set.

Conclusion

Working in a serverless environment can save your organization effort when compared with a traditional client-server approach, but is not without its own unique reliability quirks. As such, it’s important to have a full understanding of the platform being used to provide your app’s server-side business logic, whether that is a Linux-based platform like AWS Lambda or a Windows-based suite of services like Microsoft Azure. The beauty of serverless development is that, with minor changes, the code you write for one service should be portable to another with little effort – simply modify some interfaces, handle any input/output transforms, and an AWS Lambda Node.JS function is indistinguishable from a Microsoft Azure Node.js Function. If your application is dependent upon a specific provider, however, it can pay to tie yourself more deeply into their ecosystem by leveraging service-provided triggers to execute your app’s logic.

Source: dzone.com