Search icon CANCEL
Subscription
0
Cart icon
Your Cart (0 item)
Close icon
You have no products in your basket yet
Save more on your purchases now! discount-offer-chevron-icon
Savings automatically calculated. No voucher code required
Arrow left icon
All Products
Best Sellers
New Releases
Books
Videos
Audiobooks
Learning Hub
Newsletters
Free Learning
Arrow right icon
Beginning Serverless Architectures with Microsoft Azure
Beginning Serverless Architectures with Microsoft Azure

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

Arrow left icon
Profile Icon Daniel Bass
Arrow right icon
zł54.99
Book Jul 2018 100 pages 1st Edition
eBook
zł54.99
Print
zł68.99
Subscription
Free Trial
Arrow left icon
Profile Icon Daniel Bass
Arrow right icon
zł54.99
Book Jul 2018 100 pages 1st Edition
eBook
zł54.99
Print
zł68.99
Subscription
Free Trial
eBook
zł54.99
Print
zł68.99
Subscription
Free Trial

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
Table of content icon View table of contents Preview book icon Preview Book

Beginning Serverless Architectures with Microsoft Azure

Introduction to Azure Functions

Serverless programming has been a buzzword in technology for a while now, first implemented for arbitrary code by Amazon on Amazon Web Services (AWS) in 2014, and first spoken about two years before that. The term normally refers to snippets of backend code running in environments that are wholly managed by the cloud provider, totally invisible to developers. This approach has some astounding benefits, enabling an entirely new paradigm of computing architecture. Now, let's understand the benefits and drawbacks of serverless computing.

Following are the benefits of serverless computing:

  • Speed of development
  • Zero management (near)
  • Cost/cost flexibility
  • Auto-scaling

Following are the drawbacks of serverless computing:

  • Warmup latency
  • Vendor lock-in
  • Lack of control for specific use cases

Serverless code can be scaled to handle as much demand as your cloud provider's data center can handle—it is essentially infinite for all but the most demanding applications. However, the real key is elastic, unmanaged scaling. Rather than having to manually set the scale at which your code is running (for example, by spinning up extra virtual machines), serverless code will react to the demand, and scale appropriately. This means that you are charged according to computing resource usage, rather than paying in advance for a scale that you might need for an expected spike of users. It also means that serverless code needs no active management whatsoever—only monitoring. This has some profound impacts, and leads to an architecture that tends toward the microservices approach.

We will introduce this new architecture from the bottom up, starting by creating serverless code, and then building a serverless application. Our first objective will be to create a simple RESTful API with serverless code, before venturing into more interesting and unusual architectures that are unique to serverless code. This book will focus on Microsoft's serverless product Azure Functions.

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

  • Identify the benefits and drawbacks of serverless computing
  • Create an Azure Function
  • Debug an Azure Function locally
  • Deploy an Azure Function
  • Explain the Azure Functions runtime

Understanding the Real Benefits of Serverless Computing

While serverless computing has a compelling set of benefits, it is no silver bullet. To architect effective solutions, you need to be aware of its strengths and weaknesses, which are shown in the following table:

Benefits

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

Speed of Development

Firstly, a major strength of serverless computing is its speed of development. The developer doesn't have to concern oneself with, or write any of the code for, the underlying architecture. The process of listening for HTTP messages (or other data inputs/events) and routing is done entirely by the cloud provider, with only some configuration provided by the developer. This allows a developer to simply write code that implements business logic, and deploy it straight to Azure. Each function can then be tested independently.

Automatic Scaling

Secondly, serverless computing has automatic scaling by default. The routing system in a serverless service like Azure Functions will detect how many requests are coming in and deploy the serverless code to more servers when necessary. It will also reduce the number of servers all the way down to zero, if necessary. This is particularly useful if you are running an advertisement or a publicity stunt of some kind—half-time advertisements in the Premier League final, for example. Your backend can instantly scale to handle the massive influx of new users for this brief period of time, before returning to normal very quickly. It's also useful for separating out what would usually be a large, monolithic backend. Some of the parts of the backend will probably be used a lot more than others, but usually, you have to scale the whole thing manually to keep the most-utilized functions responsive. If each function is separated, automatically scaling it allows the developer to identify and optimize the most-used functions.

Flexible Costs

