AWS Lambda vs. Azure Functions: 5 Reasons to Choose Either

Serverless computing, also known as ‘Function as a Service,’ is one of the hottest trends in cloud computing. The word ‘serverless’ may be a little confusing, since actually at the very bottom servers are still in use. However, at the top layers, you can build and run applications and services without worrying about servers at all.

‘Function as a Service’ is a more explicit term, but in the end, it all boils down to the same process. You deploy your code directly to the cloud, run functions as a service, and pay as you go, but only for invocations and resources used. If your functions don’t run, you’re not paying.

The beauty of serverless computing is that it lets you forget about the code beneath the infrastructure, and at the same time it’s event-driven. Events are handled natively by the cloud. This feature relieves you of writing code for handling events, queues and so on. You can just focus on the core features of your application, and writing functions reacting to specific events.

A little bit of history

Amazon introduced serverless computing in 2014 with AWS Lambda. For almost two years there were no competing solutions on the market. In February 2016, Google released an alpha version of Google Cloud Functions, followed by Microsoft’s preview release of Azure Functions in March 2016.

At the moment, only AWS Lambda and Azure Functions are generally available. Microsoft announced the general availability of Azure Functions on November 15, 2016, while Google offers Cloud Functions as open-beta. If you want to use a mature service, Lambda would be the best choice. It has been generally available since 2015, and it offers you the best guarantee that you run your production on a tried-and-true platform.

Of course, when spoilt for choice, everyone will look for “the best” solution. However, when you juxtapose Lambda and Functions, it’s nearly impossible to name the winner. As it often happens in the IT world, the answer to the quintessential “Which of the two is better?” question is: “It depends.”

For the above reason, we cannot unambiguously judge that AWS Lambda is better than Azure Functions. Or vice versa. Instead, let us show you five criteria based on which one of these solutions may be more suitable for your needs than the other. The suggestions are ours, but the final decision is always up to you.

1. Your existing cloud

If you already made significant investments in either of the cloud platforms, and you have chosen AWS and gathered extensive experience with it, then Lambda will be a better choice for you.

The same applies to Azure Functions. If you’ve invested in Azure, then carry on with it. There’s no reason to leave everything behind and migrate to AWS. Especially that the cost of both, Lambda and Functions, is similar, and you won’t make any significant savings when switching from one to the other.

Usually, if you build your application from scratch, you will probably be able to adapt the code to both, Lambda and Functions. There are certain differences between them, but most of the times whatever is possible for the first solution will also work for the second one.

2. Supported languages

The languages supported by the platforms make up the biggest difference between them. At the moment, AWS Lambda supports Java, Node.js, Python, and C#. Azure Functions supports C#, F#, Node.js, Python, PHP, batch, bash, or any executable.

The fact that Lambda or Functions support a given language does not make either of them a better solution. But it may make one of them more suitable for your particular needs.

If your stack uses Java, and your developers have skills and experience in Java, then you have no choice but to go with Lambda. On the other hand, if all your team knows PHP, then Azure Functions will be better in your case.

Still, keep in mind that according to Stackify (https://stackify.com/trendiest-programming-languages-hottest-sought-programming-languages-2017/), Java is the second most used programming language, while PHP is the fifth.

Notwithstanding the above, remember that both services are under constant development. Support for additional languages is expected to be added in the future. If either of the solutions fails to support your preferred language now, this may change soon.

3. Integration with other services

This is the part where Lambda seems to take over Functions. Many of AWS services are natively integrated with Lambda. Lambda functions may be invoked not only by events generated by AWS services but also by Amazon Lex or Amazon Connect, for instance. Speaking of events, Lambda functions can be triggered by events from SNS, S3, Kinesis, DynamoDB, Cognito, CodeCommit, CloudFrond, CloudWatch, Alexa, IoT and API Gateway. You can also publish an API for the function with API Gateway. It is more flexible than Azure’s HTTPTrigger.

In Azure Functions, you can invoke code with a trigger or an input. HTTPTrigger is, of course, a trigger. A trigger defines an invocation method for a function, and a function must have exactly one trigger.

AWS Lambda functions have no such constraint. You can invoke the same function in many ways using different API Gateway methods. At the very same time, various events from different services may invoke your functions. API Gateway offers you also better flexibility at defining the function outputs. In Azure, you are tied to predefined outputs, while when using Lambda with API Gateway, you can map your function output to whatever you want, and do it outside of the function.

Lambda does not directly create the HTTP output (unlike Azure), which seems to be a more efficient approach. However, you may disagree, in which case you should go for the Azure’s solution.

4. Continuous deployment

When working with Azure Functions, you can deploy code in many ways. The following deployment sources are currently supported:

• Bitbucket
• Dropbox
• External repository (Git or Mercurial)
• Git local repository
• GitHub
• OneDrive
• Visual Studio Team Services

In Lambda, you can use CodePipeline, CodeBuild and AWS CloudFormation for automatic deployment. However, CodePipeline, for instance, lets you use Git repositories. The automation in Azure Functions is easier and runs more smoothly than in Lambda.

It is important to note that versioning is available for Lambda functions, whereas it doesn’t apply to Azure Functions. Here, you have to rely on Git or other version control system.

5. Monitoring

AWS Lambda by default gives you more information about code execution. Moreover, it uses CloudWatch to monitor and log your function output.

Thus far, analyzing logs and function output seems much more efficient in Lambda. AWS also provides another tool to identify and troubleshoot the root cause of issues and errors. X-Ray shows a map of your application components and helps you to understand how your application and the underlying services perform.

Other criteria

There are several significant differences between Functions and Lambda that don’t belong to any of the above categories:

• For example, you can invoke Lambda function from a Lambda function, while you cannot do so in Azure Functions.
• Another distinct feature of Lambda is the ability to create single functions. In Functions, you have to build Function Apps first, and then create functions inside of it.
• It is also worth mentioning that Lambda runs your functions in a kind of containers. When a function is not in use, it is closed and restarted upon the next invocation. In Azure Functions, you can decide if you want to run your code in a Consumption Plan, where you pay for execution, or in the App Service Plan, which lets you use a predefined capacity allocation with a predictable cost and without the few limitations typical for the Consumption Plan. In Lambda, you always pay as you go.

To conclude, if you are to choose between AWS Lambda and Azure Functions, you need to carefully analyze your needs, as the two platforms run neck and neck in many categories. Your choice will be determined by diverse, and sometimes very subjective, criteria.