Azure App Service and Web Apps

In this chapter, we take a look at the Azure App Service, consisting of Web Apps, Logic Apps, Mobile Apps, API Apps, and Function Apps. We focus on Web Apps and how they work together with the App Service. We create a web app and publish it to Azure. We also look at the options for prebuilt web apps offered by Azure.

App Service and App Service plans

Before we talk about Web Apps, let's talk about App Service and the App Service plans.

What is an App Service?

The App Service is a service that hosts one of five kinds of applications:

  • Web Apps
  • Mobile Apps
  • Logic Apps
  • API Apps
  • Function Apps

Each app runs in its own app service. When you look in the Azure portal to see your website, you will look for the app service in which it is running. It conveniently has the same name as the app it's hosting.

So what is an App Service plan?

An App Service plan defines the capacity and resources to be shared among one or more app services that are assigned to that plan.

The following are some of the criteria you can define when creating an App Service plan.

  • Location (such as West US)
  • Instance count
  • Pricing tier (such as Free, Standard, or Premium) providing distinct settings for a variety of performance and service capabilities:
  • Number of cores or instance size
  • Amount of memory
  • Amount of storage
  • Maximum number of instances
  • Autoscaling options (depends on tier—automatic, manual, or none)

When you deploy your app service for the first time, you specify which App Service plan you want to use. At deployment time, you can select an App Service plan you have created or create a new App Service plan.

How does this help you?

With infrastructure as a service (IaaS), you can create your own virtual machines (VMs), deploy your apps to them, and deal with the IIS setup and application pools and so on. Then, every time you change an app, you have to deploy it to all the VMs again. If you scale it out, and you have four VMs or eight VMs, it just becomes more onerous. With IaaS, you are responsible for the continuing management of your service. Using App Service plans enables you to run multiple applications on one set of VMs, even if each of the applications is deployed separately.

For example, let's say you have five websites and three mobile apps that you want to host. You could run each one on its own VM, which would require 8 VMs. If you wanted redundancy (recommended), that would require 16 VMs. Even if you select small instances, the cost adds up really quickly. Plus, you have to scale each set of VMs separately.

If you could run those eight applications on the same set of two VMs, it would be more cost-effective and easier to manage. This is what using App Service plans does for you. You set up one App Service plan with a specific VM size, number of instances, etc. Then, you deploy the eight applications, specifying the same App Service plan for each one. This results in all eight applications running on that same set of two VMs. You can deploy and update each application as needed—you don't have to update them all at the same time.

When you create your App Service plan, the resources you requested are allocated for you. When you deploy an app to that App Service plan, it simply deploys the applications to those allocated resources.

If you decide you want to have four VMs instead of two, you simply go to the Azure portal and modify the App Service plan, changing the number of instances from two to four. It will create two more VMs and deploy your apps to them for you. If you are using small VMs and want to scale up to medium VMs, you can simply modify the Pricing Tier in the App Service plan, and it will scale up.

With web apps running in an app service using an App Service plan, the management is handled for you, and you can easily scale up and out just by changing the settings of the App Service plan.

How to create an App Service plan in the Azure portal

Now, I'll show you how to create an App Service plan using the Azure portal. Later, I'll show you how to create a web app and deploy it to an app service using that App Service plan.

Log in to the Azure portal

Click New, then click See All, as displayed in Figure 2-1.

Figure 2-1 Go to the Marketplace to search for a resource to add.

It opens the search screen for the Marketplace (Figure 2-2). Type app service plan in the search box and press Enter.

Figure 2-2 The input screen for searching the Marketplace.

Select App Service Plan in the search results, as shown in Figure 2-3.

Figure 2-3 The search results for App Service plan.

Click Create on the App Service Plan blade displayed in Figure 2-4.

Figure 2-4 Click Create to create a new App Service plan.

After you see something similar to the App Service Plan blade displayed in Figure 2-5, you can define the parameters for your App Service plan.

