Serverless computing is a cloud computing model where backend services are provided on a pay-as-you-use basis.

In this model, developers get to create and run development code without having to manage or provision servers. As such, they get to focus solely on writing the business logic (or front-end development) code instead.

Microsoft Azure provides a wide range of options for designing this kind of architecture. However, the most frequently used methods are Azure Logic Apps and Azure Functions which will be the main focus of this article.

What are Azure Functions?

Azure Functions is the serverless computing model on Microsoft Azure platform for creating serverless applications. It enables developers to host their business logics without the need for infrastructure.

The code for Azure functions can be written in a wide range of programming languages including C#, JavaScript, and Python, amongst others. Like other cloud services, it operates on a pay-per-use basis, where you only pay for the resources you consume.

By the end of this tutorial, you will be able to:

• Create an Azure function app in the Azure portal.
• Exercise a function using triggers.
• Monitor and test your Azure function from the Azure portal.

Prerequisites

You will need a valid and active Microsoft Azure account to follow along with this tutorial. You can use either:

• Free Azure Trial: With this option, you will start with $200 Azure credit and will have 30 days to use it, in addition to free services.
• Azure for Students: This offer is available for students only. With this option, you will start with $100 Azure credit with no credit card required and access to popular services for free whilst you have your credit.

Step 1 – Create your Azure Function App

To establish a serverless computing resource for your business logic using Azure Functions, it is essential to create an Azure Function application. Having created a valid and active Microsoft Azure account, navigate to the portal.

• Select Create a resource
• Select the Create button underneath the Function App pane.
• On clicking the button, a page where you enter the details of your project appears as shown below.

Enter the configuration details for this tutorial under the Basics tab before clicking the Review + create button

• Enter the Subscription available on your account. Note that your subscription might not be Visual Studio Enterprise Subscription as shown in mine.
• For the Resource group, if you have created one before, you could use it. However, if you have not created one or are not familiar with Azure resource group, create a new one by using the Create new button.

At its core, a resource group is used to group similar Azure services on your Azure subscription together to make managing them easier.

• For the Function App name option, enter a globally unique app name. It is important to note that this name is will become part of the base URL for your service.
• For the Publish option, select Code.
• Choose Node.js for the Runtime Slack option since this tutorial's function examples were implemented using that language.
• Leave the Version option as default.
• Select the region that is geographically nearest to you when filling out the Region choice. A region is a collection of physical server data centers. Given that my base of operations is in Lagos, Nigeria, I chose South Africa North.
• For the Operating System, select one that conforms with your selection of runtime.
• For the Plan option, select Consumption (Serverless). The plan you choose will determine how your app scales and what features are enabled.
• At this point, you can then click the Review + create button.

The validation and deployment process usually takes up to three minutes. When the validation and deployment processes are both completed for the Azure Function set up, you can then verify that your Azure function app is running.

Step 2 – Verify that your Azure Function App is Running

Once the deployment process is done, select Go to resource. Your function's App pane will now appear. To open it in a browser, select the URL link in the Essentials section.

With the message above, you will see a standard Azure functions web app page appear: Your Function 4.0 app is up and running.

Step 3 – Run your Code On-Demand with Azure Functions

With the function app created, the next step is to build and configure the function. To do this, you have to understand what Triggers and Bindings are.

Triggers cause a function to run. A trigger defines how a function is invoked and a function must have exactly one trigger. Triggers have associated data, which is often provided as the payload of the function. Binding to a function is a way of declaratively connecting another resource to the function; bindings may be connected as input bindings, output bindings, or both. Data from bindings is provided to the function as parameters. – Microsoft Learn Documentation

In general, Azure Functions run in response to an event. This event is known as a Trigger and Bindings are used to connect resources to a function. The typical triggers on Azure range from a blob storage that runs a function when a blob is created or updated to a timer that runs a function on a schedule.

To run your code on Azure Functions, you need to first create your function to run your code within the function app using the template.

To do this, click the Function tag on the menu bar on the left of your functions app's home page.

• Click the + Create button to create the function.
• Select the Azure Queue Storage trigger template. This trigger runs the functions app when it detects that a message has been added to an Azure storage queue.
• Leave everything else as its default value.
• Click the Create button to create the function.

Given that the function was created with a template, several other files will be created automatically. These files comprises of a source code and a configuration file.

• Click on the Code + Test button on the left pane and open the function.json file by selecting it from the dropdown.
• Replace the block of code it shows with the one below.

{
  "bindings": [
    {
      "name": "order",
      "type": "queueTrigger",
      "direction": "in",
      "queueName": "myqueue-items",
      "connection": "MY_STORAGE_ACCT_APP_SETTING"
    },
    {
      "name": "$return",
      "type": "table",
      "direction": "out",
      "tableName": "outTable",
      "connection": "MY_TABLE_STORAGE_ACCT_APP_SETTING"
    }
  ]
}

This block of code sets the trigger for the function as when a message is added to the queue named myqueue-items. Furthermore, it sends the return value to the outTable.

• Save and Test/Run the function whilst leaving the testing details as their default values and run the function app.
• You will see the output shown below.

The fact that the outcome automatically displays on the Output tab suggests that the function app functions well. Because there isn't any business logic applied to the function, the graphic above is blank.

Conclusion

In this tutorial, you have seen that serverless computing is a great option for hosting business logic code in the cloud. You have seen that with serverless offers such as Azure Functions, you can write your business logic in the language of your choice.

Also, it is important to note that not only does the use of serverless computing solutions avoid the over-allocation of infrastructure (because they can be created and destroyed on demand), but they are also event driven. Event driven in the sense that they run only in response to an event (called a 'trigger'), such as a message being added to a queue, or receiving an HTTP request.

Finally, I share my writings on Twitter if you enjoyed this article and want to see more.

In this article, we are going to use Azure Functions and the wkhtmltopdf tool to generate a PDF file from an HTML file.

You might want to create a PDF file for a great many reasons, such as generating invoices for sales, medical reports for your patients, insurance forms for your clients, and so on. And there are a few ways to do this.

Firstly, you can use Adobe's fill and sign tool to fill out forms. But this mostly requires a human interaction and so it’s not scalable or convenient.

The second option is that you directly create a PDF file. Based on the platform you are working on you will have tools to do this. If it’s a very simple PDF you can take this approach.

This brings us to our final and most convenient option, wkhtmltopdf. This is a really great tool that lets you convert your HTML to PDF. Since it is free, open source, and can be compiled for almost all platforms, it is our best choice.

Prerequisites

• VS Code editor installed
• An account on Azure Portal
• Linux Basic (B1) App Service Plan. If you already have a Windows Basic (B1) App Service Plan you can use that.
• Azure Storage Account.

How to Use Azure Functions

Since converting HTML to a PDF is a time consuming task, we shouldn’t run it on our main web server. Otherwise it may start blocking other important requests. Azure Functions are the best way to delegate such tasks.

In order to create a function you will first need to install Azure Functions on your machine. Based on your OS install the Azure Functions Core Tools.

Once installed open your command line tool to fire the below command. html2pdf is the project’s name here, but you can replace it with any name.

func init html2pdf

When you execute the command it will ask for a worker runtime. Here select option 1, dotnet since it's a Microsoft’s product and provides great support for dotnet.

This will generate a folder name html2pdf in your current directory. Since Visual Studio Code allows to directly publish to Azure Functions, we will use it to code and deploy.

After you open your project in VS Code, create a file named Html2Pdf.cs. Azure Functions provides a wide variety of triggers to execute the function. For now we will start with the HTTP trigger, that is the function can be called directly via the HTTP protocol.

In our newly created file, paste the below content:

using System;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace Html2Pdf
{
    public class Html2Pdf
    {
        // The name of the function
        [FunctionName("Html2Pdf")]

        // The first arugment tells that the functions can be triggerd by a POST HTTP request. 
        // The second argument is mainly used for logging information, warnings or errors
        public void Run([HttpTrigger(AuthorizationLevel.Function, "POST")] Html2PdfRequest Request, ILogger Log)
        {
        }
    }
}

We have created the skeleton and now we will fill in the details. As you might have noticed the type of request variable is Html2PdfRequest. So let’s create a model Html2PdfRequest.cs class as below:

namespace Html2Pdf
{
    public class Html2PdfRequest
    {
        // The HTML content that needs to be converted.
        public string HtmlContent { get; set; }

        // The name of the PDF file to be generated
        public string PDFFileName { get; set; }
    }
}

