Visual Studio Online is found under the Function’s App Service’s tools section. It’s worth noting that there are some other cool tools here too, including a console.

Most of your development time should be outside of dashboards anyway. I don’t consider them a huge factor in my decision making process but they can offer convenience.

System Structure

Let’s dive into the architecture of Azure Functions compared to Lambda.

An “App Service” is a container, or environment, for a set of Azure Functions. This is much different than Lambda. In fact, the two services couldn’t be more different.

Lambdas are organizationally independent, where Azure Functions are grouped logically into an “application.”

This App Service can either by “dynamic” or “classic.” The dynamic option is where you pay only for the time and memory your functions use. This is the biggest similarity between Lambda and Azure Functions.

It’s important to note that the memory you allocate is per app service (with potentially many functions), not per function like Lambda.

I think of the “classic” App Service more like Amazon ECS where you have EC2 instances running to handle the tasks or functions. The pricing model for this is then like EC2.

Azure is actually more like a blend between ECS Tasks and Lambda. For example, you can set environment variables on App Services which are then available for your Azure Functions. AWS Lambda cannot persist environment variables, but ECS Tasks can (correction/update: Lambda now can as pointed out by Jeremy Axmacher, thank you).

The entire container architecture is different. Lambdas provision a brand new one and deploys your code (from a zip file) on a cold request. Subsequent requests can be subject to container re-use and be handled much faster. However, you need to understand there is no persistence and with Node.js Lambdas you need to watch your variable scope because the container can be re-used.

However, Azure Functions are less subject to the cold/warm request effects. Azure still provisions resources as needed, but your files aren’t “frozen” somewhere in a zip file. They run on top of Azure’s WebJobs.

Azure Functions are also supposed to be accessible via FTP by connecting to the App Service’s FTP. Though I couldn’t get it to work so far during my review (no matter how many times I reset my credentials).

Azure Functions of course is a Windows system (32bit for dynamic services) while Lambda is a Linux system. Though I do hope that changes since Ubuntu can now run on Windows. In fact, that would put Azure in a good position with cloud hosting.

Continuous Deployment

Speaking of working with the files, you can deploy your Azure Functions in a variety of ways:

Git (you can connect GitHub, Bitbucket, etc.)

Dropbox

OneDrive

Visual Studio Team Services

Visual Studio Online editor

Cloud function’s own editor under it’s settings area (limited to just the code and the function.json)

You have many more inherent options than AWS Lambda, but I didn’t explore any sort of CLI deployment. Lambda has some great 3rd party tools for deploying Lambdas and both cloud services have SDKs to make just about anything possible.

I do have to hand it to Microsoft here though. You can hook up GitHub, even with your favorite CI tool, and easily deploy your cloud functions to Azure. Release managers rejoice.

Though it’s important to note that Lambdas can be versioned whereas Azure Functions can not (at least not yet). So if you wanted to rollback, you’ll need to rely on Git or some other version control system.

Run Your Functions Anywhere

One challenge with Lambda is development workflow. People have created tools to test your Lambda locally so you can write code, run, and then even deploy if all looks good.

There are also several “serverless frameworks” that help with this process too.

Regardless, Lambda is closed source. However, Azure Function’s runtime is open-source. I would expect some clever CI integrations in the future.

Function Triggers & Integrations

I also have to concede that Azure Functions make things a bit easier in this department too. Every function automatically maps to an HTTP endpoint if enabled. Whereas with Lambda, you must configure API Gateway separately.

API Gateway is fine, but complex and time consuming. Again, some serverless frameworks ease this pain point by automatically setting up an API for Lambdas.

Microsoft gets points for UX because you have a lot less to configure. I’m not sure you can run Azure Functions from multiple triggers though. It doesn’t appear that way, but maybe by editing the function.json directly you can.

I would say that AWS Lambda has a slight edge in flexibility here, but both services are constantly changing.

The Azure app and function names are reflected in the URLs to trigger the cloud functions. This helps avoid confusion, but might also be limiting.

Apparently all HTTP methods are supported (GET, POST, etc.) through the endpoint assigned to each cloud function. With API Gateway, you need to configure each method manually.

One thing I don’t see is path variables. It seems that everything must be passed as a querystring or in the request body.

To be fair, it’s called an “HTTP trigger” so when thinking about it in those terms, it makes sense. If you need more robust settings, then you’re talking about “API configuration and management.”

Azure Functions also have super easy authentication. You can protect the cloud function endpoints with 3rd party authentication; this includes Facebook, Twitter, Google, and of course Microsoft’s auth.

I’ve never setup Facebook auth for an HTTP endpoint so quickly and easily before in my life.

You can configure CORS and you can also manage your own domain name for the endpoints. Though I couldn’t see if there was a way to limit the HTTP request methods. I imagine with Azure’s API management service more will be possible, but then you’re going through as much work as API Gateway.

I don’t think there’s a clear “winner” here. Both Microsoft and Amazon have powerful features for triggering cloud functions with HTTP requests. Though I definitely think Amazon could learn a thing or two about UX from Microsoft.

Azure Solves a Few Pain Points

I was thoroughly impressed by Azure and I think it’s in part due to its new dashboard. The new dashboard and the process of setting up cloud functions in a logical group called an “app” makes complete sense.

To illustrate how obvious this pain point is, look no further than Serverless (formerly JAWS) and Apex. These are two serverless frameworks that address this specific organizational concern. They help a developer logically group functions.

Another pain point with Lambda is the maximum execution time limit. It wasn’t always clear and many people never thought their functions would run that long (at least in my experience).

The time limit used to be 1 minute for Lambda, but increased to 5 to help with “ETL” operations according to Amazon. I’m happy for the time limit increase, but even 5 minutes may not be sufficient for all operations.

Iron.io pointed out that their workers had no time limits in a comparison with Lambda. Iron workers are another option, though I stayed the course with AWS Lambda. I even found a way to re-purpose your Lambda code as ECS Tasks to cope with the 5 minute limit.

While that solved my own problems with the time limit, I understand that it’s not a solution for everyone. It also requires EC2 instances which are billed in a different fashion. So it’s not a perfect solution if “pay as you go” is a top priority.

Azure’s Functions really are the perfect blend of Lambdas and ECS Tasks. You can write and execute the same exact code regardless of the environment and billing model. There are apparently no time limits either(so long as your function is not idle).