Search icon CANCEL
Cart icon
Close icon
You have no products in your basket yet
Save more on your purchases!
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Learning Hub
Free Learning
Arrow right icon
Advanced Serverless Architectures with Microsoft Azure
Advanced Serverless Architectures with Microsoft Azure

Advanced Serverless Architectures with Microsoft Azure: Design complex serverless systems quickly with the scalability and benefits of Azure

By Daniel Bass
€22.99 €15.99
Book Feb 2019 278 pages 1st Edition
€22.99 €15.99
€14.99 Monthly
€22.99 €15.99
€14.99 Monthly

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now
Table of content icon View table of contents Preview book icon Preview Book

Advanced Serverless Architectures with Microsoft Azure

Chapter 1. Complete Serverless Architectures


Learning Objectives

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

  • Create a Function-as-a-Service

  • Use a Database-as-a-Service

  • Create a serverless web application


This chapter will cover the main components that are required to make a complete serverless architecture, beyond the FaaS components (Azure Functions).


Serverless architecture, while still a small field, has continued to grow as a topic of interest in software development. Some serverless architectures are now becoming highly complex, powering massively scalable applications that deliver business value across domains. As serverless architecture advances in complexity, it presents unique challenges that aren't really present in other approaches, or if they are present, they are hidden by the other, more major issues that plague those approaches. This book will give you a pragmatic, rational, and experience-based approach to architecting your serverless solution to minimize issues and maximize scalability.

Let's first define Serverless. The current working definition of serverless that's defined in this book is as follows: "A service that abstracts away all server details, provides reactive scaling to demand, and is charged on a resource-usage-based payment model". This encompasses serverless databases and takes into account reactive scaling. Serverless fits use cases from simple web applications to massively scaled and complex applications with millions of users. This book will help you build from a simple web application (with the capability to scale to millions of users with no extra effort from the developers) to a complex application, thus utilizing security, observability, queuing, and caching.

Incorporating serverless components in other styles of architecture is relatively straightforward—for instance, it is easy to use a Function-as-a-Service as a simple replacement for a RESTful API. This approach generally works well, and you can gain large advantages by doing this. To fully realize the benefits of serverless, however, a complete serverless architecture is needed. Building one of these once will also change the way you think about application architecture, meaning that even if you have requirements that demand a non-serverless component, you can still keep the rest of the architecture serverless-first. The components that are covered in this chapter are Function-as-a-Service (FaaS), the Serverless Database, and the Serverless Website. Other components that will be covered later are queues, event hubs, authentication services, and monitoring and logging services.

Function-as-a-Service with a Simple HTTP Trigger

The core component of any serverless architecture is the Function-as-a-Service. The idea of any Function-as-a-Service is basically this: you write your code, send it to your cloud provider, and they handle every aspect of making that available to yourself and your customers. This means developers focus purely on the business logic, and not on unrelated technical things. This also means developers can deliver value much faster, and in a modern business, this is the single-most important advantage you can have.

If you've completed the previous book, Beginning Serverless Architectures with Microsoft Azure, you will know about Azure's product in this area very well: Azure Functions. Azure Functions can be written in C# (.NET Core 2), F# (.NET Core 2) or Javascript (Node 8 and 10). There's a plethora of other languages with varying levels of support, such as Python, Java, and PowerShell, but as they are in preview or marked as experimental, they won't be covered here, and they aren't advised for production use. The experimental languages, and Python and Java in their preview states, have very poor performance as well. Azure Functions also comes in two versions, 1.x and 2.x. We will solely be using version 2.x in this book.


1.x's underlying infrastructure is written in .NET and 2.x's is written in the newer, faster, and cross-platform .NET Core. Version 2 is now in General Availability, and therefore it is advised to only use it for new projects (unless you have some strong dependency on a .NET-only library). It would also be advisable to convert any existing functions to version 2 for the performance benefits alone, but it's also likely that version 1 will eventually be deprecated. If you are looking for support for other languages, Java is the most likely next language to be fully supported by Azure Functions and there are a large number of unsupported yet reasonably functional languages. Alternatively, AWS Lambda supports Java, Go, and Python, in addition to C# and Node.js.

Exercise 1: Creating an Azure Function