Continuing on the subject of being able to scale down to zero servers, the cost of serverless code is very flexible. Due to auto-scaling, providers are able to charge according to resource usage. This means that you only pay according to usage, which has benefits for all developers, but for small businesses most of all. If your business has lots of customers one month, you can scale accordingly and pay your higher bill with the higher revenue you have made. If you have a quieter month, your serverless computing bill will be proportionally lower for that lower revenue period.

Reduced Management Overhead

Finally, serverless code requires very little active management. An application running on a shared server will usually require a significant amount of monitoring and management, for both the server itself and its resource allocation at any given moment. Containerized code, or code running on virtual machines, is better, but still requires either container management software or a person to monitor the usage and then scale down or scale up appropriately, even if the server itself no longer requires active management. Serverless code has no server visible to the developer and will scale according to demand, meaning that it requires monitoring only for exceptions or security issues, with no real active management to keep a normal service running.

Drawbacks

Serverless code does have some weaknesses which are described here.

Warmup Latency

The first weakness is warmup latency. Although the traffic managers of various platforms (AWS, Azure, Google Cloud, and so on) are very good at responding to demand when there are already instances of serverless code running, it's a very different problem when there are no instances running at all. The traffic managers need to detect the message, allocate a server, and deploy the code to it before running it. This is necessarily slower than having a constantly running container or server. One way to combat this is to keep your code small and simple, as the biggest slowdown in this process can be transferring large code files.

Vendor Lock-in

Secondly, there is the issue of vendor lock-in. Each cloud provider implements its serverless service differently, so serverless code written for Azure is difficult to port over to AWS. If prices spike heavily in the future, then you will be locked in to that provider for your serverless architecture.

There's also the issue of languages. JavaScript is the only language that is universally available, with patchy service across providers for other languages, like C# and Java. There is a solution to this, however; it is called the serverless framework. This is a framework that you can use to write simple HTTP-triggered functions, which can then be deployed to all of the major cloud providers. Unfortunately, this means that you will miss out on a lot of the best features of Azure Functions, because their real power comes from deep integration with other Azure services.

Lack of Low-Level Control

Finally, there is the issue of a lack of low-level control. If you are writing a low latency trading platform, then you may be used to accessing networking ports directly, manually allocating memory, and executing some commands using processor-specific code. Your own application might require similar low-level access, and this isn't possible in serverless computing. One thing to bear in mind, however, is that it's possible to have part of the application running on a server that you have low-level access to, and background parts of it running in a serverless function.

If an Azure Function isn't executed for a while, the function stops being deployed and the server gets reallocated to other work. When the next request comes in the function needs to deploy the code, warm up the server and execute the code, so it's slower. Inevitably, this leads to latency when the functions are triggered again, making serverless computing somewhat unsuitable for use cases that demand continuous low-latency. Also, by its very nature, serverless computing prevents you from accessing low level commands and the performance benefits that they can give. It's important to emphasize that this doesn't mean serverless computing is unbearably slow; it just means that applications that demand the utmost performance are unlikely to be suitable for serverless computing.

Overall, there is a clear benefit to using serverless computing, and particularly, Azure Serverless, especially if you use some of the tips detailed in the weaknesses section. The benefits are strong for both the developer and the business.

