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.

Note

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:

Note

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

   Note

   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.