In this exercise, you will be learning how to create a function, which is the most important component of any serverless architecture, in C#. We will be using Azure Functions to do this. We will also see how to run this function locally and in the cloud:


If you are getting asked what environment to attach to when you click the play button, you are likely to be in a folder too high. Make sure you have opened Visual Studio Code inside the ProductsApi folder.

  1. Let's begin by first creating our Azure function. Create a new folder in your development area called ProductsApi. Open a command-line tool inside the folder and open Visual Studio Code by typing code . or clicking on the Visual Studio Code icon:

    Figure 1.1: Empty Visual Studio Code screen

  2. Click on the Azure logo, which will appear on the pane on the left if you've downloaded the Azure Functions extension. Then, click on the Sign in to Azure… button and authorize Visual Studio Code with your Azure subscription. Select your free subscription if asked:

    Figure 1.2: Azure Functions Extension screen before signing in to Azure

  3. Now that your environment is ready, click the folder icon with a small lightning bolt icon (see the previous screenshot) in the Azure Functions pane on the left to create a new Azure Functions project. A message will appear in the command palette at the top of the screen. Select your current folder:

    Figure 1.3: Creating a new Azure Functions project

  4. After this, you will be prompted to select a language for your project. Select C# :

    Figure 1.4: Selecting C#

  5. The Azure Functions extension will have scaffolded you a project with no real code—just a .csproj file to define the build process and host.json and local.settings.json files, as shown in the following screenshot:

    Figure 1.5: Scaffolded Azure Function project


    The host.json file defines the characteristics of the underlying container/runtime, such as how long the function can live for, the version of the runtime (1 or 2), or whether you want sampling in your logging. The local.settings.json file stores application settings, similar to IIS Application Settings, for when you are running the function locally. This is for release variables, passwords, and so on.

  6. Open the Azure Functions extension again and click the lightning bolt with the small plus sign on it to add a function (see Figure 1.2). Select HttpTrigger when prompted for a function template:

    Figure 1.6 Choosing the HttpTrigger template

  7. Name the function GetProducts, as follows:

    Figure 1.7 Naming the function

  8. When prompted to set the namespace, set it to ProductsApi, as follows:

    Figure 1.8 Setting the namespace

  9. You will then be prompted to set AccessRights. Set it to Function:

    Figure 1.9 Setting Access Rights

  10. Once this is done, a function will be templated for you, as follows:

    Figure 1.10 Templated function

  11. When prompted, click Restore on the popup in the bottom right that states that some packages are missing. If you're not prompted, open a terminal window by clicking on the Terminal −> new Terminal button at the top of Visual Studio Code and typing dotnet restore in the ProductsApi folder:

    Figure 1.11: Restoring packages in the inbuilt terminal

  12. Click on the debug button (the bug with the cross through it, which is visible on the left pane of the window) and click on the green play button to start the debug session:

    Figure 1.12: Running the local function

  13. We have now started our Azure Function on our local machine, so let's test it. Visit the address shown in the terminal (by azure-functions-core-tools) in your browser, and try adding a query parameter for the name, like this: http://localhost:7071/api/GetUserData?name=Bob. The following screenshot shows the output obtained for this query:

    Figure 1.13: Browser showing the output of the local Azure function

  14. Let's get our function onto the cloud, where it belongs. Open the Azure Functions tab again and click the up arrow to upload this function to Azure (see Figure 1.2). Create a new Function App with a globally unique name (hence it cannot be specified here):

    Figure 1.14: Choosing a Function App

    The name that's used in this exercise is AdvancedServerlessProductsApi:

    Figure 1.15 Creating a Function App

    Figure 1.16: Choosing a resource group

  15. When prompted to select a resource group, click on Create new resource group, as shown in the following screenshot:

    The resource group that was created in this exercise is named productapi-rg:

    Figure 1.17: Creating a new resource group

  1. Next, click on Create new storage account when prompted:

    Figure 1.18: Choosing a storage account

    Enter the name of your storage account (the one used in this exercise is productapi):

    Figure 1.19: Creating a new storage account

  2. Next, choose your local Azure Region when prompted, as shown in the following screenshot:

    Figure 1.20: Choosing an Azure Region

    This may take a little while. You will see progress windows in the bottom right corner:

    Figure 1.21: Successfully deployed Function App

  3. Your Function App should now have appeared on the left, as shown in the following screenshot. If you expand the functions dropdown, you can find the function you have just deployed and right-click it to get the URL:

    Figure 1.22: Deployed function viewed through Visual Studio Code extension

  4. Try out your function by copying the URL into your browser:

    Figure 1.23: Function running in the cloud

