Beginning Serverless Architectures with Microsoft Azure: Design scalable applications and microservices that effortlessly adapt to the requirements of your customers

We will discuss each of its main benefits in detail here.

Serverless code does have some weaknesses which are described here.

Before you begin, confirm that you have Visual Studio 2017 version 15.4 installed; if not, download and install it. To do so, perform the following steps: 

Now, we'll create a new Azure Function as a part of our serverless architecture that listens to HTTP requests to a certain address. It will listen to HTTP requests to a certain address as its trigger. Let's begin by implementing the following steps:

Configuration as code is an important modern development practice. Rather than having servers reconfigured or configured manually by developers before code is deployed to them, configuration as code dictates that all of the configuration required to deploy an application to production be included in the source code.

This allows for variable replacement by your build/release agent, as you will (understandably) want slightly different settings, depending on your environment. Azure Functions implement this principle, with a configuration split between the host.json file for app-wide configurations and app settings, and the Run method signature for individual functions. Therefore, you can deploy an Azure Function to production with only the code that you find in the GitHub repository:

Outcome

You created an Azure Function, understood the roles the different files play, and learned about configuration as code.

The FunctionName annotation defines the name of the function within the Function App.

This can be used for triggering your function, or it can be kept separate. The first parameter is an HttpRequestMessage object with an HttpTrigger attribute. This is what varies when you choose different triggers (for example, a timer trigger will have an object with a TimerTrigger attribute).

This attribute has several arguments. The first is the authorization level. Do you remember setting this when you created the function? It was called Access rights in the template. This defines the level of authorization that the function will demand of HTTP requests. The five levels are shown in the following table:

The next parameters are GET and POST, which define the HTTP verbs that will activate the function. Generally, from a microservices architecture point of view, you should only have one verb, to prevent you from having to do bug-prone switching logic inside of the function. You can simply create four separate functions if you want GET,  POST,  PUT, and  DELETE on an artifact.

Finally, there is a string assigned to the property route. This is the only bit of routing logic that the function itself can see, and it simply defies the subpath from the Function App. It accepts WebAPI syntax, which you can see in the curly braces, / {name}. This will assign any text that appears where the curly braces are to a parameter called name.

This completes the HttpTrigger object. Other types of triggers, which we will touch on later, have different objects and different constructors. The three parameters left in the method signature are an HttpRequestMessage object, which allows you to access the HttpRequestMessage that triggered the function; a string parameter called name, which is what the string in the curly braces in the path will get bound to; and a TraceWriter for logging.

The current logic of the Function App can be seen in the following example, and you should see that it will take whatever name is put into it and send back an HTTP response saying Hello to that name. We will test this out in the next subtopic.

You now have a working Azure Function that can be deployed to Azure or run locally. We will first host and debug the function locally, to show the development cycle in action. At the moment, its logic is very basic and not particularly useful, so we will be developing this to store some data in a cloud-hosted database over the rest of the chapter.

Debug an Azure Function

In this section, we'll run an Azure Function locally and debug it. We'll  be developing new functions and test the functionality before deploying to public cloud. And to ensure that it happens correctly, we'll require the single function created directly from the HTTP trigger with parameters template. 

Currently, your machine does not have the correct runtime to run an Azure Function, so we need to download it:

1. Click the Play button in Visual Studio, and a dialog box should ask you if you want to download Azure Functions Core Tools—click on Yes. A Windows CMD window will open, with the lightning bolt logo of Azure Functions:

Note

It will bootstrap the environment and attach the debugger from Visual Studio. It will then list the endpoints the Function App is listening on.

2. Open up Postman app and copy and paste the endpoint into it, selecting either a POST or GET verb.

Note

You should get the response Hello {name}. Try changing the {name} in the path to your name, and you will see a different response. You can download Postman at https://www.getpostman.com/.

3. Create a debug point in the Run method by clicking in the margin to the left of the code:

               

Note

Refer to the code for this example placed at Code/Serverless-Architectures-with-Azure/Lesson 1/BeginningAzureServerlessArchitecture/PostTransactionsExA.cs. Go to https://goo.gl/iCt7dG to access the code.

4. Use Postman to send the request:

5. You are now able to use standard Visual Studio debugging features and inspect the different objects as shown in the following screenshot:

6. Set your verb to POST , and add a message in the payload. See if you can find the verb in the HttpRequestMessage object in debug mode. It should be in the method property.

Note

If you need to download Azure-functions-core-tools separately, you can use npm command to download it—npm install -g azure-functions-core-tools for version 1 (fully supported) and npm install -g azure-functions-core-tools@core for version 2 (beta). We will go into the differences in versions later in this chapter. You can then use the debug setup to set Visual Studio to call an external program with the command func host start when you click on the Debug button.