How to Add DinkToPdf to Your Project

In order to invoke wkhtmltopdf from our managed code, we use a technology called P/Invoke.

In short P/Invoke allows us to access structs, callbacks, and functions in unmanaged libraries. There is a nice P/Invoke wrapper named DinkToPdf that allows us to abstract away the technicalities.

You can add DinkToPdf to your project via nuget. Simply run the command from your root folder.

dotnet add package DinkToPdf --version 1.0.8

Time to add some code at the top of our class Html2Pdf:

// Read more about converter on: https://github.com/rdvojmoc/DinkToPdf
// For our purposes we are going to use SynchronizedConverter
IPdfConverter pdfConverter = new SynchronizedConverter(new PdfTools());

// A function to convert html content to pdf based on the configuration passed as arguments
// Arguments:
// HtmlContent: the html content to be converted
// Width: the width of the pdf to be created. e.g. "8.5in", "21.59cm" etc.
// Height: the height of the pdf to be created. e.g. "11in", "27.94cm" etc.
// Margins: the margis around the content
// DPI: The dpi is very important when you want to print the pdf.
// Returns a byte array of the pdf which can be stored as a file
private byte[] BuildPdf(string HtmlContent, string Width, string Height, MarginSettings Margins, int? DPI = 180)
{
  // Call the Convert method of SynchronizedConverter "pdfConverter"
  return pdfConverter.Convert(new HtmlToPdfDocument()
            {
                // Set the html content
                Objects =
                {
                    new ObjectSettings
                    {
                        HtmlContent = HtmlContent
                    }
                },
                // Set the configurations
                GlobalSettings = new GlobalSettings
                {
                    // PaperKind.A4 can also be used instead PechkinPaperSize
                    PaperSize = new PechkinPaperSize(Width, Height),
                    DPI = DPI,
                    Margins = Margins
                }
            });
}

I have added inline comments so that the code is self-explanatory. If you have any questions you can ask me on Twitter. Let’s call the above created function from our Run method.

// PDFByteArray is a byte array of pdf generated from the HtmlContent 
var PDFByteArray = BuildPdf(Request.HtmlContent, "8.5in", "11in", new MarginSettings(0, 0, 0,0));

Once the byte array is generated, let’s store that as a blob in Azure Storage. Before you upload the blob, make sure you create a container. Once you do that, add the below code after PDFByteArray.

// The connection string of the Storage Account to which our PDF file will be uploaded
// Make sure to replace with your connection string.
var StorageConnectionString = "DefaultEndpointsProtocol=https;AccountName=<YOUR ACCOUNT NAME>;AccountKey=<YOUR ACCOUNT KEY>;EndpointSuffix=core.windows.net";

// Generate an instance of CloudStorageAccount by parsing the connection string
var StorageAccount = CloudStorageAccount.Parse(StorageConnectionString);

// Create an instance of CloudBlobClient to connect to our storage account
CloudBlobClient BlobClient = StorageAccount.CreateCloudBlobClient();

// Get the instance of CloudBlobContainer which points to a container name "pdf"
// Replace your own container name
CloudBlobContainer BlobContainer = BlobClient.GetContainerReference("pdf");

// Get the instance of the CloudBlockBlob to which the PDFByteArray will be uploaded
CloudBlockBlob Blob = BlobContainer.GetBlockBlobReference(Request.PDFFileName);

// Upload the pdf blob
await Blob.UploadFromByteArrayAsync(PDFByteArray, 0, PDFByteArray.Length);

You will see some errors and warnings after you add this code. To fix those, first add the missing import statements. Second, change the return type from void to async Task for the Run function. Here is what the final Html2Pdf.cs file will look like:

using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;
using DinkToPdf;
using IPdfConverter = DinkToPdf.Contracts.IConverter;
using Microsoft.WindowsAzure.Storage;
using Microsoft.WindowsAzure.Storage.Blob;
using System.Threading.Tasks;

namespace Html2Pdf
{
    public class Html2Pdf
    {
        // Read more about converter on: https://github.com/rdvojmoc/DinkToPdf
        // For our purposes we are going to use SynchronizedConverter
        IPdfConverter pdfConverter = new SynchronizedConverter(new PdfTools());

        // A function to convert html content to pdf based on the configuration passed as arguments
        // Arguments:
        // HtmlContent: the html content to be converted
        // Width: the width of the pdf to be created. e.g. "8.5in", "21.59cm" etc.
        // Height: the height of the pdf to be created. e.g. "11in", "27.94cm" etc.
        // Margins: the margis around the content
        // DPI: The dpi is very important when you want to print the pdf.
        // Returns a byte array of the pdf which can be stored as a file
        private byte[] BuildPdf(string HtmlContent, string Width, string Height, MarginSettings Margins, int? DPI = 180)
        {
            // Call the Convert method of SynchronizedConverter "pdfConverter"
            return pdfConverter.Convert(new HtmlToPdfDocument()
            {
                // Set the html content
                Objects =
                {
                    new ObjectSettings
                    {
                        HtmlContent = HtmlContent
                    }
                },
                // Set the configurations
                GlobalSettings = new GlobalSettings
                {
                    // PaperKind.A4 can also be used instead of width & height
                    PaperSize = new PechkinPaperSize(Width, Height),
                    DPI = DPI,
                    Margins = Margins
                }
            });
        }

        // The name of the function
        [FunctionName("Html2Pdf")]

        // The first arugment tells that the functions can be triggerd by a POST HTTP request. 
        // The second argument is mainly used for logging information, warnings or errors
        public async Task Run([HttpTrigger(AuthorizationLevel.Function, "POST")] Html2PdfRequest Request, ILogger Log)
        {
            // PDFByteArray is a byte array of pdf generated from the HtmlContent 
            var PDFByteArray = BuildPdf(Request.HtmlContent, "8.5in", "11in", new MarginSettings(0, 0, 0, 0));

            // The connection string of the Storage Account to which our PDF file will be uploaded
            var StorageConnectionString = "DefaultEndpointsProtocol=https;AccountName=<YOUR ACCOUNT NAME>;AccountKey=<YOUR ACCOUNT KEY>;EndpointSuffix=core.windows.net";

            // Generate an instance of CloudStorageAccount by parsing the connection string
            var StorageAccount = CloudStorageAccount.Parse(StorageConnectionString);

            // Create an instance of CloudBlobClient to connect to our storage account
            CloudBlobClient BlobClient = StorageAccount.CreateCloudBlobClient();

            // Get the instance of CloudBlobContainer which points to a container name "pdf"
            // Replace your own container name
            CloudBlobContainer BlobContainer = BlobClient.GetContainerReference("pdf");

            // Get the instance of the CloudBlockBlob to which the PDFByteArray will be uploaded
            CloudBlockBlob Blob = BlobContainer.GetBlockBlobReference(Request.PDFFileName);

            // Upload the pdf blob
            await Blob.UploadFromByteArrayAsync(PDFByteArray, 0, PDFByteArray.Length);
        }
    }
}

This concludes the coding part of this tutorial!

How to Add wkhtmltopdf to Your Project

We will still need to add the wkhtmltopdf library in our project. There are a few caveats when you're selecting a particular Azure App Plan. Based on the plan, we will have to get the wkhtmltopdf library.

For our purposes we have selected the Linux Basic (B1) App Service Plan since Windows Basic (B1) App Service Plan is five times more expensive.

At the time of writing this blog, the Azure App Service Plan was using Debian 10 with amd64 architecture. Luckily for us, DinkToPdf provides precompiled libraries for Linux, Windows, and MacOS.

Download the .so library for Linux and put it in your project’s root folder. I am working on MacOS so I downloaded libwkhtmltox.dylib as well.

If you are using Windows or if you have hosted the Azure Functions on the Windows App Service Plan you must download the libwkhtmltox.dll. Here is how our project structure will look now:

Project Structure

When we create a build we need to include the .so library. In order to do that, open your csproj file and add the below content to the ItemGroup.

<None Update="./libwkhtmltox.so">
    <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    <CopyToPublishDirectory>Always</CopyToPublishDirectory>
</None>

Here is the whole csproj file:

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <AzureFunctionsVersion>v3</AzureFunctionsVersion>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="DinkToPdf" Version="1.0.8" />
    <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="3.0.11" />
  </ItemGroup>
  <ItemGroup>
    <None Update="host.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
    </None>
    <None Update="local.settings.json">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Never</CopyToPublishDirectory>
    </None>
    <None Update="./libwkhtmltox.so">
      <CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
      <CopyToPublishDirectory>Always</CopyToPublishDirectory>
    </None>
  </ItemGroup>