Figure 2-5 The fields to be filled in for your new App Service plan.

  • App Service Plan. This is what you would like to name your App Service plan. Make this something you can recognize when you want to use the plan later.
  • Subscription. If you have multiple Azure subscriptions administered by this account, this will have a drop-down list of subscriptions, and you can select which one to use.
  • Resource Group. Resource groups provide a logical container for a related set of resources. For example, you could put all of the resources you create for this book in the same resource group. When you're finished, you can delete the resource group, and it will deallocate and remove all of those resources for you. Let's create a new resource group for our App Service plan; later in this chapter, we will create a web app and assign it to our App Service plan. Leave the value as +New and specify the name of your new resource group. It's recommended that you specify something that indicates what the resources are used for.
  • Location. This is the Azure region where the resource group will be hosted. This includes metadata such as audit logs, where each resource in the group resides. This can be different from the resources themselves; this is important for those who care about where data is hosted—for example, those in countries with data sovereignty laws. Also, Resource Manager operations are sourced through this region, so you typically want it to be the same as most of the resources in the group. For our example, select the region closest to you.
  • Pricing Tier. Click this field to see your choices. The new blade (displayed in Figure 2-6) shows the recommended pricing plans. This is a subset of all of the available pricing tiers. If you want to see all of the plans, click View All on this blade. The pricing plan lets you specify the amount of storage, scalability, backup choices, and so on.

Figure 2-6 The Pricing Tier blade.

Select the S1 Standard pricing plan and then click Select at the bottom of the blade. Now, your App Service Plan blade should display the pricing plan you selected.

Select the check box on the bottom of the App Service Plan blade that says Pin To Dashboard.

This will pin a tile to the Dashboard showing your App Service plan, providing easy access to it. Now, click Create. It creates the plan and adds a tile to your Dashboard.

After the App Service plan is created, you can click the tile on the Dashboard and modify it. You can also see what apps are using that plan. After the web app is created and deployed, I'll show you how to scale the apps by scaling the App Service plan.

At this point, you can create one or more app services, such as a web app, and assign them to that App Service plan. They will all run on the same VMs.

Creating and deploying Web Apps

Now that you understand App Services and App Service plans, I'll show you what a Web App is, discuss some of its features, and then talk about the various options you have for creating one. Then, I'll show you how to use a couple of those options to create and deploy a Web App.

What is a Web App?

A Web App is a web application that is hosted in an App Service. The App Service is the managed service in Azure that enables you to deploy a web application and make it available to your customers on the Internet in a very short amount of time. As noted above, you don't directly support the VMs on which your web app runs; they are managed for you. In fact, you don't have access to those underlying VMs.

Supported languages include .NET, Java, PHP, Node.js, and Python. In addition to creating your own web app, there are several web applications available to use as a starting point, such as WordPress, Umbraco, Joomla!, and Drupal.

You can use continuous deployment with Team Foundation Server (TFS), GitHub, TeamCity, Jenkins, or BitBucket so that every time you commit a change, a new version of the web app is deployed.

Scaling is done by scaling the App Service plan to which the web app belongs. You can scale the number of instances in and out on demand. You can configure autoscaling so Azure will scale it in or out for you depending on specific performance measures such as CPU percentage. You can also publish your website to multiple locations and use the Azure Traffic Manager to handle the routing of the traffic to the location nearest to your customer.

For diagnostics, you can gather performance statistics, application logging, web server logging, IIS logs, and IIS Failed Request logs. If you're using Microsoft Visual Studio, you can even remotely debug your application while it is running in the cloud.

In short, there are many features available when using Web Apps to make it easy for you to deploy, manage, and troubleshoot a web application.

Options for creating Web Apps

There are multiple options for creating a Web App and deploying the content to an app service. Let's look at a few of these, including the following.

  • Azure Marketplace. This contains all of the resources you can deploy in Azure. I'll show you how you can use this to create Web Apps from preexisting templates such as WordPress.
  • Visual Studio Code. This is a free, open source, cross-platform code editor with debugging capabilities.
  • Visual Studio. This is Microsoft's full-featured development IDE.

Marketplace

There are many pre-created websites and templates in the Azure Marketplace that you can use. To see all of the options available, log into the Azure portal and click New > Web + Mobile > See All. This shows the Marketplace blade filtered for Web and Mobile apps, as displayed in Figure 2-7.

Figure 2-7 Options in the Azure Marketplace for Web and Mobile apps.

If you scroll down on the page, you can see the categories. At the end of any row, clicking More will show additional options in that category. Here are just a few of the choices available:

  • Web Apps: Web App, Web App + SQL, Web App + MySQL, WordPress, and Umbraco CMS
  • Blogs + CMSs: Joomla!, Drupal, DNN, Orchard CMS, Umbraco CMS, and MonoX
  • Starter Web Apps: ASP.NET, HTML5, Node.js, PHP, Apache Tomcat, and some examples like the Bakery web app and the Java Coffee Shop web app

