[{"id":"ch01lvl1sec01","contentType":"text","title":"Azure App Service","content":"

Azure App Service

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

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1","metaDescription":"","titleSlug":"azure-app-service"},{"id":"ch01lvl1sec02","contentType":"text","title":"Technical requirements","content":"

Technical requirements

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/)

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec02/technical-requirements","metaDescription":"","titleSlug":"technical-requirements"},{"id":"ch01lvl1sec03","contentType":"text","title":"Creating and deploying Azure App Service","content":"

Creating and deploying Azure App Service

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.

Creating Azure App Service using the Azure Portal

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.

Selecting Azure Web App from available services

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 Web App:

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.

Configuring an Azure web app

When you click on the Create button, you will see a screen where you can enter all the information needed to create a web app. All required fields are marked using an * (asterisk) symbol:

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 Windows, Linux, or Docker containers. 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.

Creating an App Service Plan

When you click on App Service plan/Location, you will see a screen with the + Create new button, allowing for the creation of a new App Service Plan. It should look like this:

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 / Test environments, Production applications, 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, you can click OK, and you will return to the Web App blade, where you can enter missing fields. Here, you can see the whole configuration of my web app:

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:

Creating an Azure App Service using Visual Studio

If you do not want to create your web apps using the Azure Portal, you can use Microsoft Visual Studio, which has built-in integration for many different Azure services.

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 File | New 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 Cloud category:

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

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 Forms
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 MVC, as this is the most common and simplest of all templates listed here. Use the default options for this template and click OK.

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:

As you can see, it is the same generic template that you would see when starting with a traditional project. The question is, how can we deploy it to Azure to have our website working in the cloud?

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 Publish...:

Since this is a cloud project, you will see additional options besides IIS, FTP, and Folder:

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:

http(s)://{appservicename}.azurewebsites.net

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.

Deploying Azure App Service using FTP

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.

Deploying Azure App Service with user-level credentials

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 Status, Location, and 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: <appservicename>\<ftpusername>):

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: deployments, locks, and 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?

Deploying Azure App Service using app-level credentials

There are two ways to deploy an application using app-level credentials:

Download them from the Azure Portal
Configure WebDeploy in Visual Studio

Downloading app-level credentials from the Azure Portal

When you go to your App Service and click on the Overview blade, you will see the Get publish profile button at the top, as shown in the following screenshot:

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 userName and 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.

Configuring WebDeploy in Visual Studio

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 Publish screen.

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.

You can always reset app-level credentials (for instance, if current ones should be revoked, because of some kind of security issue) from the Overview blade. Next to the Get publish profile button, you can find the Reset publish profile option, which will set a new username and password.

Creating Azure App Services using Visual Studio Code

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:

handsonazure-euw-appservice
Linux
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 File | Preferences | Settings window, find the Extensions section, and then click on the App Service: Advanced Creation checkbox.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec03/creating-and-deploying-azure-app-service","metaDescription":"","titleSlug":"creating-and-deploying-azure-app-service"},{"id":"ch01lvl1sec04","contentType":"text","title":"Working with different operating systems and platforms","content":"

Working with different operating systems and platforms

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:

.NET Core
.NET Framework
Node.js
PHP
Java
Python
Static HTML website

Additionally, you can select a platform (32-bit or 64-bit), HTTP version (1.1 or 2.0), and underlying operating system (Windows, Linux, or Container). Let's start by selecting a proper operating system for our application.

Selecting an operating system

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

On the Web App - Create 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 Windows and Linux here:

	BASIC	STANDARD	PREMIUM	ISOLATED
Price per hour (Linux)	$0.071	$0.095	$0.19	N/A
Price per hour (Windows)	$0.075	$0.10	$0.20	$0.40

As you can see, there are small differences between these two operating systems. More importantly, Linux does not currently support the Free and 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.

Selecting different platforms

In the previous section, you learned how to choose a proper operating 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 Resource 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 Platform or 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
PHP version
Python version
Java 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.

