In recent years Cloud Providers such as Amazon and Google have been pushing the concept of Serverless computing. This new term can be confusing as it alludes to computing without Servers. Serverless computing is the next evolution of Paas computing. It provides a runtime environment for developers to write code without any concern for the infrastructure it is running on. Serverless computing has become synonymous with the term Function as a Service (Faas).
Platform as a Service has become a popular model for businesses who want to develop Cloud ready applications. This has allowed companies to develop and deploy new Cloud ready applications without the concerns of maintaining, patching and upgrading the underlying Virtual Machines that they will run on.
The following figure describes the difference in levels of responsibility in a Cloud Service stack.
Developing with a Paas model allows development teams to concentrate on the core business requirements. It also provides an opportunity to lift and shift existing On Premises Application workloads to the Cloud. Paas developers can configure settings such as auto scale and runtime configuration settings. For example, in Azure Web Apps developers can set Auto scale rules to scale out instances if certain metrics are exceeded (CPU, Memory). With Azure functions the developer focuses on the logic of the function he is developing. He is also concerned with having the ability to deploy and run his function quickly on the platform. This is big contrast to Paas which involves deploying the whole application to an environment.
Serverless stacks move the deployment model away from application level down to the function level. This also has an effect on the billing model too. In Paas, you need to know the underlying Compute size as providers will bill you for the Compute hours you consume. However, when you move to the Faas model then the billing model is different. In Serverless computing it is how many times your Function has executed that matters.
With a Paas model the execution model is based on the Applications you develop. If you are building a basic Asp.net Web application, then the executable code is the Web application running in an Asp.net worker process. You may build an application that can process requests Asynchronously such as an Ecommerce API using Asynchronous messaging or a standard N-Tier application. In a Faas execution model you are building functions to process messages in response to an event. This is more prescriptive than a Paas application because Paas does not prescribe a specific execution model. With Paas It is up to the engineers to decide on the architecture of the application.
Because of the event driven nature of Faas, not every application is suited. The Faas model suits the following scenarios:
Functions can therefore be used for many use cases, but more specifically Functions can be written to serve the following type of processing:
Functions can also be chained together, which then leads to similarity with Workflow orchestration. The implementation of the above features will vary according to the Cloud provider. As this is an evolving space, new features will be added by providers.
In this section we concentrate on Azure Functions and what capabilities they offer as a Serverless Computing platform.
Azure Functions were first introduced on the Azure Cloud platform in March 2016. Azure functions are Microsoft’s offering of Serverless computing platform. Amazon introduced its version of Serverless computing in 2014 with AWS Lambda service.
Before the introduction of Azure Functions, the nearest service comparable to Faas was WebJobs. Azure WebJobs are continuous, or scheduled jobs which run in an Azure Web App container. Currently Azure WebJobs offers developers the support to write their Azure Web Job Functions in the following languages:
But the obvious difference between a Web job and Azure Functions is that the developer requires an App container to be created before he can deploy a Web Job. This involves many more steps to get a function running.
The following table summarises the key differences
In this section we go through a simple example of how easy it is to get started with Azure functions.
As you can see from the above screen shot there are options to create functions based on Http, Azure Blob, queue and many more triggers. Scroll down to see more options.
Azure functions are cheap. Because they offer a consumption model of billing. This means you will get billed for execution time and memory usage for each function invocation. Also using them for simple workflow scenarios makes sense. They are simple to code and remove a lot of the boilerplate code needed to connect to Azure storage for example. As far as you are concerned you receive a message from blob and do some processing on it. And remember they can also scale on demand.
Azure functions offer you a myriad of languages to work from. You can select C#, Javascript, Powershell and more. However, if you have a requirement to move the functions to other Cloud Provider than unfortunately this would mean a lift and shift of the logic. This is because the binding setup is tied to the Azure environment. One other aspect is testing. Unlike working in a Paas environment where you can use the automated tools that are part of your development lifecycle, the tooling for Visual Studio 2015 is not the best.
In this blog we explored the difference between Paas and Serverless computing. We also demonstrated how easy it is to get started with a basic Faas service such as Azure Functions. If you are thinking of building parts of your Microservices architecture using Serverless computing, then Azure functions is a good place to start. It offers multiple language support and scaling of your functions. You can build asynchronous functions to process messages of queue, storage and more. However, do take note just like any Software project, as it increases in complexity and size you will need to think about issues such as how to maintain all the functions you are creating.