Visual Studio Code

Visual Studio Code (VS Code) is a free, open source code editor with support for development operations such as debugging, task running, and version control. It runs on Windows, OS X, and Linux.

VS Code makes debugging easier, providing IntelliSense code completion and easy code refactoring. It integrates with Git and also package managers, repositories, and various build tools.

VS Code has built-in support for Node.js, JavaScript, and TypeScript. Using extensions, you can use VS Code to debug languages such as C#, C++, Python, Ruby, and PowerShell. There is also tooling for web technologies such as HTML, CSS, JSON, and Markdown.

Using the Azure portal, you can set your web app to get the source code from OneDrive, Dropbox, or a local code repository such as GitHub or Visual Studio Team Service. If you enable continuous deployment for your WebApp, updates will be published automatically when changes are made to your source repository.

You can download Visual Studio Code for Windows, Linux, or Mac here: https://code.visualstudio.com/#alt-downloads.

Visual Studio

Visual Studio is a full development environment, giving you the ability to create many different kinds of applications including, but not limited to, ASP.NET MVC applications, .NET client applications, Windows Communication Foundation (WCF) services, Web APIs, and Cloud Services, using languages such as C#, C++, VB, F#, and XAML.

With Visual Studio, you can create a new web application and publish it to an app service in Azure. I'll show you how to do this in an upcoming demo.

Demo: Create a web app by using the Azure Marketplace

Let's take a look at how to create a web app from one of the templates available in the Azure Marketplace.

Log into the Azure portal. As seen in Figure 2-8, click New on the left side of the page, then click     See All.

Figure 2-8 Go to the Marketplace Search blade.

This brings up the search screen for the Marketplace. All resources that can be deployed to Azure are listed in the Marketplace, including virtual machines, virtual networks, storage accounts, web apps, and so on. As shown in Figure 2-9, type in WordPress and press Enter to perform the search.

Figure 2-9 Search for WordPress.

You see a list of matches, as displayed in Figure 2-10.

Figure 2-10 The search results for WordPress.

Select the row with WordPress from publisher WordPress. This shows you the blade for WordPress; click Create at the bottom to create a WordPress site. You now see a blade where you can start configuring your WordPress site, as displayed in Figure 2-11.

Figure 2-11 Create a WordPress website.

Now, start filling in the fields on this blade:

  • App Name. This is used to create the URL to access your web app.
  • Subscription. If the account you are using is associated with multiple subscriptions, select the subscription you want to use.
  • Resource Group. This is a way of grouping multiple resources that are related to one another, such as a web app and a database. Select the resource group you used for the App Service plan you created earlier.
  • App Service Plan. Select the App Service plan you created earlier in this chapter.

Click Database to see the database settings, as shown in Figure 2-12. WordPress uses MySQL by default. Set your Database Name and Type (Shared or Dedicated). For Location, select the same region in which your app is going to run. Click Pricing Tier and select the least expensive, which at this time is Mercury. Click OK to save the database settings.

Figure 2-12 Specify database settings.

Back on the WordPress Settings blade for your new website, click Legal Terms. If you agree with the Legal Terms, click OK at the bottom of that screen, which will set Legal Terms to Accepted.

You can use Web App Settings (Optional) to set the WordPress-specific settings shown in Figure 2-13; this is optional.

Figure 2-13 Fill in App Settings (optional).

Back on the WordPress blade, select the check box to pin the web app to your Dashboard, then click Create. Azure will create the WordPress site for you.

After Azure has finished publishing the web app, click the tile on your Dashboard to open its properties, as displayed in Figure 2-14. To open the site, click the URL. You are prompted for the rest of the details needed to create your WordPress site, such as language, site title, username, password, and email address. After all the fields are filled in, click the Install WordPress button. After the WordPress installation is finished, you're ready to go.

Figure 2-14 Open your new WordPress site by clicking its URL.

Note When your web app is created, Azure also creates an Application Insights instance. Application Insights is an analytics service that monitors your live application. It can help you resolve performance issues and understand how your application is used. Application Insights is outside the scope of this book. For more information, check out the Getting Started article about Application Insights: https://azure.microsoft.com/documentation/articles/app-insights-overview/.

