Making Serverless (do the) work for you
Tags: azure, serverless, dotnet
Published: 2019-09-12 22:37:20

# Introduction  

This article is part of [#ServerlessSeptember](https://dev.to/azure/serverless-september-content-collection-2fhb). 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/](https://docs.microsoft.com/azure/azure-functions/?WT.mc_id=servsept_devto-blog-cxa).

## Serverless

![Serverless: Aaaaand it's gone](https://thepracticaldev.s3.amazonaws.com/i/k368cct16hov4c6zj97u.jpg)

Serverless is _hot_. If you Google the term 'Serverless' you get [almost 9.5 million results](https://www.google.com/search?q=serverless). The [Serverless computing Wikipedia page](https://en.wikipedia.org/wiki/Serverless_computing) 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.

![Google Trends: Serverless, Worldwide](https://thepracticaldev.s3.amazonaws.com/i/symyq8f4xc5avrq9jvmh.png)

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._  
&mdash; [serverless.com](https://serverless.com/learn/overview/)  

## 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](https://azure.microsoft.com/en-us/services/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](https://serverlesslibrary.net/) 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](https://azure.microsoft.com/en-us/solutions/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!!!

![Serverless All the Things!](https://thepracticaldev.s3.amazonaws.com/i/dglq6rxfjiq7wu1v3fzc.jpeg)

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](https://flow.microsoft.com/en-us/) and [Azure Logic Apps](https://azure.microsoft.com/en-us/services/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.  

![Microsoft Flow and Logic Apps side by side](https://thepracticaldev.s3.amazonaws.com/i/xbj8vctdyswsaxc6lcc6.jpg)

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](https://ifttt.com/).  

### 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](https://docs.microsoft.com/en-us/azure/azure-functions/functions-run-local) enable you to run your Functions locally and debug them just like you would any other wpplication. And it has ASCII art, too!

![Azure Functions Core Tools, including cool ASCII art 🤓](https://thepracticaldev.s3.amazonaws.com/i/p2pafvpm1ga8ayhjvtj9.png)

The different development environments for Azure Functions are visible as soon as you create an Azure Function App in the [Azure portal](https://portal.azure.com) 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)](https://docs.microsoft.com/en-us/azure/azure-functions/functions-reference-csharp).

>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:

```C#
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](https://docs.microsoft.com/en-us/azure/azure-functions/functions-triggers-bindings#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](https://docs.microsoft.com/en-us/azure/active-directory/managed-identities-azure-resources/overview) to connect to the Key Vault. Better yet, have a look at [Key Vault references](https://docs.microsoft.com/en-us/azure/app-service/app-service-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.

![Azure Storage: Not Just Blobs!](https://thepracticaldev.s3.amazonaws.com/i/lpwkkelpgmmm3kn0wksr.png)

#### Static website hosting

Next to the normal* things Azure Storage facilitates, it also has a nice added feature: [Static Website Hosting](https://docs.microsoft.com/en-us/azure/storage/blobs/storage-blob-static-website).

>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](https://docs.microsoft.com/en-us/azure/storage/common/storage-scalability-targets), 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

![Azure Event Grid](https://thepracticaldev.s3.amazonaws.com/i/c5d277nwj43capuy1zok.png)

Event Grid supports both Event Grid events and [Cloud events](https://cloudevents.io/), 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](https://github.com/rickvdbosch/mswfy). More context might be found in my articles [Using Triggers & Bindings in Azure Functions V2](https://www.rickvandenbosch.net/blog/using-triggers-bindings-in-azure-functions-v2/) and [Dynamic output bindings in Azure Functions](e).

### _Disclaimer_

The numbers in this article have been updated on Thursday September 12<sup>th</sup> 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!