Introduction

This article is part of #ServerlessSeptember. You'll find other helpful articles, detailed tutorials, and videos in this all-things-Serverless content collection. New articles are published every day — that's right, every day — from community members and cloud advocates in the month of September.

Find out more about how Microsoft Azure enables your Serverless functions at https://docs.microsoft.com/azure/azure-functions/.

Serverless

Serverless is hot. If you Google the term 'Serverless' you get almost 9.5 million results. The Serverless computing Wikipedia page was created on July 10 2016 and currently has a total of 289 edits. That’s an average of one edit every 4 days. The three major cloud vendors (Amazon, Google and Microsoft) all have a Serverless landing page in place. And if you look at the Google Trends chart for worldwide searches for the term 'Serverless', you’ll see that it has been on a steady incline since early 2016.

Serverless doesn't mean there aren't any servers. It doesn't mean there are less servers. It just means you don't have to manage them, since they are abstracted away by the platform. From both a Dev and an Ops perspective, there are no servers. But we all know they're out there...

Just like wireless internet has wires somewhere, serverless architectures still have servers somewhere.

What ‘serverless’ really means is that, as a developer you don’t have to think about those servers. You just focus on code.

— serverless.com

Serverless in Azure

My personal experience is more geared towards Azure, so I have a bit more in-depth knowledge of how Serverless is available there. The most obvious Serverless service Microsoft Azure provides is Azure Functions. These are set out to “accelerate and simplify application development with serverless compute”. And they do just that.

Have a look at the Azure Serverless Community Library which, at the time of writing this, has 98 examples of just how simple it is to get things done with Azure Functions. And an overall count of 115 serverless examples.

But Serverless in Microsoft Azure doesn’t end with Azure Functions. The thing is.... it’s not entirely clear where it does end. Different pages on azure.com have different summaries of all serverless services.

If you look at the list on the Azure serverless page, they define these categories for their serverless services:

• Compute
• Workflows and integration
• DevOps and developer tools
• AI and machine learning
• Database
• Storage
• Monitoring
• Analytics

You could question if for instance storage or monitoring are Serverless or PaaS. Or maybe even SaaS…? But when you look at the Compute category you see something that I think is just wrong. Azure App Service is mentioned as a Serverless offering. While with App Service, you specify the tier in which to run the application. Determining number of cores, available memory and.... wait a minute...! I’m specifying a server to run this thing on!!!

Since Serverless is hot, we're naming everything serverless!

We've already seen there are a LOT of Serverless services or products available on Azure. I would like to dive in to a few of them...

Flow & Logic Apps

Microsoft Flow and Azure Logic Apps are quite similar. They're both configuration first integration services. Both of them use the same designer, too. As a matter of fact, Microsoft Flow is built on top of Logic Apps.

And where Microsoft Flow "empowers any office worker to perform simple integrations", Logic Apps "enable advanced or mission-critical integrations" and are a part of Azure.

The designers of both Flow and Logic Apps show a bit of that distinction. In the image below, the bright part on the left is Microsoft Flow, the dark part on the right is the Logic App. Both of them are triggered though a tweet with the text '#Serverless". Both of them do sentiment detection using cognitive services. But where the Flow only shows the basics, Logic Apps already shows more options for customization.

These simple pieces of code, of logic, are triggered by the connector or schedule you select and are really easy to create. I've heard people compare it to IFTTT.

Azure Functions

After using Azure Functions quite extensively I can say: they deliver on their promise. In the beginning. developing Functions was only for those who could find their way in pieces of documentation and a LOT of example code. The entire development lifecycle has been streamlined the past couple of years, including anything that has to do with (local) debugging. The Azure Functions Core Tools enable you to run your Functions locally and debug them just like you would any other wpplication. And it has ASCII art, too!

The different development environments for Azure Functions are visible as soon as you create an Azure Function App in the Azure portal and you click the plus-sign to add a function. You can choose Visual Studio, VS Code, Any Editor + Core tools or In-Portal.

The In-Portal experience enables you to do everything you need to do to get an Azure Function up and running right there in the Azure Portal. After you've selected In-Portal, the system will ask you what kind of template you would like to use. The next step is to write the code needed for your Function. And again, this can be done entirely in the Azure Portal using C# Script (.csx).

The .csx format allows you to write less "boilerplate" and focus on writing just a C# function. Instead of wrapping everything in a namespace and class, just define a Run method.

This experience is close to the experience you get when using Microsoft Flow and Azure Logic Apps, although in this situation you actually need some programming knowledge to get the function to do what you want it to do since you need to write the code yourself.

Triggers & Bindings

Where Serverless compute abstracts away the underlying infrastructure for you, using triggers & bindings abstracts away the external resources you're connecting to.

Consider this code:

public static async Task Run(
    [BlobTrigger("upload/{name}", Connection = "scs")]Stream addedBlob,
    [Blob("copied/{name}", FileAccess.Write, Connection = "scs")]Stream stream,
    string name, ILogger log)
 {
    await addedBlob.CopyToAsync(stream);
 }