Working with application settings

The Application settings blade offers more than simply enabling or disabling available features. When you scroll down, you will see additional sections, including the following:

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.

Remember that 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 Connection strings.

Application settings in Azure are always encrypted when stored. What is more, you can easily secure them by disallowing all users from accessing them.

Connection strings for platforms other than .NET are always prefixed with appropriate connection type. There are four possibilities: SQLCONNSTR_, MYSQLCONNSTR_, SQLAZURECONNSTR_, and CUSTOMCONNSTR_.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec04/working-with-different-operating-systems-and-platforms","metaDescription":"","titleSlug":"working-with-different-operating-systems-and-platforms"},{"id":"ch01lvl1sec05","contentType":"text","title":"Different App Service Plans and features","content":"

Different App Service Plans and features

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.

Dev/Test App Service Plans

App Service Plans designed for development and testing environments can be found in the Dev / Test category:

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 (B2 and B3), which provide more compute power.

If you are obligated to run your application in Azure in services defined by a service level agreement (SLA), remember that you cannot use the Free or Shared tiers, as they do not support this.

Production App Service Plans

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 Standard tier:

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 S2 or S3.
Premium (P1v2): This is the new recommended option replacing P1, 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 P2 or P3.

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.

In general, 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.

Isolated App Service Plans

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 category:

In this category, we have only one tier divided into three versions:

Isolated (I1/I2/I3): The same virtual machines as in the Premium tier (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 Standard or 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.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec05/different-app-service-plans-and-features","metaDescription":"","titleSlug":"different-app-service-plans-and-features"},{"id":"ch01lvl1sec06","contentType":"text","title":"Securing App Services using different security providers","content":"

Securing App Services using different security providers

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.

Configuring authentication/authorization in the Azure Portal

As with most PaaS services, you can configure the features of App Services directly from the portal. Thanks to such an approach, you have all options in one place and can easily switch between them.

Using Azure Active Directory to secure App Services

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:

Change the 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.

When you click on the Azure Active Directory option, you will see a new screen where you can configure integration. Firstly, you have to select the Management Mode:

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.
Advanced: If 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 Client ID, 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.

Using other authentication providers

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:

An App ID and App Secret for Facebook
A Client Id and Client Secret for Google
An API Key and 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.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec06/securing-app-services-using-different-security-providers","metaDescription":"","titleSlug":"securing-app-services-using-different-security-providers"},{"id":"ch01lvl1sec07","contentType":"text","title":"Diagnostics and monitoring of App Services","content":"

Diagnostics and monitoring of App Services

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.

The Overview blade

The very first thing you probably already noticed is the charts visible in the Overview blade:

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

The 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).

Monitoring

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 filesystem option, 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 Verbose.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec07/diagnostics-and-monitoring-of-app-services","metaDescription":"","titleSlug":"diagnostics-and-monitoring-of-app-services"},{"id":"ch01lvl1sec08","contentType":"text","title":"Summary","content":"

Summary

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.

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec08/summary","metaDescription":"","titleSlug":"summary"},{"id":"ch01lvl1sec09","contentType":"text","title":"Questions","content":"

Questions

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 Free and 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 Basic, Standard, and Premium tiers?
What do you need to enable to see logs in the Log stream?
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?

","url":"https://subscription.packtpub.com/book/cloud-and-networking/9781789340624/1/ch01lvl1sec09/questions","metaDescription":"","titleSlug":"questions"},{"id":"ch01lvl1sec10","contentType":"text","title":"Further reading","content":"

Hands-On Azure for Developers

By : Kamil Mrzygłód

Hands-On Azure for Developers

By: Kamil Mrzygłód

Overview of this book

Related Content you might be interested in

Current Title:

Hands-On Azure for Developers

Migrating Applications to the Cloud with Azure

A Developer's Guide to .NET in Azure

Microservices with Azure