Congratulations, you've created and run an Azure function locally and in the cloud. You should be able to see from this just how quick and easy it is to develop and deploy Azure functions. The function listens for a simple HTTP trigger event and returns a simple message. Anything that you can do in C# can be done using this function.

Serverless Database with Cosmos DB

Most applications need a data persistence layer. The most performant and scalable database with no management on Azure is Cosmos DB. It's the best database available for a serverless architecture, especially as serverless functions can quickly expose scaling issues in conventional databases with their instant and infinite scaling. The following are some of its features:

It's the best database available for a serverless architecture, especially as serverless functions can quickly expose scaling issues in conventional databases with their instant and infinite scaling.

Cosmos DB is considered serverless because it is entirely managed, with no server-level specifics, and is charged per resource used rather than upfront. There can be a blurred line with managed services—if they are managed enough, they can be considered serverless. However, Cosmos DB is definitely serverless because of its resources-used payment model. To expand on this point further, other managed services such as a piece of SaaS software would only count toward a true serverless architecture if they were charged per-resource-usage. This is still fairly uncommon, with software such as Apigee, Sitecore, or Salesforce generally demanding large licenses, irrespective of usage.

  • It is a NoSQL database with customizable levels of consistency (with a tradeoff against performance) and multiple supported data models.

  • It is charged per request (and the complexity of that request) and the data stored.

  • It is generally fairly expensive but will scale infinitely across the globe.

Exercise 2: Creating a Cosmos DB Instance

This exercise will walk you through creating a Cosmos DB instance in the Azure portal. Follow these steps:

  1. Open the Azure Portal and search for "cosmos." Click on the result that says Azure Cosmos DB:

    Figure 1.24: Searching for Cosmos DB

  2. You should see a screen like the following one, which has an Add button in the top left. Click Add:

    Figure 1.25: Screen before creating an Azure Cosmos DB instance

  3. On clicking Add, you will see a window like the one shown in the following screenshot. Fill in the Resource Group, the name you want your Cosmos DB instance to have (advancedserverlessproductdb is used as the Account Name in this exercise), and the region you want it to be in (Location). Select the SQL API. Given that this is a development book for learning, switch off Georedundancy:


    In a real deployment, you would certainly want to enable Georedundancy. Under the hood, it deploys Cosmos DB to each of the "paired" Azure datacenters, such as North Europe and West Europe, for example. Multi-region Writes are certainly something you should consider if you are running a truly global application, with users wanting to edit data across the world. One thing to bear in mind with this is that if you have a consistency model that forces cross-regional locks on writing, this setting could contribute to a deterioration in performance.

    Figure 1.26: Azure Cosmos DB setup – Basics

  4. Click Review + create on the bottom of the screen and then click on the Create button. This will kick off the deployment of your Cosmos DB:

    Figure 1.27: Summary of Azure Cosmos DB account

    It's likely to take a little while. If you click on the notifications button (the bell icon) in the portal, you can check on how it is progressing:

    Figure 1.28: Notification of progress when creating a Cosmos DB


    If you click the Download a template for automation link in the bottom right (see Figure 1.27), you will get the ARM template and scripts in Bash, PowerShell, and Ruby for deploying that template. Behind the scenes, the portal simply submits the same template, and this template and code is very useful for your CI/CD pipelines.

You now have an Azure Cosmos DB running, ready to be your serverless persistence layer. This database will happily handle any plausible scale that can be thrown at it, without you having to lift a finger. It also has the ability to trigger Azure Functions on data that are being entered or modified in it, which is a core capability that we will be building on. If you need a RDBMS, and a NoSQL database is simply unacceptable, then other contenders to Cosmos DB would be the SQL Azure, Azure for PostgresSQL, and Azure for MySQL. However, these have the disadvantage of lack of true elastic scaling from a serverless point of view, and all the usual tradeoffs of SQL versus NoSQL apply. Generally, though, they will fit most requirements; they just need more management than a true serverless solution such as Cosmos DB. As always for any application architecture, pragmatism applies.

