Azure App Service is one of the biggest and most commonly used services available in the Azure cloud. It allows for easy development of web applications with multiple features available (such as support for different platforms, including .NET, PHP, and Java), manual and automated scaling, and different performance options. It's a general platform and runtime that fuels other services, such as WebJobs and Azure Functions.
In this chapter, you will learn about the following:
- Creating and deploying Azure App Service
- Working with different operating systems and platforms
- Choosing the rightÂ App Service PlanÂ and what their featuresÂ are
- Securing App ServiceÂ using different security providers
- Diagnosing and monitoring your applications
To perform the exercises in this chapter, you will need the following:
- Access to an Azure subscription
- Visual Studio 2017 with Azure development workload installed
- Visual Studio Code installed (available at https://code.visualstudio.com/)
To get started withÂ Azure App Service, you have to learn how to create that serviceÂ and deploy your code. You will see how Azure provides many different ways for doing so, and each path can be easier or harder, depending on your current needs and the specification of your application. However, the strength of a cloud and Platform as a Service (PaaS) offering lies in the straightforward and intuitive process of provisioning new components of your system.Â
To begin withÂ App Service, I will show you how you can create your very first web appÂ using the Azure Portal. In fact, all you need is your mouse and keyboard (because each application has to have a name)âneither external hardware nor detailed configuration information is required here, because Azure will do everything for you.
To create Azure App Service in the Azure Portal, youÂ firstÂ have to find it in the list of available services. The easiest way to do so is to click onÂ
+ Create a resourceÂ button and search forÂ
Instead of using theÂ
+ Create a resourceÂ button, you can click onÂ
App Servicesâit will forward you to a different view, where you can create anÂ App ServiceÂ by clicking on theÂ
+ AddÂ button. This is true for all of the most popular Azure services, such as SQL databases, virtual machines, and storage accounts.
As you can see, the Azure Portal tries to help you find the service most relevant to the search string. When you click on theÂ
Web AppÂ item, you will see another screen containing multiple similar items, all related in some way to the one you are searching for:
For the purpose of this exercise, selectÂ
Web App,Â and then click on theÂ
Create button at the right bottom of the screen.
In the beginning, it is always easier to select the most generic option when it comes to choosing a service. When you gain more experience and become more familiar with available services, you will see that Azure offers many useful preconfigured setups (such as an integrated Web App and SQL database), which can be used to shorten development and configure all services in one place.
As you can see, when creating a web app, we have to fill almost all fields (with a little exception regarding theÂ
Application InsightsÂ radio button, which we will cover in the next chapters). Let's focus on each field separately, so we have a better understanding of how they work:
App name:Â This field represents the domain name of your application. It is important to select both a unique and valid name, as itÂ cannot be changedÂ later on. Please note that you can easily attach your own custom domain if needed.
Subscription:Â If you have access to more than one subscription, you will be given an opportunity to select the right one for this particular resource. Thanks to that, you will be able to differentiate the cost between, for example, different projects.
Resource Group:Â In Azure, each resource has to be a part of a logic container, called a resource group. This does not imply any additional cost by itself, so you do not have to worry about creating multiple resource groups.
OS: Currently in Azure, you can create a web app using the different operating systems ofÂ
Dockercontainers. This choice can impact both cost and performance, so make sure you have chosen the right operating system for your needs.
App Service plan/Location:Â App Services in Azure are directly linked toÂ App Service Plans, which provide different features and performance depending on the option you choose.Â
It is always a good practice to leverage resource groups and separate your resources using a specific filter, such as the lifetime of resources, or the given environment (that is, production, staging, or testing). Resource groups gives you better control over deployed services and allows for more granular control over who can access a resource.
Since you are just starting with Azure, you probably do not have anyÂ App Service PlansÂ created. As we cannot create an App ServiceÂ without an App Service Plan, we will sort this now.
As you can see, we have to enter three fields:
App Service plan:Â This is the name of yourÂ App Service Plan, which has to be unique within a resource group.
Location:Â Thanks to this setting, we can locate ourÂ App Service PlanÂ in a specific region. This sometimes implies different features are available.
Pricing tier:Â When you click on this item, you will see another screen presenting available features for different available tiers. This choice is really important feature-wise, and will depend in most cases on the environmental characteristics you are planning (such as
Dev / Testenvironments,
Productionapplications, whether you need deployment slots or not, and so on):
As you can see in the preceding screenshot, we have three categories ofÂ App Service Plans:
Dev / Test: This one contains F, D, and B tiers (which stand for free, shared, and basic). They are designed for simple dev/test scenarios and lightweight web applications thatÂ do not need features such as autoscaling or backups.
Production: This offers powerful machines and advanced features that are useful in many realistic scenarios,Â such asÂ APIs, e-commerce, and popular portals.
Isolated:Â This uses the same hardware as theÂ
ProductionÂtier, but with even more features and possibilities to isolate your web appsÂ from external access. This is the most expensive category, but can be helpful when creating systems thatÂ cannot be made available publicly.Â
It is important to remember that tiers F and D have a limited amount of computing timeÂ per day. That means that once you exceed the limit (60 minutes for the F tier, and 240 minutes for the D tier) of your processing time, your application will become unavailable andÂ be suspended until the next day.Â
For the purpose of this exercise, I would recommend selecting any tier from theÂ
Dev / TestÂ category. Once you are satisfied with the option you've selected, you can clickÂ the
ApplyÂ button. My configuration, for example, looks like this:
RememberÂ that you can always upgrade (or scale up) the instance of yourÂ App Service Plan, for example,Â when you need a specific feature or the popularity of your application has grown. This is one of the biggest advantages of cloud over on-premises, where you would have to buy and set up new machines on your own.
Now the only thing left is to click on theÂ
CreateÂ button and wait several seconds for the creation of a new resource. During this time, Azure will validate the template and parameters, and orchestrate multiple underlying controllers to create a service. Once a new resource is created, you should see a notification and be able to see in your resources. To quickly validate this, click on theÂ
All resourcesÂ button on the left and filter all of them using, for example, the name of theÂ App ServiceÂ you have created:
This exercise was created using Microsoft Visual Studio 2017 (15.6.4) with Azure workloads installed. If you want to configure your instance and ensure everything is set up correctly, please follow the short tutorial available atÂ https://docs.microsoft.com/en-us/dotnet/azure/dotnet-tools?view=azure-dotnet&tabs=windows.
In Visual Studio, click onÂ
Project. This will display aÂ
New ProjectÂ window, where you can find plenty of different templates for starting with a new application. Because we are interested in cloud projects, let's start with theÂ
Since we are working withÂ App Services in this chapter, the template we are interested in isÂ
ASP.NET Web Application (.NET Framework). The other valid option here is alsoÂ
ASP.NET Core Web Applicationâfeel free to use it if you feel confident enough to work with the latest .NET releases, as we will cover both scenarios. When you are satisfied with your choice, clickÂ
The next step is the selection of the proper template. Here, you have multiple options, such as the following:
Empty:Â The most simple option, which lets you have full control over installed packages and overall structure
Web Forms:Â The oldest available framework for building web applications, using many built-in controls with data access
MVC: A well-known model-view-controller (MVC) architecture, which took the place ofÂ
Web API: A template for creating RESTful HTTP services using the .NET programming stack
Single Page Application:Â This template comes with plenty of additional tools for building client-side interactions
All the preceding options should be more or less familiar to you. However, thanks to installing the Azure toolset, you should have access to two additional templates:
Azure API App:Â This offers additional integrations with different Azure services such as Azure AD, API Management, and Logic apps
Azure Mobile App: A template for building mobile backends
However, we will cover those two in the next sections of this chapter. For now, to proceed, let's selectÂ
Â as this is the most common and simplest of all templates listed here. Use the default options for this template and click
You have probably noticed an additional button, which I have not described,Â
Change Authentication. It allows for selecting the method used for authenticating access to your web application. We will cover that feature in the section describing the security of web appsÂ in Azure.
After several seconds, Visual Studio should generate a project based on the selected template. I believe it should look familiar to you, as it is not that different to a traditional web application created from an MVC template. I am sure you cannot wait to see whether it worksâdo not wait any longer, and pressÂ F5 to start the application.
You should see a screen similar to mine:
Let's stop our website running locally and go back to Visual Studio for a moment. When you right-click on a project icon, you will see a context menu. There, between multiple different options, you can click onÂ
Since this is a cloud project, you will see additional options besidesÂ
App Service: This is for deploying your application to a PaaS service
Azure Virtual Machines: This is for deploying your application to a virtual machine that you have configured
Because the topic of this book is PaaS services, we will not cover deploying a web appÂ to a virtual machine. However, if you are interested in doing so, proper instructions are available atÂ https://github.com/aspnet/Tooling/blob/AspNetVMs/docs/create-asp-net-vm-with-webdeploy.md.
For now, let's selectÂ
App Service. You should see two different options:
Create new: For deploying an application to a freshly createdÂ App Service
Select existing:Â This option is only useful if you have already deployed your site
Because we are just starting, the option we are interested in isÂ
Create new. After clicking onÂ
Publish..., you will see another screen, where you can enter all the required parameters. If you read the previous section about creating an App ServiceÂ using the Azure Portal, some fields should look familiarâin fact, you are doing the very same thing as you would do in the portal. If you skipped this section, I strongly recommend that you go back and read the descriptions. After configuring my web app, my screen looks like this:
Remember that you can create both resource groups andÂ App Service Plans directly from the preceding screen. If you do not like the options listed there, you can click on theÂ
New...Â button, which will guide you through the process of creating a new resource. This is another advantage of tools such as Visual Studio, as you do not have to leave your programming environment to work with Azure.
If you are satisfied with the current configuration, the last thing left is to click on theÂ
CreateÂ button and wait a moment for the application deployment to complete. Additionally, Visual Studio will prepare a publish profile that you can reuse whenever you want to. We will have a look at it, as it will help us in the next section of this chapter. Once deployment is completed, you should see your web application open automatically in your default browser:
Congratulations! You have just created and deployed your very firstÂ App Service.Â If you take a look at the URL, you'll see that it contains the name you set in the Visual Studio wizard. All web appsÂ in Azure can be accessed using the following URL format:Â
This also explains why a name has to be unique: since, by default, all web applications hosted as Azure Web AppsÂ are availableÂ publicly, you have to select a name that is not already in use in another URL. In the next section, we will try to use FTP to deploy our application, as an alternative to using Visual Studio.
Using Visual Studio for deployments is a good idea for testing things and development, but for sure, it cannot be used for deploying production environments. The easiest option to upload files toÂ App ServiceÂ is FTP, which is already integrated with this particular Azure resource.
When you go to the Azure Portal and select the Web AppÂ you created previously, take a look at theÂ
OverviewÂ screenâyou will see plenty of information regarding this service, such as current
URL. Among all that information, there is an FTP section containing three different parameters:
FTP/deployment username:Â A name that you will use when connecting to your Web AppÂ using FTP client
FTPÂ hostname:Â A host that should be used when creating an FTP connection
FTPS hostname: The same host as the previous one, but allowing for secure connection
MyÂ App ServiceÂ currently looks like this:
All FTP information can be found in the bottom-right corner of the whole section. What we need now is the FTP client that we will use to connect to the server. I do not have any particular recommendation when it comes to selecting such an application. Personally, I prefer usingÂ
FileZillaÂ for managing my FTP connections and file transfers. You can, however, use whichever client you like, as all are quite similar regarding functionality. Before we start uploading files to the server, we need one more thing, a password for the user. To generate a new password, go to theÂ
Deployment credentialsÂ blade, which can be found on the left in theÂ
DEPLOYMENTÂ section ofÂ App ServiceÂ features:
Here, you can set two fields:
- Username for FTP user
- Password for this particular user
You may wonder how this is connected to the previous username, which can be found on theÂ
OverviewÂ screen. The difference is quite simple: usingÂ
Deployment credentials,Â you are creating a new user that will be used forÂ all applications in all subscriptions associated with your Microsoft Azure account. This has the implication that you will be able to use the very same credentials for eachÂ App ServiceÂ you deploy. This is not ideal for every scenario you will face, but for the purpose of this exercise, let's set a user and use it for deployment. In the next part of this section, I will show you how to retrieve credentials from aÂ
Publish Profile generated by Visual Studio. Once you enter a username and a password, pressÂ
Save. Now, we can go to the FTP client and use these credentials for setting a connection. Here, you can see my configuration (note that your username has to be in the following format:
Once you connect to a server, you will see a list of available directories. The very first level contains the following:
LogFiles:Â Files containing diagnostic information regarding runningÂ App Service
site:Â Your Web AppÂ working files are stored here
We will coverÂ
LogFilesÂ in the next sections of this chapter, describing monitoring and diagnosing an application. For now, we are interested in theÂ
siteÂ folder. When you enter it, you will see other directories:Â
wwwroot. The last one should be familiar for those of you who have worked with IIS, as this is the most common name of the folder containing a web application. In fact, this is the working directory of your App Service, where all necessary files should be uploaded. Here, you have the full structure of an empty web app:
Now that you know howÂ App ServiceÂ is structured, you can deploy your files and see whether or not it works. If you want, you can reuse a project from the previous exercise, or upload a brand new website.Â
If you want to reuse files, you can publish a project once again, but this time, instead of publishing it directly to Azure, create a new
Publish Profile and use a folderÂ as the target. Once Visual Studio finishes creating the package, simply copy files from the output directory to the FTP location using your FTP client.
Here are the files from a previous project of mine uploaded to my FTP server:
Now, when I go to the URL of my website, I will see a working application:
Greatâyou have just learned how to leverage the FTP feature ofÂ App ServicesÂ to deploy an application from any location and environment. However, as I mentioned earlier, we are using user-level credentials, which will be the same for all web apps that you deploy within your subscription. How do we achieve the same result using an app-level username and password?
Now, when you click on it, your browser will download aÂ
.PublishProfileÂ file. Please open it to check its content. Here is an example file from my web app:
<?xml version="1.0" encoding="UTF-8"?> <publishData> <publishProfile profileName="cloudcomrade01 - Web Deploy" publishMethod="MSDeploy" publishUrl="cloudcomrade01.scm.azurewebsites.net:443" msdeploySite="cloudcomrade01" userName="$cloudcomrade01" userPWD="LEebknaDdg0KS6SgScLuXlwtzxvwYway7ssoKxCSkCLi6Gw0HRyt2iEGMLbP" destinationAppUrl="http://cloudcomrade01.azurewebsites.net" SQLServerDBConnectionString="" mySQLDBConnectionString="" hostingProviderForumLink="" controlPanelLink="http://windows.azure.com" webSystem="WebSites"> <databases /> </publishProfile> <publishProfile profileName="cloudcomrade01 - FTP" publishMethod="FTP" publishUrl="ftp://waws-prod-am2-197.ftp.azurewebsites.windows.net/site/wwwroot" ftpPassiveMode="True" userName="cloudcomrade01\$cloudcomrade01" userPWD="LEebknaDdg0KS6SgScLuXlwtzxvwYway7ssoKxCSkCLi6Gw0HRyt2iEGMLbP" destinationAppUrl="http://cloudcomrade01.azurewebsites.net" SQLServerDBConnectionString="" mySQLDBConnectionString="" hostingProviderForumLink="" controlPanelLink="http://windows.azure.com" webSystem="WebSites"> <databases /> </publishProfile> </publishData>
As you can see, it is a simple XML file containing plenty of useful information. What we are interested in currently is both theÂ
userPWDÂ properties. Those are what we have been searching forâapp-level credentials automatically created on App ServiceÂ creation. You can use these instead of the user-level ones that we created previously.
To check how to configureÂ WebDeployÂ in Visual Studio, please go through all steps from the beginning of Creating an Azure App Service using Visual Studio section about publishing an application from this IDE. If you have done that, go once more to theÂ
If you want to import a publish profile from the previous section, then on theÂ
PublishÂ screen, you can click on theÂ
New Profile...Â button and then select theÂ
Import Profile...Â option, which allows you to select a profile file generated previously.
When you click on theÂ
ConfigureÂ button, you will see another window containing the whole configuration of your deployment:
As you can see, it contains a completely different set of information, which does not reflect the user-level settings you have configured.Â
Please do remember the difference between user-level and app-level credentials. Note that multiple users with access to a given app can use their own user-level credentials individually. What is more, to be able to use app-level credentials, you have to have at least aÂ
ContributorÂ role on a specificÂ App Service. If you are only aÂ
Reader, you will not able to access those credentials.Â
The choice between app-level and user-level credentials depends solely on the process of delivering your application. In most cases, you don't need to checkÂ by checking and setting them, as tools such as Visual Studio or Azure DevOps (formerly Visual Studio Team Services) obtain and use them implicitly. App-level credentials are often only used when we are in need of manual deployment.
Microsoft Visual Studio is not the only available IDE that allows you to work with Azure App Services. Because this Azure service supports different technology stacks, including .NET, JS, PHP, Java, and so on, you can easily leverage its capabilities to host different websites using different runtimes. For instance, let's assume that we have the following PHP code that displays a
Hello World message:
<?php echo('Hello world from Azure App Service - PHP here!'); ?>
Such a simple PHP application can be easily created in any available IDE that supports the PHP language. For the purpose of this exercise, I chose Visual Studio Code, an open source editor, as it can easilyÂ beÂ extended using many different plugins. To make things easier, you can install the following extensions:
With this plugin installed, you will be able to easily deploy your applications from within the IDE, without the need to go to the portal or use other methods. To push the application to the cloud, you have to go to theÂ
AZUREÂ tab and find theÂ
APP SERVICEÂ section.Â
Before the first use of these extensions, you may need to authenticate them. Follow the displayed instructions and Visual Studio Code will connect to your subscriptions.
Before we deploy our simple PHP application, we have to create an Azure App Service. To do so, you will have to click on theÂ
Create New Web App...Â button:
The wizard is a little bit different than in Microsoft Visual Studio, as it acts similarly to a command line, where you provide all fields and information one after another. In Visual Studio Code, you will have to enter the following:
- The Azure App Service name
- The operating system of your choice
- The runtime version
In this particular example, I specified the following:
- PHP 7.2
Once the provisioning is complete, Visual Studio Code will ask you whether to deploy the application. SelectÂ
OK,Â and then choose the folder to deploy to:
Once everything is set and ready, you will see a notification informing you that you are now able to browse the website:
When you click on theÂ
Browse WebsiteÂ button, you will be forwarded to the freshly deployed web application. Note that this extension allows you to directly manage the service from within the IDE, and gives you access to different features, including application settings, deployment slots, and Azure WebJobs (the latter of which is described inÂ Chapter 2,Â Azure WebJobs). Here, you can see the working example hosted within Azure:
The important thing here is that by using the same path, you will be able to host a variety of different runtimes inside different Azure App Services. It doesn't matter whether it is a Java application, a Python script, or a Node.js backendâthey are all supported and can be easily developed using IDEs such as Visual Studio Code.
When using Visual Studio Code with the presented extension, you might wantÂ to have more control over the creation of a resource. To enableÂ
Advanced Creation, go to the
Settings window, find theÂ
ExtensionsÂ section, and then click on theÂ
App Service: Advanced CreationÂ checkbox.
Currently,Â App ServicesÂ supports a couple of different configurations when it comes to selecting operating system, runtime, and a platform. The following are some of the possible options for running your website using App Services:
Static HTML website
Additionally, you can select a platform (
64-bit), HTTP version (
2.0), and underlying operating system (
Container). Let's start by selecting a proper operating system for our application.
To select an operating system to run your web app, we have to create a new application in Azure. Currently, there is no possibility to change this setting after an App ServiceÂ is created. To create a new website, go to the Azure Portal and click onÂ
+ Create a resource. On the new screen, search forÂ
Web AppÂ and select the first item displayed (or just return toÂ the beginning of the Selecting Azure Web App from available services section and perform all the steps mentioned there).
Web App - Creat
eÂ screen, you have anÂ
OS field. You'll have three options:
Windows:Â The most common option for .NET applications, suitable for running .NET Framework, Java, Node.js, or PHP sites.
Linux:Â If you have an application written in .NET Core, you can leverage this operating systemÂ and its unique features. Additionally, you can run Java, Node.js, PHP, and Python applications as well.
Docker: Offers Web App for Containers, which we'll cover later in this book. Besides running all of the previousÂ platforms, it allows hosting applications written in languages not currently supported inÂ App ServicesÂ (such asÂ Go, for example).
The choice is yours. Each operating system has different characteristics:Â
LinuxÂ is perfect for runningÂ PythonÂ applications, asÂ
WindowsÂ has some performance issues regarding this language; on the other hand, you may have many websites written inÂ .NET Framework, which are optimized forÂ
WindowsÂ systems. Each of the operating system options also has different pricing. Let's compareÂ
Price per hour (Linux)
Price per hour (Windows)
As you can see, there are small differences between these two operating systems. More importantly, Linux does not currentlyÂ support theÂ
SharedÂ tiers. The
IsolatedÂ tier is currently in public preview, and should not be used for production workloads, but this, of course, can change in the future. When you have considered all the pros and cons, you can create an App Service powered by the operating system of your choice.
In the previous section, you learned how to choose a properoperating system for your application. This is, of course, not everything needed to run a websiteâyou have to also enable a specific language if you want to deploy, for example, PHP code. To do so, go to yourÂ App Service (you have many options by which to do this: either chooseÂ
App ServicesÂ from the Azure Portal menu on the left and select yourÂ
Web App, or go to the resource groupÂ you created by choosing it fromÂ R
esource GroupsÂ blade) and then select theÂ
Application settings blade:
Initially, you could feel a bit overwhelmed by all those options available, but soon, as you gain more and more experience, all will become clear. You might have noticed theÂ
Upgrade to enableÂ links hereâsome features, such as
Always On,Â are only available from theÂ
B1Â tier upward.
Remember that theÂ
Always OnÂ feature could become crucial in some specific scenarios, as it defines whether your application is always running or not (so it can become idle when no one uses it). As you will learn in the coming sections, settingÂ
Always OnÂ toÂ
OnÂ is required when running, for example, continuous Web JobsÂ orÂ Azure Functions.
Currently, we are interested in all options mentioning a programming language. These options include the following:
.NET FrameworkÂ versionÂ
By default, yourÂ App ServiceÂ supports two languages:Â
.NET Framework versionÂ and
PHP version. To run, for instance, Python or Java, you would have to set an appropriate setting to aÂ specific version such asÂ enable Java support using Java version dropdown.
As mentioned earlier, always select the correct operating system powering yourÂ App Service, depending on the language that you chose for your application. While it is possible to run PHP or Python on Windows, selecting Linux, is recommended, could be recommended, as many libraries and packages can run only under this particular operating system.Â
Debugging: If you want to enable remote debugging, you can toggle theÂ
Remote debuggingÂ option toÂ
On. This will allow you to set the Visual Studio version that you would like to use to debug your application locally.
Application settings:Â This section contains settings used by your application while running.
Connection strings: You can define a connection string for your website directly in the Azure Portal.
Default documents:Â If you would like to have a custom default document (that is, the starting point of your application), you can set it in this section.
Handler mappings: Sometimes, you need to specify a custom handler for a specific file extension or URL. Here, you can add the appropriate configuration to do so.
Virtual applications and directories:Â If you need to have multiple applications in yourÂ App Service, you can map virtual paths to a physical path here.Â
Application settingsÂ for .NET applications are injected at runtime and willÂ overrideÂ existing settings stored in your
web.config. When it comes to other platforms (.NET, Java, Node.js), settings from this section will be injected as environment variables, to which you can refer. This is also true forÂ
Application settings in Azure are always encrypted when stored. What is more, you can easily secure them by disallowing all users from accessing them.Â
We touched on this topic at the beginning of this chapter, so you should have an idea of what we are going to cover now. As you remember, whenÂ App ServiceÂ is created, you have to select (or create) an App Service Plan, which defines both available performance and additional features. Let's cover all three categories, this time focusing on the differences between each tier.
We have three different tiers available:
- F1 (Free):Â The most basic option, with shared infrastructure, 1 GB of memory available, and 60 minutes of compute per day. When using shared tiers, some features ofÂ App ServicesÂ are unavailable (such as
Always on, or your selected platform). F1 is perfect for quick-testing or deploying an application for a presentation or demonstration. You will not be charged for using thisÂ App Service Plan.
- D1Â (Shared): Similar toÂ
F1,Â but this also allows for setting a custom domain for yourÂ App Service. What is more, you can run your application four times longer than when using the free tier. Still, this is shared infrastructure, so some features cannot be used.Â
- B1:Â The first tier recommended for running production workloads. It guarantees dedicated A-series machines, and more memory and storage. It is also the first tier that you can scaleâalthough only manually. TheÂ
BasicÂtier comes with additional versions (
B3), which provide more compute power.
In this category, there are many more options when it comes to choosing different features available. Remember that, in terms of hardware, theÂ
BasicÂ tier offers the very same performance as theÂ
Here, we can choose between the following:
- Standard (S1): The same A-series asÂ
B1. What we are getting here is autoscaling, staging slots, backups, and the possibility to use Traffic Manager (which will be described in coming chapters). This is the best tier for most production applications, as it supports blue-green deployment scenarios and can handle a bigger load (thanks to integration withÂ Traffic Manager). If you need more compute power, you can choose eitherÂ
- Premium (P1v2): This is the new recommended option replacingÂ
Âwith newÂ Dv2-series virtual machines underneath. It offers better performance and higher limits when it comes to scaling (a maximum of 20 instances, compared to 10 inÂ
Standard) and staging slots. You also have the option to chooseÂ
Remember that the maximum amount of instances in particular tiers is subject to availability. In most cases, these are only soft limits that can be raised after contacting support.
StandardÂ should meet most requirements when it comes to performance, reliability, and automation possibilities. However, if you are going to run a very popular website in Azure, you may needÂ Premium, as it offers more flexibility and better scalability.
One of the most important things to remember is how scaling affects the pricing.Â In general, you have two options: either you scale up (changing tier to a higher one) or scale out (by deploying multiple instances of the same application). If you are paying, for example, $40 for anÂ
S1Â instance, when you scale out to 10 instances, you will pay $400 in totalâ$40 for each instance running.
Sometimes you need even more than theÂ
PremiumÂ tier has to offer. Maybe you have to isolate your application from an external network. Maybe you would like to offer access only to some specific users. Maybe 20 instances are still not enough. This is why Azure introduced theÂ
- Isolated (I1/I2/I3):Â The same virtual machines as in theÂ
Dv2). Also includes huge storage to store your files (1 TB), private app access, an integrated virtual network (so you can access, for example, internal applications), and a more stable environment. This is the most expensive tier, but offers the most when it comes to functionality and the range of features provided.
In general, theÂ
IsolatedÂ tier is the most stable one when it comes to handling a huge load. WhileÂ
PremiumÂ tiers become unresponsive pretty quickly when utilization hits 100%,Â
IsolatedÂ App ServicesÂ need more time to return theÂ
HTTP 503 Service Unavailable response. Take this into account if you need a really reliable service that cannot be broken easily.
Most web applications have to be secured in some way, either by using your own security system or third-party identity providers, such as Facebook, Google, or Twitter. While working with the traditional application hosted on-premises, you often have to configure everything on your own. PaaS solutions, such as Azure App Services, already possess this functionality and make it easily accessible, thanks to theÂ
Authentication / AuthorizationÂ feature. In this section, you will learn how to set itÂ upÂ so users will be prompted to log in.Â
Go to yourÂ App Service and the findÂ
Authentication / AuthorizationÂ blade on the left, next toÂ
Application settings as mentioned previously. When you click on it, you will see a screen for configuration:
As you can see, it isÂ currentlyÂ disabled. When you toggle theÂ
App Service AuthenticationÂ feature toÂ
On, you will see new options available, with which you can configure authentication for your web app:
Action to take when request is not authenticatedÂ fieldÂ to any value available. The portal will display the following information:
To enable Authentication / Authorization please ensure all your custom domains have corresponding SSL bindings .net version is configured to "4.5" and manage pipeline mode is set to "Integrated".
Since we do not have a custom domain now, no action needs to be taken. The same applies to the .NET version and pipeline modeâif you have not changed the default parameters of your application, everything should be set correctly already. Let's now select one authentication provider and configure itâwe will start with Azure Active Directory.
You do not have to be an expert with Azure Active DirectoryÂ to use it withÂ App Service, especially now there is the possibility to let the Azure Portal configure it for you. However, if you would like to learn more about this service, the best place to start is its documentation:Â https://docs.microsoft.com/en-us/azure/active-directory/active-directory-whatis.Â
Off:Â Azure Active DirectoryÂ authentication is disabled.
Express:Â A quick way to configure authentication for yourÂ App ServiceÂ usingÂ Azure AD. You will have to either select an already existingÂ Azure Active DirectoryÂ application or let the Azure Portal create a new one for you.Â
ExpressÂis not enough for you, you can always enter all necessary parameters on your own. With this option, you will be able to configure integration by providing information aboutÂ
Issuer URL,Â and optionally,Â
Client Secret. All of these parameters can be found when browsing yourÂ Azure Active DirectoryÂ application.
To start, I recommend using theÂ
ExpressÂ option, as configuring applications inÂ Azure Active DirectoryÂ is beyond scope of this book. For now, you only need to provide a name for the application and clickÂ
OK. You will go back to the previous screen, where you should be able to see that one authentication provider is already configured:
Now, let's click theÂ
SaveÂ button. After a moment, everything should be set and you canÂ nowÂ access your application to see whether securing it works. Go to theÂ
OverviewÂ blade and click on theÂ URLÂ link, or enter it directly in your browser. When a default page is loaded, you will not see it, but rather will be redirected to the login page.
For this particular exercise, I have assumed that you have your application already deployed. If you have not, please go back to the previous sections and deploy your code with eitherÂ Visual Studio or FTP.
Since we configuredÂ Azure Active DirectoryÂ as our authentication provider, a user will be asked to give this particular application consent to access their information.Â
As you can see,Â Azure Active DirectoryÂ is not the only security provider available forÂ App Services. We can select Facebook, Google, or even Twitter to handle authentication and authorization for us. This is especially helpful when you have a public application for people using different social media websites, as they can use their accounts from other applications and quickly sign in when entering your website. To use other authentication providers thanÂ Azure Active Directory, you have to create an application in one of the mentioned portals. In fact, there is no difference whether you select Facebook, Google, or Twitterâyou will have to provide two fields:
App SecretÂ for Facebook
Client SecretÂ for Google
API SecretÂ for Twitter
We will not cover in this book how to create an application in other authentication providers. However, proper instructions can be found atÂ https://developers.facebook.com/docs/apps/register/,Â https://developers.google.com/identity/sign-in/web/sign-in,Â https://developer.twitter.com/en/docs/basics/authentication/guides/access-tokens.html.
The last section of this chapter will show you how you can diagnose and monitorÂ App Services that you've deployed. Those operations are crucial when you have a working application, as errors and performance issues always crop up, especially in popular services. Thanks to multiple integrated tools in Azure Web Apps, you can be sure that you'll always have enough information to find and fix a problem.
They provide basic insight into the behavior of your application, such as data transfer, the number of requests, or HTTP 500 errors. Let's click on any of those chartsâyou will see another important screen, which we will look at now.
MetricsÂ blade gives you more detailed information and a better view of a specific parameter. On the left, there are many different metrics to choose from. You create your own chart by selecting more than only one parameter.
Remember that you can only choose metrics of the same unitâthere is no possibility, for example, to connect the number of loaded assemblies and average response time.
On this screen, you can also change the chart's time range. This is very useful when searching for related issues (such asÂ
Data InÂ andÂ
Memory working setÂ to check how much memory your application needs to handle incoming data).
Let's go back to the main screen ofÂ App Service. There, when you scroll down, you will see aÂ
MONITORINGÂ section containing even more useful features.
Click on theÂ
Log streamÂ blade. You will see a black screen with the following information:
Application logs are switched off. You can turn them on using the 'Diagnostic logs' settings.
Apparently, we do not have this feature available for now. Let's go to theÂ
Diagnostic logÂ blade. It offers some interesting features regarding logging, including the following:
Application logging (filesystem):Â Collects diagnostic traces
Application logging (blog):Â The same as the
filesystemoption, but this time logs are stored within theÂ Azure Storage account
Web server logging: Gathers diagnostics about a web server
Detailed error messages: If you feel current messages are not sufficient, you can turn on this feature to get more information
Failed request tracing: Gathers information about failed requests
Additionally, you can find the FTP location of all logs with user information to log in. Since we need
Â Application loggingÂ for
Â Log stream, let's turn this feature on. Now, we can go back toÂ
LogÂ streamÂ to see what kind of information we are gathering:
If you do not see any information inÂ
Log stream, make sure you have set the correct level of logging. For all information possible, useÂ
In this chapter, you have learned what App ServicesÂ are,Â and how to build and deploy a simple application that can easily beÂ pushed to Azure. Learning the basics of this particular service is crucial for understanding other topics mentioned in this book, such as WebJobsÂ orÂ Azure Functions. Always remember that you can initially use theÂ
FreeÂ tier to avoid paying for an application when testing or developing, and then scale up when you need to do so. I strongly recommend you play around a little bit withÂ WebÂ Apps, as the cloud component has a lot more to it, and some other features are not that obvious initially. We will cover more advanced features such as integration with Traffic Manager, Azure SQL database, and scaling scenarios in the next chapters.
- Do the terms "App Service" and "Web App" refer to the same Azure service?
- How many categories ofÂ App Service PlansÂ are there currently in Azure?
- Why shouldÂ
SharedÂtiers not be used for running production workloads?
- How many authentication providers can youÂ set up inÂ App Services?
- Is there any difference in hardware between theÂ
- What do you need to enable to see logs in theÂ
- Can you attach a custom domain to each tier available inÂ App Services?
- Can you attach more than oneÂ App ServiceÂ to an App Service Plan?
- Which operating systems are available forÂ App Services?
- Can you change operating system afterÂ App ServiceÂ creation?
- Is it possible to deploy application files toÂ App Services using FTPS? Where canÂ you find the proper location address?
- What is the difference between user-level and app-level credentials inÂ App Services?
- What is the difference between scaling up and scaling out?
- Let's say that you pay $50 for one instance ofÂ App ServiceÂ per month. How much willÂ youÂ pay if you scale up to 10 instances?
- What is the purpose of using theÂ
IsolatedÂtier inÂ App Services?
- Is it possible to run a Go application inÂ App Services?
- Azure App Service documentation: https://docs.microsoft.com/en-us/azure/app-service/
- Best practices for Azure App Service:Â https://docs.microsoft.com/en-us/azure/app-service/app-service-best-practices
- Reference architectures for Web Apps:Â https://docs.microsoft.com/en-us/azure/architecture/reference-architectures/app-service-web-app/
- Deployment slots:Â https://docs.microsoft.com/en-us/azure/app-service/web-sites-staged-publishing