The serverless framework (https://serverless.com/) can help with vendor lock-in by making your serverless functions cross-cloud.

Creating, Debugging, and Deploying an Azure Function

In this section, we will create an Azure Function in Visual Studio, debug it locally, and deploy it to an Azure cloud instance. While doing this, we will cover material about the basics of serverless runtime and the high-level benefits and disadvantages of serverless computing.

The core of all serverless products is to get straight into development with minimal setup time, so that's what we'll do in this subtopic. You should have a serverless function in the cloud at the end of this topic, and once you've learned the ropes, you could create and deploy one in a few minutes.

To develop Azure Functions for production, you need a computer running Windows and Visual Studio 2015 or later; however, the smoothest experience is present on Visual Studio 2017, version 15.4 or later. If your computer can run Visual Studio, it can handle Azure Function development.

An Azure Function can be written in several languages. At the time of writing, there are three languages with full support: C#, JavaScript, and F#. Generally, the most popular languages are C# and JavaScript. Java is a language in preview, but, being in preview, it is not ready for production yet, so it will not be covered.

There are also lots of other languages available experimentally for Azure Function runtime version 1 (Python, PowerShell, and so on), but it is not advised to use these for your business architecture, and they will generally fall behind the curve for new features and support. There is also a version 2 of the runtime, but this is only in preview at the time of writing, and is therefore not ready for production.

It's interesting to note that Azure Data Lake and Azure Data Lake Analytics could be considered serverless programming, too. These are designed for processing very large datasets using a new language, U-SQL. You can read about them at https://docs.microsoft.com/en-us/azure/data-lake-analytics/data-lake-analytics-overview.

Visual Studio 2017 has a comprehensive suite of Azure tools, including Azure Function development. While it's possible to use a combination of any other IDE and the command-line interface to develop Azure Functions, the best tooling will always arrive on Visual Studio first.

Creating Your First Function to Receive and Process Data from an HTTP Request

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:

  1. Open the Visual Studio Installer, which will show you the version of Visual Studio that you have installed and allow you to select the Azure Workflow and install it, if it is missing, then update Visual Studio, if required, to latest version:
  1. Click on Modify, select the Azure development workload, and click on Modify again:

Refer to the complete code placed at Code/Serverless-Architectures-with-Azure/Lesson1/BeginningAzureServerlessArchitecture/BeginningAzureServerlessArchitecture.csproj.

Go to https://goo.gl/3gNQP4 to access the code.

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:

  1. Create a new solution. The example is called BeginningAzureServerlessArchitecture, which is a logical wrapper for several functions that will get deployed to that namespace.
  2. Use the Visual C# | Cloud | Azure Function template. Select the Empty trigger type and leave the default options, but set storage to None. This will create a Function App, which is a logical wrapper for several functions that will get deployed and scaled together:
  1. You now have a solution with two files in it: host.json and local.settings.json. The local.settings.json file is used solely for local development, where it stores all of the details on connections to other Azure services.
When uploading something to a public repository, be very careful not to commit unencrypted connection settings—by default, they will be unencrypted. host.json is the only file required to configure any functions running as part of your Function App. This file can have settings that control the function timeout, security settings for every function, and a lot more.

  1. Now, right-click on the project and select Add New Item. Once again, choose the Azure Function template:
  1. On the next screen, select Http trigger with parameters and Access rights should be set to Anonymous. Right-click on your solution and select Enable NuGet Package Restore:
An important thing to remember is that this template is different from the first one you used, because it is inside the solution. Call it PostTransactions, or something similar.

  1. You will now have a C# file called PostTransactions.cs. It consists of a single method, Run, with an awful lot in the method signature: an attribute and an annotation. Some of this will be familiar to you if you are an experienced C# developer, and it is important to understand this signature.
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.

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:

Authorization level
Required information
Anonymous
No key required; anyone with the path can call it an unlimited number of times.
User
Need a valid token, generated by a user that has AD permission to trigger the Function App. Useful for high-security environments, where each service needs to manage its own security. Generally, token-based authentication is much more desirable than key-based.
Function
Need the function key—a unique key created for each function in a Function App upon deployment. Any host key will also work. The most common form of authorization for basic deployments.
System
Need the master key—a key at the Function App level (called a host key) that cannot be deleted, but can be renewed.
Admin
Need any host key.

One thing to bear in mind is that if you set a function to be high security and use System or Admin authorization, then any client that you give that key to will also be able to access any other functions in the Function App (if they can work out the path). Make sure that you separate high-security functions into different apps. An improved approach is discussed in the next chapter—using Azure Active Directory.

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.

Debugging an Azure Function

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:

It will bootstrap the environment and attach the debugger from Visual Studio. It will then list the endpoints the Function App is listening on.
  1. Open up Postman app and copy and paste the endpoint into it, selecting either a POST or GET verb.
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/.

  1. Create a debug point in the Run method by clicking in the margin to the left of the code:
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.
  1. Use Postman to send the request:
  1. You are now able to use standard Visual Studio debugging features and inspect the different objects as shown in the following screenshot:

  1. 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.
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.

Activity: Improving Your Function

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

  1. Change the Route to transactions.
  2. Remove the get verb. Remove the String parameter called name:
  1. Add the Newtonsoft.json package, if it isn't already present. You can do this by right-clicking the Solution | Manage NuGet packages | Browse | Newtonsoft.Json.

Version 10.0.3 is used for this book.
  1. Right-click on the project and add a folder called Models, then add a C# class called Transaction. Add two properties to this class: a DateTime property called ExecutionTime, and a Decimal property called Amount:
Refer to the complete code placed at Code/Serverless-Architectures-with-Azure/Lesson 1/BeginningAzureServerlessArchitecture/Models/Transaction.cs.

Go to https://goo.gl/H6cu2M to access the code.

  1. Use JsonConvert.DeserializeObject<Transaction>(message).Result() to deserialize the HttpRequestMessage into an instantiation of this class. To do that, you need to import the Models namespace and Newtonsoft.Json. This will parse the JSON payload and use the Amount property to file the corresponding property on the Transaction object:
Refer to the complete code placed at Code/Serverless-Architectures-with-Azure/Lesson 1/BeginningAzureServerlessArchitecture/PostTransactionsExC.cs.

Go to https://goo.gl/ttyvpT to access the code.

  1. Change the return message to use a property of the new Transaction object, for example, You entered a transaction of £47.32! Go to Postman and open the Body tab and select raw.
  1. Enter in the following JSON object:
{
Amount: 47.32,
ExecutionTime: "2018-01-01T09:00:00Z"
}
  1. Run locally to test. Make sure you change the endpoint to /transactions in Postman.

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.

Developing in Visual Studio is much easier for Azure Functions, especially if it is your usual IDE, but it's perfectly possible to use a simple text editor and the CLI to develop. If you are developing for version 2 on a Mac or Linux machine, this setup is basically the only way to develop at the moment, although Visual Studio Code has a good Azure Functions extension.

Deploying an Azure Function

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.

It is possible to run Azure Functions on your own servers, using the Azure Functions runtime. This is a good way to utilize the sunk cost that you have already spent on servers, combined with the unlimited scale that Azure offers (if demand exceeds your server capacity). It's probably only worth it in terms of cost if you have a significant amount of unused Windows server time, because this solution inevitably requires more management than normal Azure Function deployments.

To deploy to Azure, you will need an Azure login with a valid Azure subscription.

Deploying to Azure

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:

  1. Right-click on your project and select Publish.... Now select Azure Function App | Create New as shown in the following screenshot:
If you've signed in to Visual Studio with a Microsoft ID that has an Azure subscription associated with it, then the next screen will be pre-populated with a subscription. If not, then you need to sign in to an account with an associated Azure subscription.
  1. Enter a memorable name and create a resource group and a consumption app service plan to match the following:
  1. Click on the Publish button to publish your function.
  2. Open a browser, navigate to http://portal.azure.com, and find your function. You can use the search bar and search the name of your function. Click on your Function App, then click on the function name. Click the Get function URL in the upper-right corner paste the address of your function into Postman, and test it. Please bear in mind that if you have a paid subscription, these executions will cost a small amount of money—you are only charged for the compute resources that you actually use. On a free account, you get a million executions for free.

Outcome

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

This is not the recommended way to deploy to production. Azure Resource Manager (ARM) templates are the recommended way to deploy to production. ARM templates are JavaScript Object Notation (JSON) files. The resources that you want to deploy are declaratively described within JSON. An ARM template is idempotent, which means it can be run as many times as required, and the output will be the same each and every time. Azure handles the execution and targets the changes that need to be run.

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.

You can remote debug Azure Functions using the Cloud Explorer. Click View Menu | Cloud Explorer and log in to your Azure account. Find your function under App Services. Select the function in the Cloud Explorer, and click Attach Debugger.

Technical Basis of Azure Functions

So, we successfully created an Azure Function, ran it on a local environment, and deployed it to the cloud.

Azure Functions run on servers that have Azure WebJobs installed on them. Azure WebJobs allow DLLs, or any supported code, to be hot-swapped in and take advantage of deep Azure integrations.

We'll cover the two runtimes in more depth now, but the key takeaway is that there is a fully-supported, Windows-based version, and also a beta cross-platform version. Microsoft are pushing towards the cross-platform version.

Version 1 is based on Azure WebJobs, which is written in C# and .NET. Azure WebJobs is essentially a service with a set of adapters for Azure products. These adapters usually go a lot deeper than a standard API. When code is deployed into it, Azure WebJobs reads host.json to create an environment with the same context every time. When you downloaded azure-functions-core-tools, it contained a full production Azure Functions environment, exactly the same as the ones used in Azure. That is why we can only develop on Windows machines for version 1.

Version 2 is based on the new Azure WebJobs, written in C# and .NET Core. It can run on any server that supports .NET Core, which includes all major distributions of Linux, as well as Windows.

.NET Core is significantly faster than .NET and can run on any platform, allowing Microsoft to allocate more types of servers to Azure Functions work.

Rewriting Azure WebJobs in .NET Core will remove support for the plethora of semi-supported, experimental languages, like Python and PowerShell, but will add Java support.

Executing and Scaling Azure Functions

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.

Activity: Creating a Function That Stores User Detail

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

  1. Create a new function, called PostUser, using the HttpTrigger template. If you are competent in another language, like JavaScript or F#, you can try creating it in that language.
  2. Create a new model called User. Think about what properties you'd like to include, but as a minimum, you will need an email address and a unique identifier (these can be the same property).
  3. Modify the function to decode a JSON-formatted request into this model.

Outcome

You have a function ready to store user details.


Refer to the complete code placed at Code/Serverless-Architectureswith-Azure/Lesson 3/BeginningAzureServerlessArchitecture/Models/.

Before the transactions have taken place: User.cs: https://goo.gl/9FpHce.

After the transactions have taken place: PostUsers.cs: https://goo.gl/CWxA2S.

Summary

In this chapter, you covered the benefits and disadvantages of serverless computing. Next, you learned how to create, debug, and deploy an Azure Function, Azure's primary serverless product. This is the basic building block of serverless applications, and the first step to creating fully serverless architectures. Finally, you learned about the technical basis of Azure Functions, and how you can utilize your knowledge of it to improve the performance of your functions.

In the next chapter, we will be covering integrations with other Azure services and Azure-based logging and security solutions.

Left arrow icon Right arrow icon

Key benefits

  • Provides information on integration of Azure products
  • Plan and implement your own serverless backend to meet tried-and-true development standards
  • Includes step-by-step instructions to help you navigate advanced concepts and application integrations

Description

Many businesses are rapidly adopting a microservices-first approach to development, driven by the availability of new commercial services like Azure Functions and AWS Lambda. In this book, we’ll show you how to quickly get up and running with your own serverless development on Microsoft Azure. We start by working through a single function, and work towards integration with other Azure services like App Insights and Cosmos DB to handle common user requirements like analytics and highly performant distributed storage. We finish up by providing you with the context you need to get started on a larger project of your own choosing, leaving you equipped with everything you need to migrate to a cloud-first serverless solution.

What you will learn

  • Identify the key advantages and disadvantages of serverless development
  • Build a fully-functioning serverless application and utilize a wide variety of Azure services
  • Create, deploy, and manage your own Azure Functions in the cloud
  • Implement core design principles for writing effective serverless code

Product Details

Country selected
Publication date, Length, Edition, Language, ISBN-13
Publication date : Jul 25, 2018
Length 100 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781789537048
Vendor :
Microsoft
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

Product Details

Publication date : Jul 25, 2018
Length 100 pages
Edition : 1st Edition
Language : English
ISBN-13 : 9781789537048
Vendor :
Microsoft
Concepts :

Packt Subscriptions

See our plans and pricing
Modal Close icon
$19.99 billed monthly
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Simple pricing, no contract
$199.99 billed annually
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just zł20 each
Feature tick icon Exclusive print discounts
$279.99 billed in 18 months
Feature tick icon Unlimited access to Packt's library of 7,000+ practical books and videos
Feature tick icon Constantly refreshed with 50+ new titles a month
Feature tick icon Exclusive Early access to books as they're written
Feature tick icon Solve problems while you work with advanced search and reference features
Feature tick icon Offline reading on the mobile app
Feature tick icon Choose a DRM-free eBook or Video every month to keep
Feature tick icon PLUS own as many other DRM-free eBooks or Videos as you like for just zł20 each
Feature tick icon Exclusive print discounts

Frequently bought together

Stars icon
Total 174.97 391.97 217.00 saved
Cloud Native Architectures
zł59.99 zł158.99
Professional Azure SQL Database Administration
zł59.99 zł177.99
Beginning Serverless Architectures with Microsoft Azure
zł54.99
=
Book stack Total 174.97 391.97 217.00 saved Stars icon

Table of Contents

5 Chapters
Preface Chevron down icon Chevron up icon
1. Introduction to Azure Functions Chevron down icon Chevron up icon
2. Deploying Azure Serverless Chevron down icon Chevron up icon
3. Architecting Serverless Solutions Chevron down icon Chevron up icon
4. Other Books You May Enjoy Chevron down icon Chevron up icon
Get free access to Packt library with over 7500+ books and video courses for 7 days!
Start Free Trial

FAQs

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 www.packtpub.com/support 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 www.packtpub.com/account
  • To contact us directly if a problem is not resolved, use www.packtpub.com/contact-us
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.