Serverless Websites with Azure Storage

The final component of the basic serverless architecture is a client frontend. The most common one is web-based, but obviously mobile apps or chatbots are also used. We will be using a web-based frontend in this book.

This is the area that serverless is least developed in. The core idea, however, is to have some way of serving the raw HTML, CSS, and JS files to the client, and having JavaScript call the serverless backend from the client side. The only issue is where and how to host those HTML files.

There are multiple approaches to this. Many applications will be expanding on a current platform, perhaps a CMS such as Adobe Experience Manager, Wordpress, or Sitecore CMS. In that case, the best approach is likely to be embedding your frontend application as a JavaScript Single Page Application in a framework such as Angular, React, or Vue.

If working with a completely greenfield application where you can build a truly serverless application architecture, however, there are a greater range of options, which are listed in order of "serverless-ness" in the following list. One thing to be clear about, however, is that this isn't a fully solved problem yet, so each option will have some disadvantages that will hopefully be fixed over time:

  • Use Azure Storage Static Website Hosting: This has very recently come out of preview, and is now in General Availability. It may be a little unstable given how new the feature is. This feature allows you to use Azure Storage as the repository for your HTML, CSS, and JS files, and set a default home page and a default error page. This is the most serverless option as there are no implementation details or management requirements whatsoever—you can literally put your frontend code there and it will work. This will be the option we will follow in this book.

  • Serve files using an Azure Function: The second option is to use an Azure function as a way of hosting your HTML, CSS, or JS files. If you put your HTML code files into the C# project, you can reply to any HTTP Trigger with them. Azure Functions have standard IIS routing too, which can be used to route to the different pages. This has a few disadvantages though: Azure Functions are charged per gigabyte of RAM per second, so using them to simply transfer potentially large files isn't ideal (as that file will be loaded into the RAM and will need to be encoded and decoded, resulting in needless expense). Also, it isn't very serverless—this solution requires custom, non-business-value-oriented code just to serve up web pages. It will, however, scale along with your serverless backend, and Azure Functions are more mature than Azure Storage Static Website Hosting.

  • Deploy Files to an Azure App Service: The third option is to deploy the files to an Azure App Service. This Platform-as-a-Service technology is well-suited to this task and can host more complex MVC applications as well. They can also scale horizontally without management, which is advantageous. However, the number is limited depending on how "big" a resource you demand. The major issue is the level of management and implementation detail. All we want as serverless developers is a bucket to put files in, and Azure's App Services have all sorts of details we aren't interested in, for example, the number of virtual cores on each instance or the RAM currently being used. One point in their favor for small projects though is the "free" category of hosting, which allows you to deploy a custom web app to the internet for free. This is really useful for prototypes, too.

As you can see, the options progress in management level, adding more and more effort expended into non-business value activities. This is without going down to the level of maintaining a virtual machine or a Kubernetes cluster or, even worse, a physical machine in a rack.


There is in fact a fourth option for utilizing AWS. The storage service in AWS is called S3 and has a fully supported static website hosting feature, which you can read about here: There aren't any compatibility issues in doing this—latency isn't even an issue as users will be calling the Azure Functions' endpoints from their browsers. Lambda (AWS's FaaS service) can also serve files like Azure Functions.

Exercise 3: Hosting a Serverless Website on Azure Storage