You can see the Application Insights instances in the All Resources blade; it will have the same name as your web app, but it will be a different resource type. My list of resources is displayed in Figure 2-15; the ones with the rectangle around them are the Application Insights instances. Note that they have a different icon from the Web Apps. Simply select those Application Insights resources and delete them. (When you select that resource, it will open a bunch of blades. Just close them until you get back to the first one, and select Delete from that blade.)

Figure 2. The Application Insights instances are created automatically when you create a web app.

Demo: Create an ASP.NET website in Visual Studio and deploy it as a web app

To perform this tutorial, you must have Visual Studio 2013 or Visual Studio 2015 installed and the most recent version of the Azure Tools and SDK.

Create a new web application with Visual Studio by following these steps:

Open Visual Studio. Select File > New > Project.

Select ASP.NET Web Application; the dialog box for creating a project appears, as shown in Figure 2-16. On the right side of the dialog box, clear the Add Application Insights To Project check box. This will prevent the creation of a separate Application Insights instance for this web application.

Figure 2-16 Create an ASP.NET Web Application; deselect Application Insights.

Specify the Name of the application and the Location for the solution, then click OK.

When prompted to select the type of ASP.NET application to create, select MVC from the list of ASP.NET Templates, as shown in Figure 2-17. Clear the Host In The Cloud check box. You will set that up separately. Click OK to continue.

Figure 2-17 Select an MVC application and clear the Host In The Cloud check box.

Visual Studio will create a basic ASP.NET MVC application that runs "as is." You can modify it later to make it your own.

Now, publish this web application to an App Service in Azure and assign it to the App Service plan created earlier in this chapter. You will create the App Service when you publish the web app the first time. Right-click the website and select Publish (Figure 2-18).

Figure 2-18 Step 1 for publishing the web application.

The Publish Web dialog box will be displayed. Select the Microsoft Azure App Service (Figure 219).

Figure 2-19 Select the Microsoft Azure App Service for the publish target.

You will be prompted for your subscription name. You may be prompted again to enter the credentials for your Azure subscription. If the correct account is not displayed, click it to show a drop-down list and add an account if necessary. When the correct account is selected, select the Subscription and be sure the View is set to Resource Group. Open the Resource Group, and you will see the resources that have been set up already. In Figure 2-20, you can see the web apps that I have already created. To publish this application to a new web app, click New.

Figure 2-20 Make sure the right account and subscription are selected; show the resources by group.

The Create App Service dialog box (Figure 2-21) appears next. Remember that an App Service is simply the host for a Web App, Mobile App, Logic App, API App, or Function App. You'll create a new App Service to host your MVC web application here.

Figure 2-21 Create an App Service to host the MVC application.

  • Set the Web App Name. This will be used for the URL for the web app, so select it wisely.
  • Select the Subscription.
  • Select the Resource Group. If you use the one you created at the beginning of this chapter, then when you're done, you can delete that Resource Group and all of your resources will be removed.
  • Last, select the App Service plan that you created earlier in this chapter. This application will be hosted on the same VMs as the other web app(s) you have placed in that plan.
  • Click Create to create the App Service.

If you look in the Azure portal now, you will see your App Service has been created.

Now let's use Web Deploy to publish our web app to our app service. After creating the app service, the Publish Web dialog box will be displayed (Figure 2-22). You can use the default values.

Figure 2-22 Publish settings for the MVC application.

Click Validate Connection to make sure the information is correct. After it validates, click Next to go to the next dialog box (Figure 2-23).

Figure 2-23 Settings used when publishing the MVC application.

This dialog box lets you set the Configuration to Debug or Release and provide a connection string to a database if needed. Note that if you are going to use remote debugging on your web app, you will want to select the Debug configuration. Click Next to reach the final page (Figure 224).

Figure 2-24 Publish the MVC application.

You can preview your site here. When you're finished, click Publish to deploy the web application to the App Service. It will open your web application in the default browser after it is published.

When you make changes to your website, you can go through this same process to publish the website again. Note that it will only publish the files that have been added or modified.

Configuring, scaling, and monitoring Web Apps

Now that you've created a web app, assigned it to an App Service plan, and deployed it, let's take a look at the configuration in the portal and how to scale your web application.

Configuring Web Apps

