At this month's Build conference, Microsoft announced a preview of Azure Functions, a service that runs code on-demand. Azure Functions is Microsoft's entry into the increasingly-popular space of event-driven, serverless computing occupied by Amazon, Google, IBM, and others.
Azure Functions lets developers publish code that's executed based on external triggers, without worrying about provisioning compute or storage resources. These functions — written in C#, JavaScript, Bash, F#, PHP, PowerShell, or PHP — often represent short-lived, asynchronous tasks. In a blog post about the Preview release, Microsoft highlighted "data processing" as a reason for this type of service.
Data is everywhere. It's in the Cloud, on-premises, and is increasingly proliferating across Internet-connected devices. Organizations are working to unlock the value in that data, and are asking their developers to respond with highly-scalable solutions built on ever-compressed timetables. Solutions which often require developers implement on demand or scheduled batch jobs to reconcile transactions, ingest and process data, or react to events in real-time.
Developers trigger Azure Functions in a variety of ways, including HTTP calls, changes to Azure Queues or Blob Storage, and via cron schedule. Microsoft points out that HTTP support makes Azure Functions an ideal recipient of webhook messages from Software-as-a-Service apps.
Microsoft offers two hosting options for Azure Functions: the traditional App Service plan or the new Dynamic Service plan. This choice has an implication on scalability and cost. In the App Service plan, an Azure Function runs on a dedicated virtual machine, and a Function may share the server with other apps running in the user's account. If one chooses the Dynamic Service Plan, then the Azure Function runs in parallel across app instances that automatically scale based on utilization. In this plan, the user only pays for the instance execution time whereas App Service plan users pay for the host VM, regardless of utilization.
Developers create these single-purpose functions from a starter template, or from scratch. Microsoft provides a web-based development environment, and also enables a Git endpoint for local development and continuous integration using GitHub, Bitbucket, Visual Studio Team Services, Dropbox, and more. The web-based IDE features language-specific syntax formatting and code completion hints, and some basic testing tools. In the function's application settings, users can specify the amount of memory available to Azure Functions (up to 1536MB), whether to apply user authentication or not, and how to expose service metadata.
Microsoft built Azure Functions in 90 days on top of existing Azure services like App Services and WebJobs. According to Microsoft, simplicity was key. They introduced a feature called "bindings" that decouple the Azure Function code from the data source or destination.
With Functions bindings, developers can simply interact with other data sources and services through their Function without worrying about how the data flows to and from a Function. Bindings make tasks like adding a message to a queue or fetching a Blob as simple as passing JSON to a Function output variable or reading the Blob from a Function input variable. With this capability, developers need to know very little about the underlying services they're interacting with, making it simple to swap out later for a different service.
Microsoft is hardly the first to introduce a serverless computing model. While this service may sound somewhat similar to traditional Platform-as-a-Service (PaaS) offerings, Microsoft claims Azure Functions extends the PaaS concept by offering pay-per-execution billing and instance scaling based on consumption. Azure Functions is more similar to products like AWS Lambda, Google Cloud Functions, IBM Bluemix OpenWhisk and WebTask from Auth0.
Azure Functions differs from AWS Lambda in multiple ways, including an open-source runtime, broader language support, and no execution time limit. In a blog post, technologist and AWS Lambda user Tom Maiaroto did a comparison of the two services and considered Azure Functions to be "radically different than Lambda under the hood".
An "App Service" is a container, or environment, for a set of Azure cloud functions. This is much different than Lambda. In fact, the two services couldn't be more different.
Lambdas are organizationally independent, where ACFs are grouped logically into an "application."
...
Azure is actually more like a blend between [EC2 Container Service] Tasks and Lambda. For example, you can set environment variables on App Services which are then available for your ACFs. AWS Lambda cannot persist environment variables, but ECS Tasks can.
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, ACFs 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.
...
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.
Azure Functions is free during this preview period, and after that, Microsoft will charge based on compute utilization and per-million requests. The UX experience is open sourced on GitHub, as is the WebJobs SDK. Coming up, Microsoft says they are working on additional language support, local development options, and integration with other Microsoft services like the Azure Service Bus.