The aim of this exercise is to host a simple Hello World! page on Azure Storage, thus creating a serverless website:

  1. First, you need files to host. Create a new folder called ServerlessWebsite in your development area and create new index.html and error.html files in there:

    Figure 1.29: Empty website files

  2. Create a simple page for both the index and error. The following code can be used to display Hello World!:

        <h1>Hello World!</h1>

    The following example can be used to display Error:

    Figure 1.30: Error page

  3. Now that you've created the files to host, let's create an account on Azure Storage where you can host these files. Open the Azure Portal and search for "storage":

    Figure 1.31: Searching for storage

  4. Select Storage accounts. You should see a screen like the one shown in the following screenshot, with at least one storage account already existing from when you created it. You may see more if you have already been using Azure and have already made some storage accounts:


    It's possible that you will see other categories of storage account in the search, such as classic. This depends on your Azure Account, so you won't necessarily see any others. Just always select the one that precisely says Storage accounts.

    Figure 1.32: Azure Storage Accounts page

  5. Click Add. You should be taken to a screen like the one shown in the following screenshot. Enter the same resource group that you did for Cosmos DB and the Azure Function App. Give your storage account an appropriate name for hosting a website (the one in this exercise is named webfrontendadvanceds). Choose a location near to you. Choose Standard performance, StorageV2, and simple Locally Redundant Storage or RA-GRS. In production, you will probably want a greater level of georedundancy, but for development purposes, locally redundant storage is fine. Premium performance is actually designed for virtual machine disks, not for web hosting, and is not currently supported with static site hosting. Finally, choose the Hot access tier; Cold is for archiving data:


    Note that storage account names have to be globally unique. Hence, do not try and create a storage account with the exact same name as the one that's used in this exercise.

    Figure 1.33: Creating a storage account

  6. Click the Review + create button and then create the storage account. This may take a little while to provision. You will receive a notification in the top right of the page when it has been created:

    Figure 1.34: Creating a storage account

  7. Now, you can host the files you created on your Azure Storage account. Go to the storage account you just created (it will appear on the pane on the left) and click on it:

    Figure 1.35: Storage Account Home

  8. Scroll down the left column and look for Static website (preview) under Settings. Enable it and set your Index document name to index.html and your Error document path to error.html, as shown in the following screenshot:

    Figure 1.36: Setting up static website hosting

  9. Click on the Azure tab. We are going to use the Azure Storage extension of Visual Studio Code to deploy the site. Click the Azure Storage account and open the Blob Containers sub-item until you get to the $web item. Right-click it and select Deploy to Static Website:

    Figure 1.37: Deploy to Static Website


    Using the Azure Storage extension of Visual Studio Code is the easiest manual way to upload files to Azure Storage. If you are doing an automated deployment, you should use a PowerShell script to connect.

  10. You will now be prompted to select a folder to deploy. Select the ServerlessWebsite folder:

    Figure 1.38: Selecting a folder to deploy

  11. Click Delete and Deploy if the following message comes up. It won't if you have never deployed anything to this Azure Storage account before:


    Figure 1.39: Confirming deployment

    As before, updates on the deployment will appear in the bottom right:

    Figure 1.40: Deployment updates

  12. You can finally test your website by visiting the address of your Azure Blob Storage account in your browser. This can be found by clicking on the browse site button in the successful deployment update, going back to the static website part of the portal, or by using the pattern they all follow: https://{StorageAccountName}

    Figure 1.41: Serverless website hosted on Azure Storage

You now have the fundamental building blocks of a complete serverless architecture. With Azure Storage hosting your website, you can build any web application. Of course, other client-side delivery methods such as mobile apps and chatbots are possible. Mobile apps are a perfect fit, simply calling the serverless backend directly. Chatbots would use Alexa or Google Assistant as their frontend and call in to the serverless backend.

Exercise 4: Displaying Product Data on Your Serverless Website