There's only one (that's 1) actual line of code in this example, the rest is just configuring the triggers and bindings. And although it's just one line of code, there's a LOT that happens: This code is automatically triggerd when a new blob is added to a specific container, making the stream to the new blob available immediately. You also get the name if the added blob, and a new stream in a separate container pointing to a blob with the same name as the uploaded one. And of course, the contents of one blob are copied to the other.

Now imagine the boilerplate code you would have to write if you want to develop this without the power of the cloud. Or 5 years ago... 😲

Let's break down the code.

• The BlobTrigger line states: trigger this Function when there's a new Blob in the 'upload' container and pass its name and a Stream 'addedBlob' for it into the Function.
• The Blob binding states: create a blob in the 'copied' container with the same name and pass a Stream 'stream' for it into the Function.
• The string 'name' contains the name of the added blob that causes the Trigger, the ILogger log is a logging mechanism the platform passes in.
• The call to CopyToAsync is the one actual line of code.

There is so much going on here, with so little code. The platform manages a TON of stuff for you, enabling you to focus on what matters. And there's even more where this came from, enabling developers to finally focus on adding business value to code, instead of writing boilerplate code to, for instance, connect to a resource. For a full and up to date list of supported bindings see..... Supported bindings 🤭

Sidenote

By the way, talking about the platform managing stuff for you... If you're using Key Vault to store application secrets, have a look at using a Managed Identities for Azure Resources to connect to the Key Vault. Better yet, have a look at Key Vault references. It enables you to work with secrets from Azure Key Vault in your App Service or Azure Functions application without requiring any code changes.

Azure Storage

Azure Storage is a Microsoft-managed service providing cloud storage that is highly available, secure, durable, scalable, and redundant. Azure Storage includes Azure Blobs (objects), Azure Data Lake Storage Gen2, Azure Files, Azure Queues, and Azure Tables.

So Azure Storage is more than just blobs. Azure storage enables you to ingest data from anywhere, even at the edge. There are several cost-effective options to retain data. You can have security features in place to safeguard data and control access and of course wrangle data with a broad library of supported tools.

Static website hosting

Next to the normal* things Azure Storage facilitates, it also has a nice added feature: Static Website Hosting.

You can serve static content (HTML, CSS, JavaScript, and image files) directly from a storage container named $web. Hosting your content in Azure Storage enables you to use serverless architectures that include Azure Functions and other Platform as a service (PaaS) services.

Content in the $web container are served through anonymous requests, only available through object read operations and case-sensitive.

Static website hosting is available at no extra charge. Of course you are billed for the blob storage that your site utilizes and the operations costs.

Sidenote

* We're already calling everything Azure Storage is providing 'normal'. But it isn't. Read Azure Storage scalability and performance targets for storage accounts, then determine if it's normal... 😲

Azure Event Grid

The next (logical?) step in Serverless architectures are event-based architectures. Event Grid made events a first-class citizen in Azure. Where triggers might get lazy (since they rely on a form of polling), events are instant. In comes Event Grid: it has built-in support for events coming from Azure services, like storage blobs and resource groups. Event Grid also has support for your own events, using custom topics.

The flow inside Event Grid is as follows:

1. A publisher decides to send events to Event Grid
2. An event takes place in an event source
3. The source sends the event to a topic
4. A subscription to a topic means you're interested in a specific type of event

Event Grid supports both Event Grid events and Cloud events, a specification for describing event data in a common way.

Azure Event Grid is one of the first public cloud services with available support for CloudEvents, so you can now publish and consume events using both CloudEvents and Azure native events schemas. This means today you can pump Azure Storage events in CloudEvents format into the serverless platform of your choice for handling, or you can ingest events from other cloud platform’s services publishing CloudEvents into the Azure platform and process them on your beloved Azure Functions or Logic Apps already connected to Event Grid. All natively done, with no custom code involved.

Conclusion

While writing this I've already thought of a lot of other stuff I also found worth mentioning, since there is so much cool stuff going on in the (Azure) cloud. Especially around Serverless and developer productivity. The platform is managing more and more for us as developers enabling us to focus on actually adding value.

So the title "Making Serverless do the work for you" actually means two things:

1. Serverless enables your applications to rapidly scale with little to no up-front costs
2. Serverless enables your developers to leverage the power of the platform, making them (even) more productive

I'm not sure about you, but I'm making Serverless do the work for me... 😉

Resources

You can find some examples in the GitHub repo Making Serverless Work For You. More context might be found in my articles Using Triggers & Bindings in Azure Functions V2 and Dynamic output bindings in Azure Functions.

Disclaimer

The numbers in this article have been updated on Thursday September 12^th 2019. They give a general feel of the order of magnitude. I'm not aiming at keeping them updated, so if you're reading this at a (much) later point in time, make sure to check the numbers before basing important (business) decisions on them. 🤓

One other thing: do Serverless if it fits. Don't do it because it's hip. Don't use it because everyone else is. Use it because it's the best choice for the situation. And if it isn't, don't!