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.
Before we talk about Web Apps, let's talk about App Service and the App Service plans.
The App Service is a service that hosts one of five kinds of applications:
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.
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.
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.
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.
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.
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.
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.
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.
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.
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:
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 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.
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:
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.
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.
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.
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.
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.
Let's start with the icons across the top of the Web App blade and look at what they are used for.
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.
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.
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:
Other settings farther down this blade include the list of default documents, handler mappings, and virtual applications and directories.
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.
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:
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.
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.
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.
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.
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.
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:
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.