Log into the Azure portal and go to the web application you created and deployed from Visual Studio earlier. The primary blade should look like Figure 2-25.

Figure 2-25 Web App blade.

The Essentials section

Let's start with the icons across the top of the Web App blade and look at what they are used for.

  • Settings. This opens a new blade called Settings. This displays by default when you first open the Web App blade, and is the same blade you see when you click All Settings.
  • Tools. This opens the Tools blade, which provides access to Performance testing, Process Explorer, Performance monitoring, and so on. It also provides access to the Kudu console, which is helpful for troubleshooting and analysis.
  • Browse. This opens your web app in your default browser.
  • Stop/Start. This option starts and stops the web app.
  • Swap. This option swaps the versions deployed to two different deployment slots. For example, if you have a production slot and a staging slot, you can publish your web app to staging and test it. When you're satisfied with it, you can promote it to production by using the Swap option. When you're sure everything is working okay, you can remove the staging version.
  • Restart. This restarts your web app.
  • Delete. This removes the web app.
  • Get Publish Profile. This retrieves the information needed to publish a web app from Visual Studio.
  • Reset Publish Profile. This resets the publishing credentials and invalidates the old credentials. These credentials are used for FTP and Git access.

In the Essentials area, it shows the settings provided when creating the web app: the Resource Group, Location, Azure Subscription ID, the URL of the website, and the name of the App Service plan being used. It also shows the credentials for FTP'ing into the web app in case you want to deploy new files via FTP.

Click Settings to open the Settings blade. Let's take a closer look at some of the options on this blade.

The Settings blade: General

Figure 2-26 shows the General section of the Settings blade.

Figure 2-26 General section on the web app's Settings blade.

Let's take a look at the General settings we can configure on this blade.

  • Quick Start. This brings up some resources you can use to learn more about Web Apps. There are links to install Visual Studio and the Microsoft Azure SDK, links to reset your deployment credentials, and links to tutorials, forums, samples, etc.
  • Properties. This shows some of the same values that are in the Essentials blade: the URL, the mode (Standard), the outbound IP addresses, the FTP settings, and so on.
  • Application Settings. These are values that apply to your web app.

The top of the Application Settings blade shown in Figure 2-27 lets you set things like the .NET Framework version, PHP version, etc.

Figure 2-27 Application Settings blade for the web app.

Let's look at what some of these settings are used for:

  • .NET Framework Version. If your web app is a .NET application, this will denote the major version being used. Values available are 3.5 and 4.6.
  • PHP, Java, and Python Versions. If using one of these technologies, this allows you to set the version to be run for the App Service. PHP 5.4, 5.5, 5.6, and 7.0 are supported. Java 7 and 8 are supported. For Python, versions 2.7 and 3.4 are supported.
  • Platform. This indicates whether your web app runs on a 32-bit platform or a 64-bit platform. Note that you cannot select 32-bit for Free websites.
  • Always On. By default, webpages are unloaded after being idle for a certain amount of time. If you need your webpage to be live and active all of the time, set this to On.
  • Debugging. These settings allow you enable and disable remote debugging. If set to On, you can then select which version of Visual Studio you want to use to perform the debugging. Be sure to specify the Debug configuration when you publish your web app if you want to perform remote debugging.

Other settings farther down this blade include the list of default documents, handler mappings, and virtual applications and directories.

The Settings blade: App Service plan

This is the App Service Plan section of the Settings blade (Figure 2-28).

Figure 2-28 App Service Plan section on the web app's Settings blade.

These are the App Service plan settings you can configure on this blade.

  • App Service Plan. This shows which App Service plan is used by the web app. This will show the settings for that App Service plan, which are the same values you see if you choose your App Service plan from All Resources on the main menu of the Azure portal.
  • Scale Up (App Service Plan). This lets you change the pricing tier for the plan. Each pricing tier provides different values for the number of cores, amount of memory, amount of storage, and so on.
  • Scale Out (App Service Plan). This is where you can set up autoscaling for your App Service plan and all of its app services. For example, you can ask it to increase the number of VMs if your CPU percentage reaches 90 percent and stays there for X number of minutes. We'll take a closer look at this in the "Scaling Web Apps" section later in this chapter.
  • Change App Service Plan. This enables you to select a different App Service plan or create a new one.

The Settings blade: Publishing

Figure 2-29 shows the Publishing section of the Settings blade for a web app.

