What AWS Lambda Users Should Know About Azure Functions, and Vice Versa.

In my previous post, I explained about my painful multi-cloud experience and lessons that I learned. Regardless of which cloud platform you are using, I recommend you to read it to avoid our mistakes. I’ve encountered a surprising high number of Cloud developers who have never tried other providers. That’s why in this post, I would like tell about the differences between AWS (Lambda) and Azure (Functions). Aim of this post is NOT to tell which one is better. They are both good with their own pros and cons, indeed I would like to clarify this with some facts. Hopefully this post can encourage users of each FaaS to give the other one a try.

I’ve tried to be fair on my points by providing facts for my claims, and they are valid at the time of writing this post. However, if you disagree with me on any point, I’m more than happy to hear your comments.

Similar to AWS, Azure has a rich set of offerings for serverless consumers: functions, orchestrators, powerful tooling for local development. But Azure (functions) are implemented and used in a different way compared to AWS (Lambdas); therefore, developers with AWS background can have difficulties if they try to use functions in Lambda way. Here are some differences (1):

Community support

There is a strong community support for Azure Functions. You can ask your questions in Microsoft Developer Forum — Azure Functions or alternatively post your questions on StackOverFlow using the tag azure-functions-core-tools. I asked many questions, and for each question I got my answer in less than 24 hours. I really like it that there are many experts who are actively trying to solve your problem.

This is very opposite to my experience with SAM (AWS own framework for developing and debugging serverless applications) on Lambda forum or on stackoverflow, where many questions remain unanswered. So, thumbs up for Azure and its great community.

Observability and Monitoring

Unless your function is running on Kubernetes, you can’t get function logs through cli (using Core Tools). Serverless Framework and AWS SAM, both have the feature of log live (log — tail) and it’s quite handy, so user doesn’t have to always check Portal to find latest logs.

And when you use Portal (to be specific Azure Monitor), there is minimum 3 minutes delay to get you function logs (based on my experience for a bare simple function). This can get annoying. Even though there are some workarounds for this problem, I would expect my monitoring tool to have little delay by default. As comparison, AWS CloudWatch can get logs in around 30–45 seconds.

However, I should admit that I’m excited about capabilities of Application Insight (which is part of Azure Monitor). Application Insight helps you to monitor and to observe your application. It has some interesting capabilities such as Smart Detection (name should be self-clear). Especially, I find Azure Workbook a handy tool. It helps you to easily and within few seconds combine different capabilities of Application Insight and to get some enlightening reports about your app. Also, Live Metrics System can be very useful: within a short delay (1–2 seconds), it shows status of your application at a glance (2).

Azure Portal

Azure Portal is fancier than AWS Console, however there are some issues with it:

• It’s sluggish. Sometimes it keeps loading a requested page, forever.
• It has bugs: many times, I encountered Rain Cloud error (here you can find more about this error). In contrast, I’ve rarely encountered any UI related error while working with AWS.
• For Function App part of the portal, routes aren’t defined. So, if you refresh the page, you need to start from the beginning to get to page which you left. This part can get annoying. It’s interesting that other services don’t have this problem. For example, if you explore Storage Account section, you can refresh the page and stay on were your left.

Documentation

In my opinion, one of the major problems with Azure is its documentation; I find some part of the doc confusing. Here are few examples (3):

• Azure Functions deployment options are not clear and indeed I find the official doc misleading. Instead, I find this unofficial post by former Azure team member more clear and understanding.
• CosmosDb node.js SDK is documented here, and you can find samples for some (not all) methods in here. Whereas samples for .NET apps are more comprehensive. Personally, I find it more convenient the way AWS SDKs are documented. Developer can see sample values for each option so doesn’t need to search for them somewhere else.

I believe if the Azure documentation gets organized better, it can reduce developers struggle to find the information from “somewhere”. Firstly, I thought it’s just me who have this problem; therefore, I asked six skilled AWS developers who tried Azure. All of them confirmed that sometimes they find Azure doc confusing too. Also, it could be that we are used to the way that AWS is documented.

It happened couple of times that by reading Azure doc, I got more confused or even got mislead and took a wrong approach. Also, I find it difficult to start working with Azure (having AWS background): often I got headache to make basic things to work and ended up doing them by try-and-error. This can improve by documentation.

I would recommend Azure team to work more on their documentation, if they are willing to grab AWS developers to their platform.

Out of the box features

I like the fact that Azure Functions features aren’t just a copy of AWS Lambda’s. Indeed they have come up with some interesting features. For example, I find Function Bindings handy. They enable you to process data on fly. Let’s say you have following API:

http://host.com/api/get_cat/{cat_id}

With help of CosmosDb input binding, you can retrieve the items on the fly and without the need to call SDK inside your function. To explain, this can be your function:

module.exports = function (context, req, cat) {
context.log(‘This is the retrieved cat from Cosmosdb’ + cat);
context.done();
};

Another interesting feature is KUDU console. “With KUDU you can get access to log files, environment information/variables and also the actual file system on the runner instance that was assigned to your Azure Function.”. More about it you can read here.

Main Takeaway

Most probably, the differences that I’ve just outlined will be invalid in near future. But main takeaway of this post is probably the long lasting one: When you start working with a new Cloud Provider, get rid of your previous assumptions , learn how the new provider is trying to help you, follow its rules, and its way of thinking. In other words, if you are e.g. an AWS developer, do NOT try to get your Azure task done in AWS way; otherwise, you’ll just get headache and will end up insulting Azure. If you follow my advice, there is higher chance that you will enjoy working with the new provider. At least this was my experience. Again, I’m more than happy to hear your comments.

Acknowledgement

I would like to thank Klaus Venesmaa, Olli Välkki and Jarno Hilvenius for helping me with this post by their comments.

Notes

(1) Please notice that I haven’t addressed performance on this list, as you can Google and find many benchmarks

(2) So far, I have mainly played with Application Insight features. When I get time, I’ll write a separate blog, assessing capabilities

of Azure Monitor in detail (earlier I wrote a blog about AWS X-Ray and some observability providers)

(3) The two addressed doc’s issues are just from my perspective and are valid at the time of writing this blog. Others may or may not find those doc parts confusing.