Outcome

You have debugged an Azure Function and tested it using Postman.

As you can see from running the function locally, you, the developer, do not need to write any of the usual boilerplate code for message handling or routing. You don't even need to use ASP.NET controllers, or set up middleware. The Azure Functions container handles absolutely everything, leaving your code to simply do the business logic.

In this activity, we will add a JSON payload to the request and write code to parse that message into a C# object.

Prerequisites

You will require a function created from the HTTP trigger with the parameters template.

Scenario

You are creating the start of a personal finance application that allows users to add their own transactions, integrate with other applications and perhaps allow their credit card to directly log transactions. It will be able to scale elastically to any number of users, saving us money when we don't have any users.

Aim

Parse a JSON payload into a C# object, starting your RESTful API.

Steps for Completion

{
  Amount: 47.32,
  ExecutionTime: "2018-01-01T09:00:00Z"
} 

Outcome

You have learned how to access the HttpRequestMessage, and you will have a function that can read a JSON message and turn it into a C# object. During this subtopic, you debugged an Azure Function. Visual Studio only allows this through downloading azure-functions-core-tools. Unfortunately, it doesn't make it available on the general command line—only through command windows started in Visual Studio. If you want to use it independently, then you have to download it using npm. If you need to download azure-functions-core-tools separately, you can use npm to get it—npm install -g azure-functions-core-tools for version 1 (fully supported) and npm install -g azure-functions-core-tools@core for version 2 (beta). We will go into the differences in versions later in this chapter. You can then use the debug setup to set Visual Studio to call an external program with the command func host start when you click on the Debug button.

This package is a lot more than just a debug environment, however; it actually has a CLI for everything you could possibly need in Azure Function development. Open up a command window (in Visual Studio, if you haven't downloaded it independently) and type func help; you should see a full list of everything the CLI can do. Notable commands are func host start, which starts the local debug environment, and func azure {functionappname} fetch-app-settings, which lets you download the app settings of a function deployed to Azure so that you can test integration locally, as well. These need to be run in the same folder as the host.json file.

An Azure Function is obviously geared towards being hosted on the Azure cloud, rather than locally or on your own computer. Visual Studio comes with a complete suite of tools to deploy and manage Azure services, and this includes full support for Azure Functions. The azure-functions-core-tools CLI that you downloaded to provide a local debug environment also has a set of tools for interacting with Azure Functions in the cloud, if you prefer CLIs. We will focus on using Visual Studio, but we will mention some of the equivalent methods in the CLI.

In this section, we'll deploy our first function to the public cloud, and learn how to call it. We'll be going live with our Azure Function, starting to create our serverless architecture. And to ensure that it happens correctly, we'll need a function project and a valid Azure subscription. Let's begin by implementing the following steps:

Outcome

You now have a fully deployed and working Azure Function in the cloud.

Anyone can execute your function if they can work out the address, which is why the security we discussed previously is a good idea to implement. We will further discuss the optimal way to employ security for a large enterprise using Azure Active Directory in the next chapter.

The old way of deploying Azure Functions allowed you to edit the C# code in the portal, but all of those sections will come up as read-only. For proper development, you should rarely even interact with the portal; everything is possible in Visual Studio with the Cloud Explorer.

The containers that Azure Functions run in are inherently short-lived, with a maximum execution time of 10 minutes allowed (this was set in host.json, as seen earlier), but it is generally advisable to execute HTTP requests in two minutes. This short timeframe is part of what allows for the flexibility of Azure Functions, so if you need longer execution times but still want most of the convenience of serverless computing, then look at using Azure WebJobs SDK, running on a VM or physical  machine that you control, or Azure Data Lake Analytics, if you are processing large datasets.

The resources that Azure allocates to functions is set at the Function App level, split equally among functions inside that app. Most of the time, this will have absolutely no practical impact on your work, and generally, you should keep logically connected functions in the same app. However, in cases where you suddenly demand massive scaling for one of your functions but not for the others, this can cause issues. If your suddenly popular function is one of twenty in an app, it's going to take longer to allocate enough resources to supply it. On the other hand, if you have a seldom-used function that you need better latency from, consider adding it to the Function App of a commonly-used one, so that the function doesn't have to warm up from the cold.

Prerequisites

You will need Visual Studio installed, with Azure development workload.

Scenario

Creating a personalized application for users.

Aim

Create a function that stores user details.

Steps for Completion

Outcome

You have a function ready to store user details.