Working with different operating systems and platforms

Currently, App Service supports a couple of different configurations when it comes to selecting the operating system, runtime, and platform. Here are some of the possible options for running your website using App Service:

• .NET Core 2/3
• .NET 5/6
• ASP.NET 3.5/4.8
• Node.js 12/14
• PHP 7/8
• Java 8/11
• Python 3
• Static HyperText Markup Language (HTML) website

Additionally, you can select a platform (32-bit or 64-bit), the HyperText Transfer Protocol (HTTP) version (1.1 or 2.0), an underlying operating system (Windows, Linux, or container), or even a Java web server powering your website. 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 must create a new application in Azure. Currently, there is no possibility to change this setting after an App Service resource is created.

Note

Be careful when planning to deploy web applications using different operating systems to the same resource group because of some hardware limitations—for example, once a Linux Azure App Service plan is deployed, you cannot create a Windows one next to it. You will need an additional resource group for that.

To create a new website, go to the beginning of this chapter, where we discussed the way to deploy a web application using the Azure portal. Once you see the creator, look at the Basics tab. The Instance Details section presents the information we are interested in, as follows:

• Publish: This offers a way to deploy code or a Docker container. Choosing the Docker Container option will hide the Runtime stack parameter as it is no longer valid.
• Operating System: You can select either Windows (which is the most common option for .NET applications, suitable for running .NET Framework, Java, Node.js, or PHP sites) or Linux, which can be used for running an application written in .NET Core. Additionally, you can run Java, Node.js, PHP, and Python applications as well.
• Runtime stack: Depending on your technology stack, here, you can select exactly what you need to get started with your application.

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 is optimized for Windows systems. Each of the operating system options also has different pricing. Let's compare Windows and Linux here, assuming the West Europe region is chosen:

Figure 1.29 – App Service plan pricing comparison

As you can see, there are some differences between these two operating systems. More importantly, Linux does not currently support the Shared tier. The Isolated tier is something you should consider if in need of hardware isolation or strict network connectivity requirements. When you have considered all the pros and cons, you can create an App Service resource 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 must also enable a specific language if you want to deploy (for example, PHP code). To do so, go to your App Service resource (you have many options by which to do this: either choose App Service from the Azure portal menu on the left and select your Web App resource or go to the resource group you created by choosing it from the Resource Groups blade) and then select the Configuration blade, as illustrated in the following screenshot:

Figure 1.30 – Configuration 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 Click here to upgrade... notification here—some features, such as Scaling out or Always on, are only available from the B1 tier upward.

Tip

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, enabling Always on is recommended when running, for example, continuous WebJobs or Azure Functions.

Currently, we are interested in all options mentioning a programming language. These options are available in the General settings tab and include the following:

• .NET version
• PHP version
• Python version
• Java version
• Node version
• Ruby version

As opposed to selecting the operating system, which cannot be changed later, you are free to change the stack powering your website anytime. This is unlikely in most cases, but if you ever need to do that, you will not have to recreate the whole App Service instance.

Tip

As mentioned earlier, always select the correct operating system powering your App Service instance, 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 as many libraries and packages can run only under this particular operating system.

Let's now check how we can work with web application settings.

Working with application settings

The Configuration blade offers more than simply enabling or disabling available features. As you can see, you have three different tabs giving access to various features, as follows:

• Application settings: This tab contains settings used by your application while running. It allows you to set parameters available as environment variables and connection strings transmitted over an encrypted channel.
• General settings: This tab contains settings for controlling technology stack and platform settings such as WebSocket, HTTP version, or File Transfer Protocol (FTP) access.
• Path mapping: This is used so you can mount Azure files/blobs and access them from within your application without additional configuration.

Tip

Remember that Application settings features for .NET applications are injected at runtime and will override existing settings stored in your web.config file. 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 features.

Application settings features in Azure are always hidden when stored. What is more, you can easily secure them by disallowing all users from accessing them or even integrating them with Azure Key Vault for further protection.

Tip

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

Now, as we learned a bit about various configuration settings, we can focus our attention on additional basic functionalities App Service offers.