Whether you're a hyperscale cloud provider, software developer or enterprise admin, one of the hottest technologies right now is serverless computing. Also known as functions as a service, these event-driven services allow organizations to deploy application code, without provisioning a VM or container cluster, when another cloud service passes along selected triggers.
Cloud functions are a natural extension of platform as a service (PaaS). Not only do functions insulate cloud admins and developers from the details of servers and storage, they completely abstract code executions from underlying runtime infrastructure and OSes. Functions run in response to external triggers, so they are best suited to deployments that use microservices and event-driven components, not persistent, long-running applications.
Starting in 2014, Amazon Web Services popularized the serverless model with Lambda, but other cloud providers, including Google, IBM and Microsoft, have also launched functions-as-a-service offerings. Microsoft's service, released last November, is called Azure Functions.
Microsoft Azure Functions 101
Microsoft Azure Functions is based on the WebJobs software development kit used in Azure's App Service PaaS. This allows you to run a program or script as part of a web or mobile app, or to expose it as a callable API. As such, Microsoft Azure Functions can use WebJobs features that make it easier to work with Azure Storage and the Azure Service Bus, a publish-and-subscribe message queue.
A function includes the execution logic written in a supported language, as well as a JSON configuration file that describes function bindings, such as name, data type and whether the binding sends or receives data.
Best practices for Microsoft Azure Functions
Microsoft offers the following best practices to use Microsoft Azure Functions:
- Each function should have a single purpose, such as a microservice, not a monolithic application.
- Functions are idempotent. This means calling a function with the same parameters yields the same result, independent of system state.
- Execution times should be brief; break up long-running jobs into constituent functions.
- Functions should have few internal dependencies to help minimize runtimes and allow them to be deployed and scaled in parallel.
- Functions should be stateless and exposed via HTTP REST APIs for integration with other functions or services.
As an event-driven service, Microsoft Azure Functions is well-suited to process data, including from internet of things (IoT) devices; build microservices; create shims to integrate other code modules or cloud services; or build APIs. The following Azure events or services can trigger functions:
- Storage blob activity, such as adding or changing data in a container;
- Event Hubs activity , such as streaming data for IoT;
- Web events, such as HTTP requests or webhooks;
- Azure Service Bus; and
- Timers for scheduled activity, similar to a Cron job.
Microsoft Azure Functions also integrates with the following Azure and third-party services that post event triggers:
- Azure DocumentDB
- Azure Event Hubs
- Azure Mobile Apps
- Azure Notification Hubs
- Azure Service Bus, including on-premises services that can publish to Service Bus queues
- Azure Storage
- GitHub via webhooks
A simple example that illustrates serverless design is the use of Microsoft Azure Functions to respond to and process a web form. Instead of having a web server always running and waiting to process user input, a function does the job on command. Once activated, the function can display one of several forms stored in an Azure blob, process the submitted fields and store the results in an SQL or NoSQL database.
Comparison with AWS Lambda
Microsoft Azure Functions is similar to other serverless offerings, notably AWS Lambda. There are, however, important differences, including:
- How each handles persistent data: Both services use stateless containers as the execution mechanism, but Microsoft Azure Functions can also run in the context of an Azure App Service application with a dedicated VM that allows you to store a state from one execution to the next.
- Supported event sources on each cloud service: For the latest list, see the developer documentation for Lambda and Microsoft Azure Functions.
- Pricing model: Both vendors bill for these services based on a combination of total execution time and the number of function requests. However, the rates and amount of uncharged activity differ. Be sure to review the latest rates for Lambda and Functions on their respective websites.
General recommendations for serverless
Since serverless functions are a new concept, organizations still use trial and error to discover when they should and shouldn't use them. Functions work well with event-driven programs, such as processing user input or responding to events in an asynchronous message queue. Like general-purpose PaaS, functions are advantageous for new applications where you have little idea of initial capacity requirements, but expect usage to be sporadic, bursty and grow over time.
For example, a common use of message queues is to process data as it arrives from an external source, such as filtering and normalizing IoT metrics before they're stored in a database, or compressing and changing the format of image or video files as they are uploaded. Organizations can also use functions for batch jobs to repurpose Cron jobs to the cloud.
Azure Functions and AWS Lambda battle for serverless market
Get the right skills for serverless success
Event-driven apps will change the public cloud market