Figure 2-29 Publishing section on the web app's Settings blade.

Here is what each of the Publishing settings is for:

  • Deployment Source. This is where you can choose a source such as Git, GitHub, OneDrive, Bitbucket, Dropbox, or Visual Studio Team Services to be used for continuous deployment.
  • Deployment Slots. This lets you publish multiple versions of your web app to different URLs. For example, you can set one up and call it staging, then publish interim changes to it. After you've tested the new version thoroughly, you can put the new version in production by swapping the deployment slot called staging with production.
  • Deployment Credentials. This lets you set the user name and password for use with Git and FTP deployment.

There are additional sections for Mobile Apps, WebJobs, and Routing, and a section that enables you to set up a custom domain and SSL bindings.

Monitoring Web Apps

Let's take a look at the many ways you can monitor your application. If you're not already there, log into the Azure portal and go to the blade for your web application. Below the properties of the web app is a pane showing the default Monitoring. You can click Edit in that pane to see all of the metrics you can add to that chart and set the time range to be displayed and the type of chart (Figure 2-30).

Figure 2-30 Specify the metrics to display on the chart.

In the Settings blade, you can check out your diagnostics in the Site Metrics Per Instance option. This shows overall metrics for your web app as well as metrics for each instance that is running. You can ask to see the last 24 hours, the last hour, or the last 5 days. This is graphed for you.

You can also see the metrics for all of the apps running in your App Service plan by selecting App Service plan Metrics Per Instance. This has the same settings as the option for your site (24 hours, etc.), but the numbers are combined metrics for all of the apps running.

Another option is Live HTTP Traffic, which will show what's going on currently with the web app, showing Request count, HTTP 5xx responses, and HTTP 4xx responses.

Using the Diagnostics Logs setting, you can enable and disable the different kinds of diagnostics logging for your web app, as shown in Figure 2-31. This includes any logging that the application may do, as well as IIS requests and Failed requests. You can FTP into the site to check the logs; the FTP information is also displayed on that blade.

Figure 2-31 Enable or disable the logging.

Scaling Web Apps

Let's go to the Settings blade and look at the scaling options.

Note You don't scale the web app specifically; you scale the App Service plan, which scales all of the apps running in app services that use that plan.

Scale Up will allow you to select a different pricing tier. This lets you increase the VM size, providing a different amount of memory, storage, etc. that we saw when we originally set up the App Service plan.

Let's take a closer look at scaling out your App Service plan. Figure 2-32 shows the Scale Setting blade that you see when you click Scale Out.

Figure 2-32 Scale Setting blade used for scaling out.

Scaling out manually

On the blade displayed in Figure 2-32, you can specify the number of instances that you want to run by either editing the text box with the number in it or dragging the slider over to the right. Figure 233 shows an example requesting that the App Service plan should be scaled out to six instances. This means all apps running in app services that are assigned to that plan will now have six instances.

Figure 2-33 Manually scaling out to six instances.

Scaling manually isn't practical unless you're sure your apps will run consistently all of the time. What if you have an application used by a small company, and usage is only high from 8 AM to 5 PM? Do you set it to handle the usage during the day and let it run at that size through the night? It would make more sense to scale down the apps in the evening when there's less usage.

What if you just want to use a simple plan of increasing the instance size when your CPU percentage reaches a specific value, and decrease when the CPU percentage goes back down? You can monitor the app service for these conditions and scale it manually, but wouldn't it be better if you could set it to scale up and down automatically? Figure 2-34 shows the options for Scale By in a drop-down list.

Figure 2-34 Options for scaling out.

You can see that you now have two more options. One is for scaling by CPU Percentage, and other option lets you put in specific rules for scaling.

Scaling by CPU Percentage

Let's take a look at the CPU Percentage scale settings, shown in Figure 2-35.

Figure 2-35 Scale by CPU Percentage.

This will allow you to scale up or down depending on the CPU Percentage. You can set the lowest number of instances and the highest number of instances as well as the CPU Percentage value where you want the autoscaling to occur. In the case displayed in Figure 2-35, the web app will run on a minimum of two instances and a maximum of six instances. The autoscaling uses standard Microsoft Insights autoscaling, creating an upper and lower bound rule that you can view using the Resource Explorer in the Microsoft.Insights resource for the App Service. It waits 10 minutes between each scaling action.

