What Is Serverless?

Serverless computing is a cloud service where the cloud provider dynamically allocates infrastructure to run your code. Your provider scales hardware dynamically based on your usage and deallocates hardware when your code isn’t running. Pricing is based on your usage.

Businesses worldwide are rapidly embracing cloud computing. That means our software and hardware environments are cha­nging. Companies no longer need on-premises hardware, or need significantly less of it. Infrastructure and software are deployed using scripts and continuous deployment. However, whether you have a physical server, an on-premise virtual machine (VM), or a VM in the cloud, you still need to maintain the server, install updates, and troubleshoot issues. No matter how or where you host your infrastructure, you’ll always need maintenance.

The cloud has four types of cloud services. Hosting infrastructure in the cloud is also called infrastructure as a service (IaaS). It’s easier to run applications on a predefined host and leave the infrastructure to your cloud provider, but options are more limited. They provide a middleware on top of your infrastructure that makes software run out of the box. Such platforms are named platform as a service (PaaS). Another step “up” is using software in the cloud, such as Office 365 or Dynamics 365. This is called software as a service (SaaS), and is not offered in Azure directly. The fourth and last cloud service is serverless. In this chapter we’re going to briefly explore IaaS and PaaS, and then move on to serverless for the remainder of the book.

Infrastructure as a service (IaaS)

One reason to use VMs in the cloud is that it’s easy to grab your on-premises VM and move it to the cloud. You can run all of your on-premises workloads, except they now run in the cloud. VMs give you the freedom to install whatever you want, but at the cost of having to maintain your own server.

Let’s look at the VM creation blade in Azure. We can see that we have to plan for availability, and we need to select a region (which can affect the available machines), an image, and a size. We need to provide administrator credentials, and on the next blade we need to configure hard disks, networks (or virtual networks (VNETs), network interface cards (NICs), and IP addresses), security rules (for example, open port 3389 for remote desktop connections), and diagnostic tools.

Figure 1: Creating a VM

Luckily, the default settings provide a sensible standard for trying out VMs in Azure, so we don’t need to know all that stuff when we’re playing around. Still, it’s quite a lot to manage, and if you just want to host your .NET application in Azure, there are simpler and cheaper options.

Platform as a service (PaaS)

With platform as a service, the maintenance effort is significantly reduced. In Azure this would typically be an app service with a hosting plan. Instead of hosting software on a server or VM, you can host software in the cloud and not worry too much about server maintenance. You still rent some server space for your application to run on, but the server is maintained by your cloud provider. You must decide on a server plan, for example, one with at least 2 GB of memory and four cores (or compute units). After that, you have to monitor if your service plan is enough and plan for upscaling (increase memory and/or compute units) or out-scaling (adding additional instances) if it isn’t. Additionally, you can set some settings like Always On, HTTPS Only, certificates and authentication, and authorization using the intuitive Azure portal.

Figure 2: Creating an App Service

With an app service you can select either a Linux or Windows OS, but no distro or version. There are no networks or IP addresses to specify. The most important feature is the App Service plan, but that can be changed after creation. The only additional option we must specify is whether we want monitoring, which is as easy as choosing a name for our Application Insights instance that is going to monitor this App Service.

Once you have created an App Service, you can use Visual Studio to directly publish a web app to Azure, which will then be hosted on https://[your-app-service-name].azurewebsites.net. You can specify custom domain names. There’s now even a service in preview that lets you create managed SSL certificates for your own domain names, which are automatically renewed using Let’s Encrypt.

While PaaS is easier than IaaS, it does have its downsides. On a VM you can install anything you want, but on an App Service, not so much. For example, if you’re using SQL Server on-premises, you can most likely use the Azure SQL PaaS offering, although it doesn’t support functionality such as SSRS and the SQL Agent. When you want an Oracle database in Azure, you have no other option than to create a VM and install it there. When your application depends on software such as Microsoft Office being installed on the server that it runs on, you’re out of luck—and PaaS isn’t for you.

Serverless

Serverless is the next step in this evolution. You get even less control over your environment, but with some great benefits. First, serverless is a bit of a misnomer. Of course, your code still runs on servers, but you have minimum control over them. In fact, when your code isn’t running, the server is allocated to other Azure users who need to run their code. The code for your serverless applications is stored in an Azure storage account and started up when it is somehow triggered.

To run code in a serverless solution, you’re going to need an Azure function app to hold your functions. Functions can be triggered by various events, such as a timer, an HTTP call, a message on a storage account queue, or a message on a Service Bus queue or topic.

Figure 3: Creating an Azure Function App

The creation of an Azure function app seems a bit more complicated than that of a web app, but it’s just a name, a development stack (.NET Core, Node.js, Python, Java, or PowerShell Core), a storage account to store your code, an operating system, a plan type (which I’ll be discussing later), and whether or not you want to use Application Insights.

Another serverless solution is Azure Logic Apps, which allows you to click together a workflow using a designer in Azure. Logic apps are triggered by various events, like functions, but they have additional events, such as receiving an email in Outlook or a tweet on Twitter. A logic app can trigger a function, and vice versa (through HTTP).

Other serverless offerings in Azure include Service Bus, Event Grid, Azure SQL, and API Management. We’ll see them all in the remainder of this book.

Cheap scaling

Because you do not have a dedicated server at your disposal, the use cases for serverless are limited. For example, consider the startup time that’s needed if your function triggers create some latency. Furthermore, the default timeout for a function is five minutes, but can be increased to 10 minutes.

One of the biggest pros is that you also don’t need to maintain a server, and you don’t pay for a server that you’re not using. Since servers are allocated when you need them, you aren’t limited to a single server, either. When you have some heavy workload, for example, you need to process hundreds or even thousands of images at a couple of minutes per image, both functions and logic apps will scale accordingly. So, when Azure notices that your allocated server is at full capacity, but new triggers are still incoming, Azure will automatically scale out new servers to run your additional workloads. When a server has been idle for a few minutes, Azure can also automatically scale down server instances.

The pricing model for functions and logic apps is a bit difficult and hard to measure, but it’s a mix of number of executions and resource consumption measured in gigabyte seconds. However, the first million executions and the first 400,000 GB-s of resource consumption are free. That means you probably don’t pay anything at all for small and medium-sized businesses with small workloads. If, however, your function is working the whole day, every day, on multiple instances, the price goes up quickly, and you may be better off with an app service, or even VM. Of course, when Azure scales out some servers, your number of executions and GB-s are increased as well, and your bill will go up accordingly. You can find more information on Azure Functions pricing here.

In the next chapter, we’re going to dive into Azure Functions and serverless.

Note: Serverless isn’t limited to the Azure cloud. For example, the AWS equivalent of Azure Functions is AWS Lambda, and in the Google Cloud it’s called Google Cloud Functions. There is nothing stopping you from using functions in one cloud and calling functions in another. For example, say you want to do some processing in Go, which isn’t supported in Azure, but is supported in AWS. Multicloud environments are becoming increasingly popular, but this book will focus on Azure.

Summary

Serverless is becoming increasingly popular. It’s potentially cheap and has automatic scaling out of the box. With serverless, you don’t have to worry about infrastructure, operating systems, updates, or installed software. While this is a strength of serverless computing, it also limits the possible use cases. Luckily, serverless can complement your other computing infrastructure.