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