Serverless computing offers a way to more easily deploy and manage complex enterprise apps. Learn how options from AWS and Azure differ in terms of pricing, triggers and containers.

Despite the advantages of cloud services, such as Amazon Web Services and Microsoft Azure, they still come with overhead. Whether its virtual servers, object storage buckets or SQL databases, you must provision resources before using them. While that seems like an obvious requirement, it does add cost, time and friction to the cloud experience.

But what if the system could automatically provision services and execute jobs in response to events, such as a message from another application? That's the principle behind serverless applications, also referred to as cloud functions. Let's explore the details of two serverless computing options: AWS Lambda and Microsoft Azure Functions.

Triggers and languages

Although cloud functions are a new concept, there are already several service options. AWS Lambda is the leader, but there is also IBM Bluemix OpenWhisk, Google Cloud Functions and Microsoft Azure Functions.

Microsoft Azure Functions, still in preview, builds on Azure's existing platform as a service features, notably App Service and WebJobs, which simplify the development of back-end components for mobile- and browser-based applications. Microsoft Azure Functions is a set of code modules written in JavaScript, C#, Python and PHP that only execute when triggered by an external event, such as changes in storage containers, activity on a message queue or access from an exposed HTTP API. Triggering events aren't confined to Azure; they can come from a third-party or on-premises system.

Triggers in AWS Lambda are called event sources, which can also come from other AWS services or external applications. Users configure mapping between event sources and AWS Lambda functions. For example, a function might execute each time a user creates an object in a Simple Storage Service (S3) bucket and has permission to run the AWS Lambda code. Supported AWS Lambda events include S3, DynamoDB, SNS notification and CloudWatch activity.

Users can also invoke functions on-demand, using, for example, a mobile app with the AWS SDK to execute an exposed AWS Lambda API. AWS Lambda functions can be written in Node.js, Python or Java.

The role of containers

Both Microsoft Azure Functions and AWS Lambda run in a container; however, the implementations and limitations are different. Azure cloud functions are built using the Azure App Service container architecture, but users can deploy them as either part of an App Service plan or individually as a Dynamic Service plan. The former runs functions in the context of a dedicated VM that is always available, regardless of whether the code is executing.

Dynamic functions run independently and can automatically scale across multiple VMs. Dynamic functions are best for intermittent jobs that execute for a short time, while App Service functions are better for functions that run for long periods and run on underutilized VMs.

AWS Lambda functions also run in containers, in which users specify the amount of memory and maximum execution time. When the function triggers, AWS Lambda launches a new container based on that configuration. Since container setup and booting take time, Lambda maintains a container for a while -- AWS doesn't specify the details -- in case the same function is repeatedly invoked to minimize execution latency. Each container also has some temporary disk space that is frozen and available for reuse. However, AWS warns that users shouldn't assume Lambda always reuses the container because, in some instances, it will choose to create a new one.

Microsoft Azure Functions and AWS Lambda pricing

The beauty of cloud functions, whether Microsoft Azure Functions, AWS Lambda or a third-party alternative, is their efficiency and scalability. In Azure, users pay only for code execution time and the total number of executions. Time is measured as gigabytes per second (GBps), calculated by multiplying the function's memory size by the total execution time in seconds.

How to calculate the cost of Azure Functions

A 1,536 megabyte Function App in the West US region takes one second to execute and executes 2,000,000 times in one month, resulting in a cost of $19.20 for execution time.

○ Where the function memory size is converted to gigabytes and the charged execution time is the total used, minus 400,000 available free and the regional cost is 0.8 millicents.

Requests = (2,000,000-1,000,000) / 1,000,000 * $0.20 = $0.20

○ Where the charged execution count is normalized to millions with one million free grant deducted multiplied by a price of $0.20 per million.

The executions cost of $0.20 is added to the $19.20 for execution time to arrive at a total cost for the function of $19.40/month.

Pricing will vary, as the function in this example has a large memory allocation and a low number of executions.

AWS Lambda pricing is also based on the total execution time with a rate based on memory allocation, less a tier of one million requests and 400,000 GBps of compute time per month. Using the parameters from our Azure example, a function using 1,536 MB of memory, taking one second to execute and running 2 million times a month would cost:

Functions have become a standard feature of the major infrastructure as a service providers, but they're a new and rapidly evolving category. Watch for developments as providers add features, language support and integration with development environments and continuous delivery tools. One area of change will likely be the configuration dashboards, which can be confusing, given the number of event sources and function mappings.

Join the conversation

4 comments

Register

I agree to TechTarget’s Terms of Use, Privacy Policy, and the transfer of my information to the United States for processing to provide me with relevant information as described in our Privacy Policy.

Please check the box if you want to proceed.

I agree to my information being processed by TechTarget and its Partners to contact me via phone, email, or other means regarding information relevant to my professional interests. I may unsubscribe at any time.

Your password has been sent to:

Please create a username to comment.

Serverless (or Event Driven) architecture apps could be a good fit where we want to experiment with orchestrating a number of native AWS or other cloud services to compose a more complex application, particularly in a test and learn mode. When proven, such use cases can be further industrialized (e.g. for resillience and performance). Serverless can be an efficient and innovative way to assemble applications. We should remember, however, that even if the Serverless code is only running and billed for when required, the main bill will be for the other services executed, be they IoT, machine learning or others.