</Project>

How to Create the Azure Functions App

Before we deploy to Azure Functions we will have to create it in Azure Portal. You can go to Azure Portal and start creating the Azure Functions resource. Follow the below screenshots for clarity.

Instance Details

In the below screenshot, make sure to select or create at least the Basic Plan here. Secondly, in the Operating System select Linux.

Plan Details

It’s good to have Application Insights since you will be able to see logs and monitor functions. Besides, it hardly costs anything. As shown in the screenshot below, select Yes if you want to enable it.

Application Insights

Select Next: Tags and again click Next and click Create to create your resource. It might take a few minutes to create the Azure Functions resource.

How to Deploy to Azure Functions

Once created, we will deploy our code directly to Azure Functions via VS Code. For that you will have to go to the extensions and install the Azure Functions extension. With its help we will be able to login and manage Azure Functions.

Azure Functions in Marketplace

Once installed you will see the Azure icon on the side bar. When you click it, it will open a panel with an option to Sign In to Azure.

Azure Functions Extension

Select Sign in to Azure which will open a browser where you can login with your account. Once logged in, you can go back to VS Code and see the list of Azure Functions in your side panel.

List of Azure Functions

For me there are four function apps. Since you might have created just one it will show one. Now it's time to deploy the app.

Press F1 to open a menu with a list of actions. Select Azure Functions: Deploy to Function App… which will open a list of Azure Functions to which you can deploy.

Select our newly created Azure Funtions App. This will ask for a confirmation pop-up, so go ahead and deploy it. It will take a few minutes to deploy your App.

How to Configure wkhtmltopdf

Once you have deployed to Azure Functions there is still one last thing to do. We will need to add libwkhtmltox.so to a proper location on our Azure Functions App.

Login to Azure portal and navigate to our Azure Functions App. On the side panel search for SSH and click the Go button.

Search SSH for Azure Functions

This will open a SSH console in new tab. Our site is located at /home/site/wwwroot. So navigate to that folder by typing in the below command:

cd /home/site/wwwroot/bin

When you execute the ls command to view the contents of the file you won’t see the libwkhtmltox.so file. It is actually located at /home/site/wwwroot.

That is not the correct position. We need to copy it into the bin folder. To do that, execute the below command:

cp ../libwkhtmltox.so libwkhtmltox.so

If you know a better way to include the file in the bin folder, please let me know.

That’s it! You have a fully functional Azure Functions App. Time to call it from our demo dotnet project.

How to Invoke the Azure Function

All said and done, we still need to test and call our function. Before we do that we need to get ahold of Code which is required to call the Function.

The Code is a secret that needs to be included to call the Function securely. To get the Code navigate to Azure Portal and open your Function App. In the side panel search for Functions.

Search Functions

You will see Html2Pdf in the list. Click on that function which will open the details view. In the side panel there will be an option for Function Keys. Select that option to view a hidden default Code already added for you.

Copy the code and keep it handy since we will need it in the code. In order to test the function I have created a sample console app for you. Replace the base URL and the code is as below:

using System;
using System.Net;
using System.Net.Http;
using System.Net.Http.Headers;
using System.Threading.Tasks;
using Newtonsoft.Json;

namespace Demo.ConsoleApp
{
    public class Program
    {
        public static async Task Main(string[] args)
        {
            string AzureFunctionsUrl = "https://<Your Base Url>/api/Html2Pdf?code=<Replace with your Code>";


            using (HttpClient client = new HttpClient())
            {
                var Request = new Html2PdfRequest
                {
                    HtmlContent = "<h1>Hello World</h1>",
                    PDFFileName = "hello-world.pdf"
                };
                string json = JsonConvert.SerializeObject(Request);
                var buffer = System.Text.Encoding.UTF8.GetBytes(json);
                var byteContent = new ByteArrayContent(buffer);

                byteContent.Headers.ContentType = new MediaTypeHeaderValue("application/json");


                using (HttpResponseMessage res = await client.PostAsync(AzureFunctionsUrl, byteContent))
                {
                    if (res.StatusCode != HttpStatusCode.NoContent)
                    {
                        throw new Exception("There was an error uploading the pdf");
                    }
                }
            }
        }
    }

    public class Html2PdfRequest
    {
        // The HTML content that needs to be converted.
        public string HtmlContent { get; set; }

        // The name of the PDF file to be generated
        public string PDFFileName { get; set; }
    }

}

Again the code should be pretty self-explanatory. If you have any feedback or questions just let me know. Once you run the above console app, it will create a hello-world.pdf file in your pdf container in Azure Storage.

Conclusion

That concludes our tutorial on how to convert HTML to PDF using Azure Functions. Though it might be a bit difficult to setup, it is one of the cheapest solutions for going serverless.

Read some of my other articles here:

• Learning Integration Tests in .NET with .TDD
• Provide a password-less way to login using .NET
• How to Authenticate & Authorise with .NET Identity
• How to speed up your site with Azure CDN

Introduction

In this article, we will learn how to implement Azure serverless with Blazor web assembly. And to do that, we will create an app that lists out some Frequently Asked Questions (FAQ) on Covid-19.

Here's what we will cover:

• We will create an Azure Cosmos DB which will act as our primary database to store questions and answers.
• We will use an Azure function app to fetch data from cosmos DB.
• We will deploy the function app to Azure to expose it globally via an API endpoint.
• And lastly, we will consume the API in a Blazor web assembly app.

The FAQs will be displayed in a card layout with the help of Bootstrap.

The Covid-19 FAQ app is deployed on Azure. See it in action at https://covid19-faq.azurewebsites.net/

What is a serverless architecture?

In traditional applications such as a 3-tier app, a client requests resources from the server, and the server processes the request and responds with the appropriate data.

However, there are some issues with this architecture. We need a server running continuously. Even if there are no requests, the server is present 24X7, ready to process the request. Maintaining server availability is cost-intensive.

Another problem is scaling. If the traffic is huge, we need to scale out all the servers which can be a cumbersome process.

An effective solution to this problem is serverless web architecture. The client makes a request to a file storage account instead of a server. The storage account returns the index.html page along with some code that needs to be rendered on the browser.

Since there is no server to render the page, we are relying on the browser to render the page. All the logic to draw the element or update the element will run in the browser. We do not have any server on backend – we just have a storage account with a static asset.

This is a cost-effective solution as we do not have any server, just some static files in a storage account. It is also very easy to scale out for heavy load websites.

What is an Azure function?

Making the browser run all the logic to render the page seems exciting, but it has some limitations.

We do not want the browser to make database calls. We need some part of our code to run on the server-side such as connecting to a database.

This is where Azure functions come in handy. In a serverless architecture, if we want some code to run the server-side, then we use an Azure function.

Azure functions are an event-driven serverless compute platform. You need to pay only when execution happens. They are also easy to scale. Hence, we get both the scaling and the cost benefits with Azure functions.

To learn more you can refer to the Azure function official docs.

Why should you use Azure serverless?

An Azure serverless solution can add value to your product by minimizing the time and resources you spend on infrastructure-related requirements.

You can increase developer productivity, optimize resources and accelerate the time to market with the help of a fully managed, end-to-end Azure serverless solution.

To learn more, see the Azure serverless official doc.

What is Blazor?

Blazor is a .NET web framework for creating client-side applications using C#/Razor and HTML.

Blazor runs in the browser with the help of WebAssembly. It can simplify the process of creating a single page application (SPA). It also provides a full-stack web development experience using .NET.

Using .NET for developing Client-side application has multiple advantages:

• .NET offers a range of API and tools across all platforms that are stable and easy to use.
• The modern languages such as C# and F# offer a lot of features that make programming easier and interesting for developers.
• The availability of one of the best IDE in the form of Visual Studio provides a great .NET development experience across multiple platforms such as Windows, Linux, and macOS.
• .NET provides features such as speed, performance, security, scalability, and reliability in web development that makes full-stack development easier.

Why should you use Blazor?

Blazor supports a wide array of features to make web development easier for us. Some of the prominent features of Blazor are:

• Component-based architecture: Blazor provides us with a component-based architecture to create rich and composable UI.
• Dependency injection: This allows us to use services by injecting them into components.
• Layouts: We can share common UI elements (for example, menus) across pages using the layouts feature.
• Routing: We can redirect the client request from one component to another with the help of routing.
• JavaScript interop: This allows us to invoke a C# method from JavaScript, and we can call a JavaScript function or API from C# code.
• Globalization and localization: The application can be made accessible to users in multiple cultures and languages
• Live reloading: Live reloading of the app in the browser during development.
• Deployment: We can deploy the Blazor application on IIS and Azure Cloud.

To learn more about Blazor, please refer to the official Blazor docs.

Prerequisites

To get started with the application, we need to fulfill these prerequisites:

• An Azure subscription account. You can create a free Azure account at https://azure.microsoft.com/en-in/free/
• Install the latest version of Visual Studio 2019 from https://visualstudio.microsoft.com/downloads/

While installing the VS 2019, please make sure you select the Azure development and ASP.NET and web development workload.

Source Code

You can get the source code from GitHub here.

Create Azure Cosmos DB account

Log in to the Azure portal and search for the “Azure Cosmos DB” in the search bar and click on the result. On the next screen, click on the Add button.

This will open a “Create Azure Cosmos DB Account” page. You need to fill in the required information to create your database. Refer to the image shown below:

You can fill in the details like this:

• Subscription: Select your Azure subscription name from the drop-down.
• Resource Group: Select an existing Resource Group or create a new one.
• Account Name: Enter a unique name for your Azure Cosmos DB account. The name can contain only lowercase letters, numbers, and the ‘-‘ character, and must be between 3 and 44 characters.
• API: Select Core (SQL)
• Location: Select a location to host your Azure Cosmos DB account.

Keep the other fields to its default value and click on the “Review+ Create” button. In the next screen, review all your configurations and click on the “Create” button. After a few minutes, the Azure Cosmos DB account will be created. Click on “Go to resource” to navigate to the Azure Cosmos DB account page.

Set up the Database

On the Azure Cosmos DB account page, click on “Data Explorer” on the left navigation, and then select “New Container”. Refer to the image shown below:

An “Add Container” pane will open. You need to fill in the details to create a new container for your Azure Cosmos DB. Refer to the image shown below:

You can fill in the details as indicated below.

• Database ID: You can give any name to your database. Here I am using FAQDB.
• Throughput: Keep it at the default value of 400
• Container ID: Enter the name for your container. Here I am using FAQContainer.
• Partition key: The Partition key is used to automatically partition data among multiple servers for scalability. Put the value as “/id”.

Click on the “OK” button to create the database.

Add Sample data to the Cosmos DB

In the Data Explorer, expand the FAQDB database then expand the FAQContainer. Select Items, and then click on New Item on the top. An editor will open on the right side of the page. Refer to the image shown below:

Put the following JSON data in the editor and click on the Save button at the top.

{
    "id": "1",
    "question": "What is corona virus?",
    "answer": "Corona viruses are a large family of viruses which may cause illness in animals or humans. The most recently discovered coronavirus causes coronavirus disease COVID-19."
}

We have added a set of questions and answer along with a unique id.

Follow the process described above to insert five more sets of data.

{
    "id": "2",
    "question": "What is COVID-19?",
    "answer": "COVID-19 is the infectious disease caused by the most recently discovered corona virus. This new virus and disease were unknown before the outbreak began in Wuhan, China, in December 2019."
}
{
    "id": "3",
    "question": "What are the symptoms of COVID-19?",
    "answer": "The most common symptoms of COVID-19 are fever, tiredness, and dry cough. Some patients may have aches and pains, nasal congestion, runny nose, sore throat or diarrhea. These symptoms are usually mild and begin gradually. Some people become infected but don’t develop any symptoms and don't feel unwell."
}
{
    "id": "4",
    "question": "How does COVID-19 spread?",
    "answer": "People can catch COVID-19 from others who have the virus. The disease can spread from person to person through small droplets from the nose or mouth which are spread when a person with COVID-19 coughs or exhales. These droplets land on objects and surfaces around the person. Other people then catch COVID-19 by touching these objects or surfaces, then touching their eyes, nose or mouth."
}
{
    "id": "5",
    "question": "What can I do to protect myself and prevent the spread of disease?",
    "answer": "You can reduce your chances of being infected or spreading COVID-19 by taking some simple precaution. Regularly and thoroughly clean your hands with an alcoholbased hand rub or wash them with soap and water. Maintain at least 1 metre (3 feet) distance between yourself and anyone who is coughing or sneezing. Make sure you, and the people around you, follow good respiratory hygiene. This means covering your mouth and nose with your bent elbow or tissue when you cough or sneeze. Stay home if you feel unwell. If you have a fever, cough and difficulty breathing, seek medical attention and call in advance."
}
{
    "id": "6",
    "question": "Are antibiotics effective in preventing or treating the COVID-19?",
    "answer": "No. Antibiotics do not work against viruses, they only work on bacterial infections. COVID-19 is caused by a virus, so antibiotics do not work."
}

Get the connection string

Click on “keys” on the left navigation, navigate to the “Read-write Keys” tab. The value under PRIMARY CONNECTION STRING is our required connection string. Refer to the image shown below:

Make a note of the PRIMARY CONNECTION STRING value. We will use it in the latter part of this article, when we will access the Azure Cosmos DB from an Azure function.

Create an Azure function app

Open Visual Studio 2019, click on “Create a new project”. Search “Functions” in the search box. Select the Azure Functions template and click on Next. Refer to the image shown below:

In “Configure your new project” window, enter a Project name as FAQFunctionApp. Click on the Create button. Refer to the image below:

A new “Create a new Azure Function Application settings” window will open. Select “Azure Functions v3 (.NET Core)”from the dropdown at the top. Select the function template as “HTTP trigger”. Set the authorization level to “Anonymous” from the drop-down on the right. Click on the Create button to create the function project and HTTP trigger function.

Refer to the image shown below:

Install package for Azure Cosmos DB

To enable the Azure function App to bind to the Azure Cosmos DB, we need to install the Microsoft.Azure.WebJobs.Extensions.CosmosDB package. Navigate to Tools >> NuGet Package Manager >> Package Manager Console and run the following command:

Install-Package Microsoft.Azure.WebJobs.Extensions.CosmosDB

Refer to the image shown below.

You can learn more about this package at the NuGet gallery.

Configure the Azure Function App

The Azure function project contains a default file called Function1.cs. You can safely delete this file as we won’t be using this for our project.

Right-click on the FAQFunctionApp project and select Add >> New Folder. Name the folder as Models. Again, right-click on the Models folder and select Add >> Class to add a new class file. Put the name of your class as FAQ.cs and click Add.