In this exercise, you will be displaying product data from the serverless database (Cosmos DB) on the serverless website hosted in the Azure Storage, using the Azure Function you created in the first exercise. It will serve as the basis for the rest of your work on this book, and an inspiration for how easy and quick this development process is:

  1. First of all, you need some product data to display. Go to the Cosmos DB instance in the Azure Portal and select Data Explorer:

    Figure 1.42: Cosmos DB Data Explorer

  2. Click on the New Database option to create a database. Call it serverless and click on OK:

    Figure 1.43: Creating a database

  3. Next, click on the New Collection option and create a collection called products in the serverless database that we created in the preceding step. Set its throughput to 400 Resource Units (this is how Cosmos DB charges for compute usage on queries) and set the Partition key to /colour. Again, click on OK:

    Figure 1.44: Creating a collection

  4. Click on Documents inside the Collection, as shown in the following screenshot:

    Figure 1.45: Selecting Documents inside the collection

  5. Click on the New Document option. Insert some records into the Cosmos DB, which will represent products. An example is shown in the following code. Make sure that you do not remove or misspell any of the property names as it will cause problems later. The ID follows the pattern {typeId}_{name}_{colour}_{size}. Cosmos DB will add some fields, including a very useful Etag, which will be used later. In general, you don't need to worry about the automatically added fields; Cosmos DB will handle them:

        "typeId": "tshirt",
        "name": "Metallica",
        "colour": "black",
        "size": "xl",
        "quantityInStock": 100

    Figure 1.46: Creating a Cosmos DB record

    You have now added your product data to Cosmos DB. Now, you need to display this data on your website using the Azure function we created previously.

  6. Open the GetProducts Azure Function from Exercise 1, Creating an Azure Function. Install the DocumentDB package by opening the terminal in the ProductsApi folder and entering the following command:

    dotnet add package Microsoft.Azure.WebJobs.Extensions.CosmosDB --version 3.0.1


    Due to version upgrades, the latest version may not exactly match the one given here. We recommend that you use the latest version for this and the subsequent exercises and activities, in order to ensure that the command functions.

    Next, we need to ensure that all the NuGet packages are installed, which we do by "restoring". Use the following command:

    dotnet restore

    Your file will look as follows:

    Figure 1.47: Installing the DocumentDB extension

  7. We need to give our function the ability to read from the Cosmos DB. This is done using a DocumentClient object from the SDK. Add a using statement for Microsoft.Azure.Documents.Client and create a private static DocumentClient property called client:

    private static DocumentClient client = new DocumentClient(new Uri("cosmos endpoint"),"key");

    Figure 1.48: Added DocumentClient

  8. Next, we need the Unique Resource Identifier (URI) for the Collection inside the Cosmos DB instance. This will allow us to create queries against that collection. Create a private static Uri property that uses the UriFactory to create a URI for the DocumentCollection:

    private static Uri productCollectionUri = UriFactory.CreateDocumentCollectionUri("serverless","products");

    Your file will look as follows:

    Figure 1.49: Adding productCollectionUri

  9. Add a private static QueryOptions property with the MaxItemCount set to –1. This sets the number of docs returned in a query to infinite, which is something to be cautious of as your database scales:

    private static readonly FeedOptions productQueryOptions = new FeedOptions { MaxItemCount = -1 };

    Figure 1.50: Adding productQueryOptions

  10. Now, we need to return the products from Cosmos DB. We don't need the post method anymore, so delete post from the function signature. Change the return type to Task<List<Product>>. The Cosmos DB SDK uses an Iqueryable syntax that lets you use LINQ expressions in C# to generate queries on the database. This is superb for simple queries, but it is advisable to double-check what database queries it is generating for complex queries as they may not be optimally efficient. We will use the syntax to simply return all. Delete the entire function body and replace it with this:

    return client.CreateDocumentQuery<Product>(productCollectionUri, productQueryOptions).ToList();

    Also, add the following using statement:

    using System.Linq;

    Figure 1.51: Adding query returning products

  11. Add a Product class in a file called Product.cs in a folder called Models with properties matching the ones in the Cosmos DB. Add a JsonProperty annotation on the ID property to force it into lower case:

    Figure 1.52: Product Model

  12. Add the following three using statements to the GetProducts function:

    using System.Collections.Generic; using ProductsApi.Models;
  13. Now, go to Cosmos DB in the Azure Portal and click on Keys. Retrieve the endpoint and the primary key and enter them into the DocumentClient. This is vital to authorize your function to connect to your Cosmos DB.

  14. Test the function by pressing the play button on the debug tab and going to the address in your browser. You should see an output similar to the following when testing:

    Figure 1.53: Testing the function

  15. Open the ServerlessWebsite folder in VS Code. Add a table to the index.html file using the following code:

                    Quantity In Stock
        <tbody id='tableBody'>

    Figure 1.54: HTML Table

  16. Add a function that takes the object from the API and returns a table row by using the following code:

        function rowOfDataFromObject(data){
            let row = document.createElement('tr');
            let nameTableElement = document.createElement('td');
            let sizeTableElement = document.createElement('td');
            let colourTableElement = document.createElement('td');
            let quantityTableElement = document.createElement('td');
            return row;

    Figure 1.55: Function that returns a table row from a product object

  17. Add a HTTP GET call to the Azure function either by running locally or in the cloud using the fetch method, and turn it into a table row using the JavaScript method you just created (in the following screenshot, the function being called is one that would be running locally as the address in the fetch method is a localhost address):

    Figure 1.56: Fetching product data from the Azure function

  18. Append the rows to the table using the ID set in the HTML and the table rows created by the method:


    Figure 1.57: Appending rows to table

  19. Cross Origin Resource Sharing (CORS) is an important security measure that applies to Azure functions as well. It prevents scripts from unexpected websites calling your Azure Function. For the moment, though, this prevents us from testing effectively, so we are going to open it up to all. In production, you would give it only the addresses you expect, so this would be the URL of your website, for example. Open the ProductsApi folder and add a local.settings.json file if it isn't already there. Modify it to add an element called Host with a property called CORS with the value *:

    Figure 1.58: Setting CORS rules to permissive

  20. Finally, test your HTML page by opening it from your local disk or uploading it to Azure Storage and opening in your browser:

    Figure 1.59: Working web page displaying products

You've successfully created your first serverless application in only a couple of hours. This solution almost certainly scales better than anything most developers have ever made and required little extra effort from us.

Activity 1: Creating a Serverless Application for Viewing User Data

You are a developer working for Serverless Ltd. and you have been tasked with creating a serverless application for a client that lets them view basic data about the end customers of their clothing company. For this purpose, you need to create an end-to-end serverless app to view users. Follow these steps to complete this activity:

  1. Create a collection called users in the Cosmos DB database named serverless.

  2. Add some user data to it. The example object just uses name and email address:

        "name": "Daniel",
        "emailAddress": ""
  3. Create an Azure function called GetUsers that reads from the users collection.

  4. Create an index.html file that displays that data on a web page by using JavaScript to call the Azure function:

    Figure 1.60: Resulting User Table


The solution for this activity can be found on page 230.


This approach, with a simple website supported by serverless functions and a serverless database, will scale incredibly well and is very fast to develop. One particularly important thing to note is the total separation of frontend and backend development—this will free both disciplines of development to progress rapidly. Generally, frontend developers would use a SPA framework such as Angular, React, or Vue to produce an interactive web application, but it's equally possible to use vanilla JS or jQuery to call the serverless backend. In the next chapter, we will be covering asynchronous processing and caching as a way to increase the scalability of serverless architecture.

Left arrow icon Right arrow icon

Key benefits

  • Use serverless systems to help you fulfill complex requirements
  • Develop your knowledge of Azure Microsoft Serverless
  • Understand concepts with a hands-on approach and helpful examples


Advanced Serverless Architectures with Microsoft Azure redefines your experience of designing serverless systems. It shows you how to tackle challenges of varying levels, not just the straightforward ones. You'll be learning how to deliver features quickly by building systems, which retain the scalability and benefits of serverless. You'll begin your journey by learning how to build a simple, completely serverless application. Then, you'll build a highly scalable solution using a queue, load messages onto the queue, and read them asynchronously. To boost your knowledge further, the book also features durable functions and ways to use them to solve errors in a complex system. You'll then learn about security by building a security solution from serverless components. Next, you’ll gain an understanding of observability and ways to leverage application insights to bring you performance benefits. As you approach the concluding chapters, you’ll explore chaos engineering and the benefits of resilience, by actively switching off a few of the functions within a complex system, submitting a request, and observing the resulting behavior. By the end of this book, you will have developed the skills you need to build and maintain increasingly complex systems that match evolving platform requirements.

What you will learn

Understand what true serverless architecture is Study how to extend and scale architectures until they become ‘complex Implement durable functions in your design Improve the observability of your serverless architecture Implement security solutions using serverless services Learn how to ‘practise chaos engineering in production

Product Details

Country selected

Publication date : Feb 28, 2019
Length 278 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781788479127
Vendor :
Languages :
Concepts :

What do you get with eBook?

Product feature icon Instant access to your Digital eBook purchase
Product feature icon Download this book in EPUB and PDF formats
Product feature icon Access this title in our online reader with advanced features
Product feature icon DRM FREE - Read whenever, wherever and however you want
Buy Now

Product Details

Publication date : Feb 28, 2019
Length 278 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781788479127
Vendor :
Languages :
Concepts :

Table of Contents

8 Chapters
Preface Chevron down icon Chevron up icon
1. Complete Serverless Architectures Chevron down icon Chevron up icon
2. Microservices and Serverless Scaling Patterns Chevron down icon Chevron up icon
3. Azure Durable Functions Chevron down icon Chevron up icon
4. Security Chevron down icon Chevron up icon
5. Observability Chevron down icon Chevron up icon
6. Chaos Engineering Chevron down icon Chevron up icon
Appendix Chevron down icon Chevron up icon

Customer reviews

Top Reviews
Rating distribution
Empty star icon Empty star icon Empty star icon Empty star icon Empty star icon 0
(0 Ratings)
5 star 0%
4 star 0%
3 star 0%
2 star 0%
1 star 0%
Top Reviews
No reviews found
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial


How do I buy and download an eBook? Chevron down icon Chevron up icon

Where there is an eBook version of a title available, you can buy it from the book details for that title. Add either the standalone eBook or the eBook and print book bundle to your shopping cart. Your eBook will show in your cart as a product on its own. After completing checkout and payment in the normal way, you will receive your receipt on the screen containing a link to a personalised PDF download file. This link will remain active for 30 days. You can download backup copies of the file by logging in to your account at any time.

If you already have Adobe reader installed, then clicking on the link will download and open the PDF file directly. If you don't, then save the PDF file on your machine and download the Reader to view it.

Please Note: Packt eBooks are non-returnable and non-refundable.

Packt eBook and Licensing When you buy an eBook from Packt Publishing, completing your purchase means you accept the terms of our licence agreement. Please read the full text of the agreement. In it we have tried to balance the need for the ebook to be usable for you the reader with our needs to protect the rights of us as Publishers and of our authors. In summary, the agreement says:

  • You may make copies of your eBook for your own use onto any machine
  • You may not pass copies of the eBook on to anyone else
How can I make a purchase on your website? Chevron down icon Chevron up icon

If you want to purchase a video course, eBook or Bundle (Print+eBook) please follow below steps:

  1. Register on our website using your email address and the password.
  2. Search for the title by name or ISBN using the search option.
  3. Select the title you want to purchase.
  4. Choose the format you wish to purchase the title in; if you order the Print Book, you get a free eBook copy of the same title. 
  5. Proceed with the checkout process (payment to be made using Credit Card, Debit Cart, or PayPal)
Where can I access support around an eBook? Chevron down icon Chevron up icon
  • If you experience a problem with using or installing Adobe Reader, the contact Adobe directly.
  • To view the errata for the book, see and view the pages for the title you have.
  • To view your account details or to download a new copy of the book go to
  • To contact us directly if a problem is not resolved, use
What eBook formats do Packt support? Chevron down icon Chevron up icon

Our eBooks are currently available in a variety of formats such as PDF and ePubs. In the future, this may well change with trends and development in technology, but please note that our PDFs are not Adobe eBook Reader format, which has greater restrictions on security.

You will need to use Adobe Reader v9 or later in order to read Packt's PDF eBooks.

What are the benefits of eBooks? Chevron down icon Chevron up icon
  • You can get the information you need immediately
  • You can easily take them with you on a laptop
  • You can download them an unlimited number of times
  • You can print them out
  • They are copy-paste enabled
  • They are searchable
  • There is no password protection
  • They are lower price than print
  • They save resources and space
What is an eBook? Chevron down icon Chevron up icon

Packt eBooks are a complete electronic version of the print edition, available in PDF and ePub formats. Every piece of content down to the page numbering is the same. Because we save the costs of printing and shipping the book to you, we are able to offer eBooks at a lower cost than print editions.

When you have purchased an eBook, simply login to your account and click on the link in Your Download Area. We recommend you saving the file to your hard drive before opening it.

For optimal viewing of our eBooks, we recommend you download and install the free Adobe Reader version 9.