In our case here, when the CPU Percentage reaches 80 percent and stays there for at least 10 minutes, it will start scaling up the instances until the CPU Percentage is below the limit or it reaches the maximum number of instances. When the CPU Percentage is below the limit, it will scale down until it reaches the minimum number of instances.

Note When talking about autoscaling, the average CPU percentage used to scale up or down is the average across all of the VMs running in that App Service plan. This is also true for the other metrics you can use.

You can also set up notifications so it will email you when it starts scaling up and configure a webhook to be run. Webhooks allow you to route the notification to other systems. For example, you could have a service that sends you an SMS message when the scaling begins.

Scaling by schedule and performance rules

The third option allows you to set your own rules. You can set a schedule telling when to scale out and in, and you can even combine that with a performance metric. This is very useful when you want to be really specific about how your app scales out and in. For example, let's say that rather than accepting the default amount of time a value is exceeded before a scaling operation starts, you want to set it to a specific value like 20 minutes, or you want to scale using a different performance metric. You can do this by using this third setting, as shown in Figure 2-36.

Figure 2-36 Custom scaling rules.

This comes with a default profile called Default, Scale 1-1. Let's edit that profile and then define a rule that will specify that the App Service plan should scale out when the average CPU Percentage is greater than 80 percent for more than 17 minutes, and scale in when it averages less than 50 percent for 12 minutes. (I'm using odd numbers rather than the defaults here so you can pick out the numbers on the screen.) Click Default, Scale 1-1 to change the default profile as displayed in Figure 2-37. After setting up the profile, you'll add the rules.

Figure 2-37 Set up a profile for scaling.

This profile is called Test The Scaling Options, and it will apply all of the time. The minimum number of instances is two; the maximum number of instances is eight. Set the fields and click OK to add the profile.

Next, click Add Rule under the profile you just edited. This will bring up a blade similar to Figure 2-38.

Figure 2-38 Set up a rule for scaling out.

If you click the drop-down list for Metric Name, you'll see several different metrics that you can use to autoscale, such as Memory Percentage, Disk Queue Length, HTTP Queue Length, Data In, and Data Out. For example, if your web application lets people upload data, you might want to autoscale it if they are uploading a ton of data and send a notification to someone who can check and make sure it's legitimate and not a hacker. Set this to autoscale based on CPU Percentage.

In this case, when the average CPU Percentage is over 80 percent for more than 17 minutes, it will scale up by one instance. The Cool Down (Minutes) is the amount of time before another scaling action will take place. So after 5 minutes, if the average CPU Percentage is still over 80 percent, it will add another instance. It will continue to do this until it reaches the maximum number of instances you set on the profile, which was eight. Fill in the fields and click OK to save the rule.

Now we need a rule that says if the average CPU Percentage is less than 50 percent for more than 12 minutes, decrease the instance count. It will keep decreasing the instance count until it reaches the minimum number of instances, which is two in our case. Figure 2-39 shows how to set up this rule.

Figure 2-39 Set up a rule for scaling in.

After filling in the fields, click OK to save the rule. Now, the Scale Setting blade should look similar to Figure 2-40.

Figure 2-40 A screenshot showing the specified profile and its rules.

Click Save at the top of the Scale Setting blade to save the scaling settings. Now, the App Service plan will scale using these rules. Note that all Web Apps, Mobile Apps, etc. that use that App Service plan will be scaled as the App Service plan scales.

There are two other options for the profile—one is Recurrence and the other is Fixed Date. Fixed Date allows you to provide a specific date/time range with scaling information. For example, you may want it to scale up faster on opening day for your web application.

Recurrence allows you to specify a start time and which days of the week apply. This is what you would use if you had a web application used by a company from 8 AM to 5 PM but not much after that. You would add a profile to start at 8 AM on Monday through Friday to scale out, and then add one to start at 5 PM on Monday through Friday to scale back in for the evenings and weekends.

If you have multiple profiles, there is an order of precedence in which they are handled. When processed by the Autoscale service, the profiles are always checked in the following order:

  1. Fixed Date
  2. Recurrence profile
  3. Default (Always) profile

In the example above, you would set up a Recurrence profile for Monday through Friday, 8 AM to 5 PM, and then set up a Fixed Date profile for a specific holiday, and the Fixed Date profile will take precedence on that one date.