Open [FAQ.cs](https://github.com/AnkitSharma-007/azure-serverless-with-blazor/blob/master/FAQFunctionApp/FAQFunctionApp/Models/FAQ.cs) and put the following code inside it.

namespace FAQFunctionApp.Models
{
    class FAQ
    {
        public string Id { get; set; }
        public string Question { get; set; }
        public string Answer { get; set; }
    }
}

The class has the same structure as the JSON data we have inserted in the cosmos DB.

Right-click on the FAQFunctionApp project and select Add >> Class. Name your class as [CovidFAQ.cs](https://github.com/AnkitSharma-007/azure-serverless-with-blazor/blob/master/FAQFunctionApp/FAQFunctionApp/CovidFAQ.cs). Put the following code inside it.

using Microsoft.AspNetCore.Mvc;
using System.Collections.Generic;
using Microsoft.AspNetCore.Http;
using Microsoft.Extensions.Logging;
using Microsoft.Azure.WebJobs;
using FAQFunctionApp.Models;
using Microsoft.Azure.WebJobs.Extensions.Http;
using System.Threading.Tasks;

namespace FAQFunctionApp
{
    class CovidFAQ
    {
        [FunctionName("covidFAQ")]
        public static async Task<IActionResult> Run(
        [HttpTrigger(AuthorizationLevel.Anonymous, "get", Route = null)] HttpRequest req,
        [CosmosDB(
            databaseName:"FAQDB",
            collectionName:"FAQContainer",
            ConnectionStringSetting = "DBConnectionString"
            )] IEnumerable<FAQ> questionSet, 
        ILogger log)
        {
            log.LogInformation("Data fetched from FAQContainer");
            return new OkObjectResult(questionSet);
        }
    }
}

We have created a class CovidFAQ and added an Azure function to it. The attribute FunctionName is used to specify the name of the function. We have used the HttpTrigger attribute which allows the function to be triggered via an HTTP call. The attribute CosmosDB is used to connect to the Azure Cosmos DB. We have defined three parameters for this attribute as described below:

• databaseName: the name for the cosmos DB
• collectionName: the collecting inside the cosmos DB we want to access
• ConnectionStringSetting: the connection string to connect to Cosmos DB. We will configure it in the next section.

We have decorated the parameter questionSet, which is of type IEnumerable<FAQ> with the CosmosDB attribute. When the app is executed, the parameter questionSet will be populated with the data from Cosmos DB. The function will return the data using a new instance of OkObjectResult.

Add the connection string to the Azure Function

Remember the Azure cosmos DB connection string you noted earlier? Now we will configure it for our app. Open the local.settings.json file and add your connection string as shown below:

{
  "IsEncrypted": false,
  "Values": {
    "AzureWebJobsStorage": "UseDevelopmentStorage=true",
    "FUNCTIONS_WORKER_RUNTIME": "dotnet",
    "DBConnectionString": "your connectionn string"
  }
}

The local.settings.json will not be published to Azure when we publish the Azure Function app. Therefore, we need to configure the connections string separately while publishing the app to Azure. We will see this in action in the latter part of this article.

Test the Azure Function locally

Press F5 to execute the function. Copy the URL of your function from the Azure Functions runtime output. Refer to the image shown below:

Open the browser and paste the URL in the browser’s address bar. You can see the output as shown below:

Here you can see the data we have inserted into our Azure Cosmos DB.

Publish the Function app to Azure

We have successfully created the Function app, but it is still running in the localhost. Let’s publish the app to make it available globally.

Right-click on the FAQFunctionApp project and select Publish. Select the Publish target as Azure.

Select the specific target as “Azure Function App (windows)”.

In the next window, click on the “Create a new Azure Function…” button. A new Function App window will open. Refer to the image as shown below:

You can fill in the details as indicated below:

• Name: A globally unique name for your function app.
• Subscription: Select your Azure subscription name from the drop-down.
• Resource Group: Select an existing Resource Group or create a new one.
• Plan Type: Select Consumption. It will make sure that you pay only for executions of your functions app.
• Location: Select a location for your function.
• Azure Storage: Keep the default value.

Click on the “Create” button to create the Function App and return to the previous window. Make sure the option “Run from package file” is checked. Click on the Finish button.

Now you are at the Publish page. Click on the “Manage Azure App Service Settings” button.

You will see a “Application Settings” window as shown below:

At this point, we will configure the Remote value for the “DBConnectionString” key. This value is used when the app is deployed on Azure. Since the key for Local and Remote environment is the same in our case, click on the “Insert value from Local” button to copy the value from the Local field to the Remote field. Click on the OK button.

You are navigated back to the Publish page. We are done with all the configurations. Click on the Publish button to publish your Azure function app. After the app is published, get the site URL value, append /api/covidFAQ to it and open it in the browser. You can see the output as shown below.

This is the same dataset that we got while running the app locally. This proves that our serverless Azure function is deployed and able to access the Azure Cosmos DB successfully.

Enable CORS for the Azure app service

We will use the Function app in a Blazor UI project. To allow the Blazor app to access the Azure Function, we need to enable CORS for the Azure app service.

Open the Azure portal. Navigate to “All resources”. Here, you can see the App service which we have created while Publishing the app the in previous section. Click on the resource to navigate to the resource page. Click on CORS on the left navigation. A CORS details pane will open.

Now we have two options here:

1. Enter the specific origin URL to allow them to make cross-origin calls.
2. Remove all origin URL from the list, and use “*” wildcard to allow all the URL to make cross-origin calls.

We will use the second option for our app. Remove all the previously listed URL and enter a single entry as “*” wildcard. Click on the Save button at the top. Refer to the image shown below:

Create the Blazor Web assembly project

Open Visual Studio 2019, click on “Create a new project”. Select “Blazor App” and click on the “Next” button. Refer to the image shown below:

On the “Configure your new project” window, put the project name as FAQUIApp and click on the “Create” button as shown in the image below:

On the “Create a new Blazor app” window, select the “Blazor WebAssmebly App” template. Click on the Create button to create the project. Refer to the image shown below:

To create a new razor component, right-click on the Pages folder, select Add >>Razor Component.An “Add New Item” dialog box will open, put the name of your component as CovidFAQ.razor and click on the Add button. Refer to the image shown below:

Open [CovidFAQ.razor](https://github.com/AnkitSharma-007/azure-serverless-with-blazor/blob/master/FAQUIApp/FAQUIApp/Pages/CovidFAQ.razor) and put the following code into it.

@page "/covidfaq"
@inject HttpClient Http

<div class="d-flex justify-content-center">
    <img src="../Images/COVID_banner.jpg" alt="Image" style="width:80%; height:300px" />
</div>
<br />
<div class="d-flex justify-content-center">
    <h1>Frequently asked Questions on Covid-19</h1>
</div>
<hr />

@if (questionList == null)
{
    <p><em>Loading...</em></p>
}
else
{
    @foreach (var question in questionList)
    {
        <div class="card">
            <h3 class="card-header">
                @question.Question
            </h3>
            <div class="card-body">
                <p class="card-text">@question.Answer</p>
            </div>
        </div>
        <br />
    }
}

@code {

    private FAQ[] questionList;

    protected override async Task OnInitializedAsync()
    {
        questionList = await Http.GetFromJsonAsync<FAQ[]>("https://faqfunctionapp20200611160123.azurewebsites.net/api/covidFAQ");
    }

    public class FAQ
    {
        public string Id { get; set; }
        public string Question { get; set; }
        public string Answer { get; set; }
    }
}

In the @code section, we have created a class called FAQ. The structure of this class is the same as that of the FAQ class we created earlier in the Azure function app. Inside the OnInitializedAsync method, we are hitting the API endpoint of our function app. The data returned from the API will be stored in a variable called questionList which is an array of type FAQ.

In the HTML section of the page, we have set a banner image at the top of the page. The image is available in the /wwwroot/Images folder. We will use a foreach loop to iterate over the questionList array and create a bootstrap card to display the question and answer.

Adding Link to Navigation menu

The last step is to add the link of our CovidFAQ component in the navigation menu. Open [/Shared/NavMenu.razor](https://github.com/AnkitSharma-007/azure-serverless-with-blazor/blob/master/FAQUIApp/FAQUIApp/Shared/NavMenu.razor#L15-L19) file and add the following code into it.

<li class="nav-item px-3">
  <NavLink class="nav-link" href="covidfaq">
    <span class="oi oi-plus" aria-hidden="true"></span> Covid FAQ
  </NavLink>
</li>

Remove the navigation links for Counter and Fetch-data components as they are not required for this application.

Execution Demo

Press F5 to launch the app. Click on the Covid FAQ button on the nav menu on the left. You can see all the questions and answers in a beautiful card layout as shown below:

You can also check the live app at https://covid19-faq.azurewebsites.net/

Summary

In this article, we learned about serverless and its advantage over the traditional 3-tier web architecture. We also learned how the Azure function fits in serverless web architecture.

To demonstrate the practical implementation of these concepts, we have created a Covid-19 FAQ app using the Blazor web assembly and Azure serverless. The questions and answers are displayed in the card layout using Bootstrap.

We have used the Azure cosmos DB as the primary database to store the questions and answers for our FAQ app. An Azure function is used to fetch data from the cosmos DB. We deployed the function app on Azure to make it available globally via an API endpoint.

See Also

• Optical Character Reader Using Blazor And Computer Vision
• Multi-Language Translator Using Blazor And Azure Cognitive Services
• Facebook Authentication And Authorization In Server-Side Blazor App
• Continuous Deployment For Angular App Using Heroku And GitHub
• Google Authentication And Authorization In Server-Side Blazor App
• Blazor CRUD Using Google Cloud Firestore

If you like the article, share with you friends. You can also connect with me on Twitter and LinkedIn.

Originally published at https://ankitsharmablogs.com/

In this article, we'll discuss Azure Function Proxies. They provide “Reverse Proxy Functionality” for Azure Functions. Azure Function Proxies are quite similar to Azure API management.

This post is largely inspired by Matthew Henderson the of Microsoft Azure Function Team. In his blog post, Azure Functions Proxies public preview, Matthew explains the reason behind why Microsoft came up with the ideology for Azure Function Proxies.

What are Azure Function Proxies?

The basic idea behind Azure Function Proxies is that they allow us to define a single API surface for multiple function apps. Now any function app can define an endpoint that serves as a Reverse Proxy for another API. The endpoint can be a function app or it can be anything else.

Are you looking out for an off the shelf tool to manage and monitor your Azure Functions? Try this one out here for free.

Reason for implementing Azure Function Proxies

For some users, it's difficult to manage large solutions with a single function app. There are a bunch of organizations using Azure Function in their micro service architecture with deployment between individual components. In this case, each function app has its own hosting, so there are many different function apps to keep track of.

We could also have some function app combined with another API but they could be in various different regions. So we end up passing a lot of that complexity on down to our client or consuming system.

Azure Function Proxies come to the rescue by providing a unified URI (Uniform Resource Identifier) which the client can actually consume. In the meantime, we can abstract all of the different function apps or other APIs and it would also enable us to build our API at a faster rate.

Explanation

In the Solution Architecture Diagram above, we have an Azure Function Proxy followed by an Azure Function and Service Bus Queue on the back-end to store information. At the other end of the diagram, we have Data Publishers. For the purposes of this discussion, let's say that the Power Equipment generates the tag event and forwards it to Azure Functions through Proxy.

Initially, we create a function app by selecting the function option from the Azure portal. Here let's say we create an HTTP trigger for C# where the function of the HTTP trigger is to invoke a function with an HTTP request.

Now we create two functions: one is the PostTag which represents our post if we want to create a tag. The Code for the PostTag function is the following:

Then, we create another function called GetTag with the code specified as follows:

We use GetTag to pull the message from the queue, and the last tag value returns to the client.

We can select the link specified below to fetch the URL of both the functions. This link will provide us with a Security Token for authorization.

At this point, we move over to Function App Settings and enable the Azure Function Proxies that have the latest proxy runtime version of 0.2. Consequently, we select the “New Proxy” option from Function App Development which enables us to create two proxies. They are Proxy GetTag and Proxy PostTag. The available options in proxy are:

• Proxy URL
• Route Template
• Backend URL

The URL specified in Proxy URL and the Route Template are the same regarding both the GetTag and PostTag event. The Backend URL of the Proxy GetTag will be related to the GetTag event - but for the Proxy PostTag it will be related to the PostTag event.

Wrap-up

Azure Function Proxies are a great way to mock and test your Azure Functions endpoint even before the actual back-end development begins. Also, they can even be used in production when you need to route one URI to another.

I would like to conclude that Azure Function Proxies are one of the most engaging and go to market features that the Azure Functions team has provided.

This blog was originally published in Serverless360.

Stateful Workflows on top of Stateless Serverless Cloud Functions—this is the essence of the Azure Durable Functions library. That's a lot of fancy words in one sentence, and they might be hard for the majority of readers to understand.

Please join me on the journey where I'll try to explain how those buzzwords fit together. I will do this in 3 steps:

• Describe the context of modern cloud applications relying on serverless architecture;
• Identify the limitations of basic approaches to composing applications out of the simple building blocks;
• Explain the solutions that Durable Functions offer for those problems.

Microservices

Traditionally, server-side applications were built in a style which is now referred to as Monolith. If multiple people and teams were developing parts of the same application, they mostly contributed to the same code base. If the code base were structured well, it would have some distinct modules or components, and a single team would typically own each module:

Usually, the modules would be packaged together at build time and then deployed as a single unit, so a lot of communication between modules would stay inside the OS process.

Although the modules could stay loosely coupled over time, the coupling almost always occurred on the level of the data store because all teams would use a single centralized database.

This model works great for small- to medium-size applications, but it turns out that teams start getting in each other's way as the application grows since synchronization of contributions takes more and more effort.

As a complex but viable alternative, the industry came up with a revised service-oriented approach commonly called Microservices. The teams split the big application into "vertical slices" structured around the distinct business capabilities:

Each team then owns a whole vertical—from public communication contracts, or even UIs, down to the data storage. Explicitly shared databases are strongly discouraged. Services talk to each other via documented and versioned public contracts.

If the borders for the split were selected well—and that's the most tricky part—the contracts stay stable over time, and thin enough to avoid too much chattiness. This gives each team enough autonomy to innovate at their best pace and to make independent technical decisions.

One of the drawbacks of microservices is the change in deployment model. The services are now deployed to separate servers connected via a network:

Networks are fundamentally unreliable: they work just fine most of the time, but when they fail, they fail in all kinds of unpredictable and least desirable manners. There are books written on the topic of distributed systems architecture. TL;DR: it's hard.

A lot of the new adopters of microservices tend to ignore such complications. REST over HTTP(S) is the dominant style of connecting microservices. Like any other synchronous communication protocol, it makes the system brittle.

Consider what happens when one service becomes temporary unhealthy: maybe its database goes offline, or it's struggling to keep up with the request load, or a new version of the service is being deployed. All the requests to the problematic service start failing—or worse—become very slow. The dependent service waits for the response, and thus blocks all incoming requests of its own. The error propagates upstream very quickly causing cascading failures all over the place:

The application is down. Everybody screams and starts the blame war.

Event-Driven Applications

While cascading failures of HTTP communication can be mitigated with patterns like a circuit breaker and graceful degradation, a better solution is to switch to the asynchronous style of communication as the default. Some kind of persistent queueing service is used as an intermediary.

The style of application architecture which is based on sending events between services is known as Event-Driven. When a service does something useful, it publishes an event—a record about the fact which happened to its business domain. Another service listens to the published events and executes its own duty in response to those facts:

The service that produces events might not know about the consumers. New event subscribers can be introduced over time. This works better in theory than in practice, but the services tend to get coupled less.

More importantly, if one service is down, other services don't catch fire immediately. The upstream services keep publishing the events, which build up in the queue but can be stored safely for hours or days. The downstream services might not be doing anything useful for this particular flow, but it can stay healthy otherwise.

However, another potential issue comes hand-in-hand with loose coupling: low cohesion. As Martin Fowler notices in his essay What do you mean by "Event-Driven":

It's very easy to make nicely decoupled systems with event notification, without realizing that you're losing sight of the larger-scale flow.

Given many components that publish and subscribe to a large number of event types, it's easy to stop seeing the forest for the trees. Combinations of events usually constitute gradual workflows executed in time. A workflow is more than the sum of its parts, and understanding of the high-level flow is paramount to controlling the system behavior.

Hold this thought for a minute; we'll get back to it later. Now it's time to talk cloud.

Cloud

The birth of public cloud changed the way we architect applications. It made many things much more straightforward: provisioning of new resources in minutes instead of months, scaling elastically based on demand, and resiliency and disaster recovery at the global scale.

It made other things more complicated. Here is the picture of the global Azure network:

There are good reasons to deploy applications to more than one geographical location: among others, to reduce network latency by staying close to the customer, and to achieve resilience through geographical redundancy. Public Cloud is the ultimate distributed system. As you remember, distributed systems are hard.

There's more to that. Each cloud provider has dozens and dozens of managed services, which is the curse and the blessing. Specialized services are great to provide off-the-shelf solutions to common complex problems. On the flip side, each service has distinct properties regarding consistency, resiliency and fault tolerance.

In my opinion, at this point developers have to embrace the public cloud and apply the distributed system design on top of it. If you agree, there is an excellent way to approach it.

Serverless

The slightly provocative term serverless is used to describe cloud services that do not require provisioning of VMs, instances, workers, or any other fixed capacity to run custom applications on top of them. Resources are allocated dynamically and transparently, and the cost is based on their actual consumption, rather than on pre-purchased capacity.

Serverless is more about operational and economical properties of the system than about the technology per se. Servers do exist, but they are someone else's concern. You don't manage the uptime of serverless applications: the cloud provider does.

On top of that, you pay for what you use, similar to the consumption of other commodity resources like electricity. Instead of buying a generator to power up your house, you just purchase energy from the power company. You lose some control (e.g., no way to select the voltage), but this is fine in most cases. The great benefit is no need to buy and maintain the hardware.

Serverless compute does the same: it supplies standard services on a pay-per-use basis.

If we talk more specifically about Function-as-a-Service offerings like Azure Functions, they provide a standard model to run small pieces of code in the cloud. You zip up the code or binaries and send it to Azure; Microsoft takes care of all the hardware and software required to run it. The infrastructure automatically scales up or down based on demand, and you pay per request, CPU time and memory that the application consumed. No usage—no bill.

However, there's always a "but". FaaS services come with an opinionated development model that applications have to follow:

• Event-Driven: for each serverless function you have to define a specific trigger—the event type which causes it to run, be it an HTTP endpoint or a queue message;

• Short-Lived: functions can only run up to several minutes, and preferably for a few seconds or less;

• Stateless: as you don't control where and when function instances are provisioned or deprovisioned, there is no way to store data within the process between requests reliably; external storage has to be utilized.

Frankly speaking, the majority of existing applications don't really fit into this model. If you are lucky to work on a new application (or a new module of it), you are in better shape.

A lot of the serverless applications may be designed to look somewhat similar to this example from the Serverless360 blog:

There are 9 managed Azure services working together in this app. Most of them have a unique purpose, but the services are all glued together with Azure Functions. An image is uploaded to Blob Storage, an Azure Function calls Vision API to recognize the license plate and send the result to Event Grid, another Azure Function puts that event to Cosmos DB, and so on.

This style of cloud applications is sometimes referred to as Serviceful to emphasize the heavy usage of managed services "glued" together by serverless functions.

Creating a comparable application without any managed services would be a much harder task, even more so, if the application has to run at scale. Moreover, there's no way to keep the pay-as-you-go pricing model in the self-service world.

The application pictured above is still pretty straightforward. The processes in enterprise applications are often much more sophisticated.

Remember the quote from Martin Fowler about losing sight of the large-scale flow. That was true for microservices, but it's even more true for the "nanoservices" of cloud functions.

I want to dive deeper and give you several examples of related problems.

Challenges of Serverless Composition

For the rest of the article, I'll define an imaginary business application for booking trips to software conferences. In order to go to a conference, I need to buy tickets to the conference itself, purchase the flights, and book a room at a hotel.

In this scenario, it makes sense to create three Azure Functions, each one responsible for one step of the booking process. As we prefer message passing, each Function emits an event which the next function can listen for:

This approach works, however, problems do exist.

Flexible Sequencing

As we need to execute the whole booking process in sequence, the Azure Functions are wired one after another by configuring the output of one function to match with the event source of the downstream function.

In the picture above, the functions' sequence is hard-defined. If we were to swap the order of booking the flights and reserving the hotel, that would require a code change—at least of the input/output wiring definitions, but probably also the functions' parameter types.

In this case, are the functions really decoupled?

Error Handling

What happens if the Book Flight function becomes unhealthy, perhaps due to the outage of the third-party flight-booking service? Well, that's why we use asynchronous messaging:after the function execution fails, the message returns to the queue and is picked up again by another execution.

However, such retries happen almost immediately for most event sources. This might not be what we want: an exponential back-off policy could be a smarter idea. At this point, the retry logic becomes stateful: the next attempt should "know" the history of previous attempts to make a decision about retry timing.

There are more advanced error-handling patterns too. If executions failures are not intermittent, we may decide to cancel the whole process and run compensating actions against the already completed steps.

An example of this is a fallback action: if the flight is not possible (e.g., no routes for this origin-destination combination), the flow could choose to book a train instead:

This scenario is not trivial to implement with stateless functions. We could wait until a message goes to the dead-letter queue and then route it from there, but this is brittle and not expressive enough.

Parallel Actions

Sometimes the business process doesn't have to be sequential. In our reservation scenario, there might be no difference whether we book a flight before a hotel or vice versa. It could be desirable to run those actions in parallel.

Parallel execution of actions is easy with the pub-sub capabilities of an event bus: both functions should subscribe to the same event and act on it independently.

The problem comes when we need to reconcile the outcomes of parallel actions, e.g., calculate the final price for expense reporting purposes:

There is no way to implement the Report Expenses block as a single Azure Function: functions can't be triggered by two events, let alone correlate two related events.

The solution would probably include two functions, one per event, and the shared storage between them to pass information about the first completed booking to the one who completes last. All this wiring has to be implemented in custom code. The complexity grows if more than two functions need to run in parallel.

Also, don't forget the edge cases. What if one of the function fails? How do you make sure there is no race condition when writing and reading to/from the shared storage?

Missing Orchestrator

All these examples give us a hint that we need an additional tool to organize low-level single-purpose independent functions into high-level workflows.

Such a tool can be called an Orchestrator because its sole mission is to delegate work to stateless actions while maintaining the big picture and history of the flow.

Azure Durable Functions aims to provide such a tool.

Introducing Azure Durable Functions

Azure Functions

Azure Functions is the serverless compute service from Microsoft. Functions are event-driven: each function defines a trigger—the exact definition of the event source, for instance, the name of a storage queue.

Azure Functions can be programmed in several languages. A basic Function with a Storage Queue trigger implemented in C# would look like this:

[FunctionName("MyFirstFunction")]
public static void QueueTrigger(
    [QueueTrigger("myqueue-items")] string myQueueItem, 
    ILogger log)
{
    log.LogInformation($"C# function processed: {myQueueItem}");
}

The FunctionName attribute exposes the C# static method as an Azure Function named MyFirstFunction. The QueueTrigger attribute defines the name of the storage queue to listen to. The function body logs the information about the incoming message.

Durable Functions

Durable Functions is a library that brings workflow orchestration abstractions to Azure Functions. It introduces a number of idioms and tools to define stateful, potentially long-running operations, and manages a lot of mechanics of reliable communication and state management behind the scenes.

The library records the history of all actions in Azure Storage services, enabling durability and resilience to failures.

Durable Functions is open source, Microsoft accepts external contributions, and the community is quite active.

Currently, you can write Durable Functions in 3 programming languages: C#, F#, and Javascript (Node.js). All my examples are going to be in C#. For Javascript, check this quickstart and these samples. For F# see the samples, the F#-specific library and my article A Fairy Tale of F# and Durable Functions.

Workflow building functionality is achieved by the introduction of two additional types of triggers: Activity Functions and Orchestrator Functions.

Activity Functions

Activity Functions are simple stateless single-purpose building blocks that do just one task and have no awareness of the bigger workflow. A new trigger type, ActivityTrigger, was introduced to expose functions as workflow steps, as I explain below.

Here is a simple Activity Function implemented in C#:

[FunctionName("BookConference")]
public static ConfTicket BookConference([ActivityTrigger] string conference)
{
    var ticket = BookingService.Book(conference);
    return new ConfTicket { Code = ticket };
}

It has a common FunctionName attribute to expose the C# static method as an Azure Function named BookConference. The name is important because it is used to invoke the activity from orchestrators.

The ActivityTrigger attribute defines the trigger type and points to the input parameter conference which the activity expects to get for each invocation.

The function can return a result of any serializable type; my sample function returns a simple property bag called ConfTicket.

Activity Functions can do pretty much anything: call other services, load and save data from/to databases, and use any .NET libraries.

Orchestrator Functions

The Orchestrator Function is a unique concept introduced by Durable Functions. Its sole purpose is to manage the flow of execution and data among several activity functions.

Its most basic form chains multiple independent activities into a single sequential workflow.

Let's start with an example which books a conference ticket, a flight itinerary, and a hotel room one-by-one:

The implementation of this workflow is defined by another C# Azure Function, this time with OrchestrationTrigger:

[FunctionName("SequentialWorkflow")]
public static async Task Sequential([OrchestrationTrigger] DurableOrchestrationContext context)
{
    var conference = await context.CallActivityAsync<ConfTicket>("BookConference", "ServerlessDays");
    var flight = await context.CallActivityAsync<FlightTickets>("BookFlight", conference.Dates);
    await context.CallActivityAsync("BookHotel", flight.Dates);
}

Again, attributes are used to describe the function for the Azure runtime.

The only input parameter has type DurableOrchestrationContext. This context is the tool that enables the orchestration operations.

In particular, the CallActivityAsync method is used three times to invoke three activities one after the other. The method body looks very typical for any C# code working with a Task-based API. However, the behavior is entirely different. Let's have a look at the implementation details.

Behind the Scenes

Let's walk through the lifecycle of one execution of the sequential workflow above.

When the orchestrator starts running, the first CallActivityAsync invocation is made to book the conference ticket. What actually happens here is that a queue message is sent from the orchestrator to the activity function.

The corresponding activity function gets triggered by the queue message. It does its job (books the ticket) and returns the result. The activity function serializes the result and sends it as a queue message back to the orchestrator:

When the message arrives, the orchestrator gets triggered again and can proceed to the secondactivity. The cycle repeats—a message gets sent to Book Flight activity, it gets triggered, does its job, and sends a message back to the orchestrator. The same message flow happens for the third call.

Stop-resume behavior

As discussed earlier, message passing is intended to decouple the sender and receiver in time. For every message in the scenario above, no immediate response is expected.

On the C# level, when the await operator is executed, the code doesn't block the execution of the whole orchestrator. Instead, it just quits: the orchestrator stops being active and its current step completes.

Whenever a return message arrives from an activity, the orchestrator code restarts. It always starts with the first line. Yes, this means that the same line is executed multiple times: up to the number of messages to the orchestrator.

However, the orchestrator stores the history of its past executions in Azure Storage, so the effect of the second pass of the first line is different: instead of sending a message to the activity it already knows the result of that activity, so await returns this result back and assigns it to the conference variable.

Because of these "replays", the orchestrator's implementation has to be deterministic: don't use DateTime.Now, random numbers or multi-thread operations; more details here.

Event Sourcing

Azure Functions are stateless, while workflows require a state to keep track of their progress. Every time a new action towards the workflow's execution happens, the framework automatically records an event in table storage.

Whenever an orchestrator restarts the execution because a new message arrives from its activity, it loads the complete history of this particular execution from storage. Durable Context uses this history to make decisions whether to call the activity or return the previously stored result.

The pattern of storing the complete history of state changes as an append-only event store is known as Event Sourcing. Event store provides several benefits:

• Durability—if a host running an orchestration fails, the history is retained in persistent storage and is loaded by the new host where the orchestration restarts;
• Scalability—append-only writes are fast and easy to spread over multiple storage servers;
• Observability—no history is ever lost, so it's straightforward to inspect and analyze even after the workflow is complete.

Here is an illustration of the notable events that get recorded during our sequential workflow:

Billing

Azure Functions on the serverless consumption-based plan are billed per execution + per duration of execution.

The stop-replay behavior of durable orchestrators causes the single workflow "instance" to execute the same orchestrator function multiple times. This also means paying for several short executions.

However, the total bill usually ends up being much lower compared to the potential cost of blocking synchronous calls to activities. The price of 5 executions of 100 ms each is significantly lower than the cost of 1 execution of 30 seconds.

By the way, the first million executions per month are at no charge, so many scenarios incur no cost at all from Azure Functions service.

Another cost component to keep in mind is Azure Storage. Queues and Tables that are used behind the scenes are charged to the end customer. In my experience, this charge remains close to zero for low- to medium-load applications.

Beware of unintentional eternal loops or indefinite recursive fan-outs in your orchestrators. Those can get expensive if you leave them out of control.

Error-handling and retries

What happens when an error occurs somewhere in the middle of the workflow? For instance, a third-party flight booking service might not be able to process the request:

This situation is expected by Durable Functions. Instead of silently failing, the activity function sends a message containing the information about the error back to the orchestrator.

The orchestrator deserializes the error details and, at the time of replay, throws a .NET exception from the corresponding call. The developer is free to put a try .. catch block around the call and handle the exception:

[FunctionName("SequentialWorkflow")]
public static async Task Sequential([OrchestrationTrigger] DurableOrchestrationContext context)
{
    var conf = await context.CallActivityAsync<ConfTicket>("BookConference", "ServerlessDays");
    try
    {
        var itinerary = MakeItinerary(/* ... */);
        await context.CallActivityAsync("BookFlight", itinerary);
    }
    catch (FunctionFailedException)
    {
        var alternativeItinerary = MakeAnotherItinerary(/* ... */);
        await context.CallActivityAsync("BookFlight", alternativeItinerary);
    }
    await context.CallActivityAsync("BookHotel", flight.Dates);
}

The code above falls back to a "backup plan" of booking another itinerary. Another typical pattern would be to run a compensating activity to cancel the effects of any previous actions (un-book the conference in our case) and leave the system in a clean state.

Quite often, the error might be transient, so it might make sense to retry the failed operation after a pause. It's a such a common scenario that Durable Functions provides a dedicated API:

var options = new RetryOptions(
    firstRetryInterval: TimeSpan.FromMinutes(1),                    
    maxNumberOfAttempts: 5);
options.BackoffCoefficient = 2.0;

await context.CallActivityWithRetryAsync("BookFlight", options, itinerary);

The above code instructs the library to

• Retry up to 5 times
• Wait for 1 minute before the first retry
• Increase delays before every subsequent retry by the factor of 2 (1 min, 2 min, 4 min, etc.)

The significant point is that, once again, the orchestrator does not block while awaiting retries. After a failed call, a message is scheduled for the moment in the future to re-run the orchestrator and retry the call.

Sub-orchestrators

Business processes may consist of numerous steps. To keep the code of orchestrators manageable, Durable Functions allows nested orchestrators. A "parent" orchestrator can call out to child orchestrators via the context.CallSubOrchestratorAsync method:

[FunctionName("CombinedOrchestrator")]
public static async Task CombinedOrchestrator([OrchestrationTrigger] DurableOrchestrationContext context)
{
    await context.CallSubOrchestratorAsync("BookTrip", serverlessDaysAmsterdam);
    await context.CallSubOrchestratorAsync("BookTrip", serverlessDaysHamburg);
}

The code above books two conferences, one after the other.

Fan-out / Fan-in

What if we want to run multiple activities in parallel?

For instance, in the example above, we could wish to book two conferences, but the booking order might not matter. Still, when both bookings are completed, we want to combine the results to produce an expense report for the finance department:

In this scenario, the BookTrip orchestrator accepts an input parameter with the name of the conference and returns the expense information. ReportExpenses needs to receive both expenses combined.

This goal can be easily achieved by scheduling two tasks (i.e., sending two messages) without awaiting them separately. We use the familiar Task.WhenAll method to await both and combine the results:

[FunctionName("ParallelWorkflow")]
public static async Task Parallel([OrchestrationTrigger] DurableOrchestrationContext context)
{
    var amsterdam = context.CallSubOrchestratorAsync("BookTrip", serverlessDaysAmsterdam);
    var hamburg   = context.CallSubOrchestratorAsync("BookTrip", serverlessDaysHamburg);

    var expenses = await Task.WhenAll(amsterdam, hamburg);

    await context.CallActivityAsync("ReportExpenses", expenses);
}

Remember that awaiting the WhenAll method doesn't synchronously block the orchestrator. It quits the first time and then restarts two times on reply messages received from activities. The first restart quits again, and only the second restart makes it past the await.

Task.WhenAll returns an array of results (one result per each input task), which is then passed to the reporting activity.

Another example of parallelization could be a workflow sending e-mails to hundreds of recipients. Such fan-out wouldn't be hard with normal queue-triggered functions: simply send hundreds of messages. However, combining the results, if required for the next step of the workflow, is quite challenging.

It's straightforward with a durable orchestrator:

var emailSendingTasks =
    recepients
    .Select(to => context.CallActivityAsync<bool>("SendEmail", to))
    .ToArray();

var results = await Task.WhenAll(emailSendingTasks);

if (results.All(r => r)) { /* ... */ }

Making hundreds of roundtrips to activities and back could cause numerous replays of the orchestrator. As an optimization, if multiple activity functions complete around the same time, the orchestrator may internally process several messages as a batch and restart the orchestrator function only once per batch.

Other Concepts

There are many more patterns enabled by Durable Functions. Here is a quick list to give you some perspective:

• Waiting for the first completed task in a collection (rather than all of them) using the Task.WhenAny method. Useful for scenarios like timeouts or competing actions.
• Pausing the workflow for a given period or until a deadline.
• Waiting for external events, e.g., bringing human interaction into the workflow.
• Running recurring workflows, when the flow repeats until a certain condition is met.

Further explanation and code samples are in the docs.

Conclusion

I firmly believe that serverless applications utilizing a broad range of managed cloud services are highly beneficial to many companies, due to both rapid development process and the properly aligned billing model.

Serverless tech is still young; more high-level architectural patterns need to emerge to enable expressive and composable implementations of large business systems.

Azure Durable Functions suggests some of the possible answers. It combines the clarity and readability of sequential RPC-style code with the power and resilience of event-driven architecture.

The documentation for Durable Functions is excellent, with plenty of examples and how-to guides. Learn it, try it for your real-life scenarios, and let me know your opinion—I'm excited about the serverless future!

Acknowledgments

Many thanks to Katy Shimizu, Chris Gillum, Eric Fleming, KJ Jones, William Liebenberg, Andrea Tosato for reviewing the draft of this article and their valuable contributions and suggestions.