Aug 30 / Barry Luijbregts

Introduction to Azure App Service - part 2 (Hosting Web Applications with Web Apps)

This is part 2 of a 4-part series about Azure App Service. You can find the other posts in this series here:

You can also learn more about Azure App Service from my Pluralsight course Introduction to Azure App Services. It is a bit older, but still very useful.
And if you like these posts and want to support me in what I do, please visit my Pluralsight page and follow me and check out the courses on my website. 

Hosting Web Applications with Web Apps

Azure App Service Web Apps are one of the most popular services in Azure. This is because they are very easy to get started with and enable you to run your web application in Azure in minutes.
The power of Web Apps (and the other App Service types) is their ability to abstract the infrastructure. Let me explain. Traditionally, when you would develop and host a web application, you would develop it and then host it in a webserver, like IIS, which would run on an operating system, like Windows Server. All of this would typically run on either a virtual machine or a physical server that must be kept secure, performant and available.
In this traditional scenario, you, as a developer, would be responsible for developing the application. And you would also be responsible for some of the webserver configurations, like setting up the application pools and configuring the right security settings and language runtimes (for instance, configuring the correct version of the .NET Framework).
When you host your web application in an Azure Web App, Azure takes care of a lot of plumbing for you. The Service Fabric keeps the server and operating system secure, performant and available. And all you have to do, is to develop the application and deploy it to the Web App, which is basically an abstraction of a webserver. It is a webserver-as-a-service. You can still configure some of the security settings and runtime versions of the Web App, but you don’t have to do that in most cases.
Web Apps and other App Service types take care of a lot of work for you. This enables you to focus on creating the application – on adding value to your business.

Web App facts

An Azure Web App is a webserver-as-a-service. Here are some of its properties:
  • Web Apps run web applications. These could be websites, general web applications and APIs
  • You can run all sorts of applications in a Web App. You can run applications that are written in .NET, .NET Core, Python, PHP, Node.js, Java, Go, Ruby and more
  • Web Apps come with an SLA (Service Level Agreement) that promises that they will stay up and running 99.95% of the time
  • You can use all of the App Service shared features with Web Apps, including custom domains, deployment slots, scaling and hybrid connections

Web Apps run on Windows and Linux and can run Containers

When you create a Web App, you can choose what the underlying operating system should be. You can run a Web App on a Windows OS or on Linux. You don’t get to choose which version of Windows or Linux you use, because App Service will take care of that for you. You should focus on creating the application. 
Alternatively, you can choose to create an Azure Web Apps for Containers. This is just like a regular Web App but expects you to run a Windows Server or Linux based (Docker), container in it. This is a container that you store in a registry like Docker Hub, or in the Azure Container Registry service. Web Apps for Containers doesn’t come with or require a container orchestrator. It is perfect to run a single container in.
The advantage of running a container in Web Apps for Containers, as supposed to running it in another service, like in the Azure Container Instance service, is that you can use some of the App Service features, like deployment slots. 

Zero downtime deployments with Deployment slots

Deployment slots. We’ve discussed this feature in the shared features section of the first post in this series, but I want to discuss it in more detail here. This is a feature that all of the App Service types can use, so it is not unique to Web Apps. 
Deployment slots are sometimes called staging slots and that makes sense. You can use them as staging environments for the new version of your application. 
When you have an Azure Web App, you can create one or more deployment slots for it. These can all run in the same App Service Plan, so they don’t cost you any money.
A deployment slot is a Web App, just like the original Web App that you create deployment slots from. This means that a deployment slot has almost all the same features that a Web App has and can host your application in exactly the same way as your Web App does. And when you create a deployment slot, you can also copy the configuration of your Web App. You can copy things like application settings and connection strings. 
Web Apps have a unique URL and unique public IP address assigned to them. You use these when you access the Web App from the internet. A deployment slot is also a Web App (or another App Service type) and also has a unique URL and IP address. If you use your deployment slot for staging purposes, you might include staging in the name of the URL of the slot. You can reach the deployment slot with this URL. So when you deploy a new version of your application to the deployment slot, you can start testing it with that URL. This is one of the benefits of using a deployment slot – it provides a separate testing environment that is the same as your production environment.
You can also route some of the production traffic to your deployment slot. Normally, 100% of the traffic would go to your original Web App. In the Azure portal, you can indicate that you want, for instance, 20% of the production traffic, routed to your deployment slot. This way, 20% of your users will use the new version of your application and you can verify if and how they are using the new features in that version. 
Once you are satisfied with the new version of your application, you can put it in production by performing a “swap” operation. A swap operation makes sure that your users experience no downtime when you promote the new version to production. It does that by:
1. Warming up the source slot by hitting a URL to make the application load its assemblies into memory (you can also customize this behavior) 
2. Swapping the IP address and URL of the deployment slot and the original Web App (which we also call the production slot). This makes the source deployment slot the production slot
The swap operation can also be used to revert a deployment. If you are not happy with the new version, you can just swap it back to the deployment slot, thereby putting the old version of your application back into production. 
To me, deployment slots offer enough value to use App Service. You can easily integrate the swap functionality into your deployment tool, like Azure DevOps or any other tool, to automate the process when you release a new version.

Scaling up and out

One way of scaling is to increase the amount of resources that run your application. For instance, you run your application on a bigger server, with more CPU, memory, disk space and networking bandwidth. This is called scaling up.
You can also scale down by decreasing the amount of resources that you run your application on. By running it on a smaller machine. 
In App Service, you can scale up and down by choosing a different pricing tier for the App Service Plan that runs your App Service. This increase or decreases the amount of resources that run your app.

Scaling out and in

You can also run your application on more instances, by scaling out. This increases the amount of throughput that is available for users and can increase the performance of your application. 
Scaling out can be very difficult. Your application needs to be ready to run on multiple instances. For it to run on multiple instances, it should not rely on any resources that are tied to any particular instance. For instance, your application shouldn’t store data in local memory (of the VM it runs on) or save information on the local disk. Instead, your application should use external services, like Azure Storage, to store and retrieve information. 
Just like scaling out, you can save costs by running your application on less instances – by scaling in.
Scaling out and in used to be very difficult. It involved setting up and running web farms, which isn’t easy. In Azure App Service, scaling out and in is easy. You can do it manually, by increasing the number of instances, or automated, by configuring a schedule or configuring metrics.
You can configure a Web App to scale automatically by telling it when to scale, based on one or more metrics. You can, for instance, tell it to increase the number of instances to 5 when the CPU hits 70%. The automated scaling can also work on a schedule. For instance, you could configure your Web App to scale in, to 1 instance every day at 17:00 as you know the application won’t be used as much anymore. This can save you costs. You can also combine a schedule with metric rules.
A word of warning: whenever you scale your App Service, it takes a while for it to scale up or scale out. This is because the Service Fabric needs to copy over your application workload to other instances or to a bigger VM or to another VM. This usually takes a minute or so at most, but it is something that you need to plan for when you design your scaling strategy.

Deploying your application to a Web App

By now you might be wondering how you can get started. You can do that by deploying your application to a Web App (or another App Service type). 
There are many methods that you can use to deploy your application to Azure App Service:
* Use the deployment center feature in App Service
    * This enables you to couple a source control repository (like GitHub, Azure DevOps Repos or something else) to your Web App and build and deploy whenever you push new changes
* Use Azure DevOps
    * This is the go-to build and deployment center of the Microsoft technology family. This is the online version of what was called Team Foundation Server (which is now called DevOps Server). Azure DevOps used to be called Visual Studio Team Services and Visual Studio Online before that
* Use the Azure API
    * Azure has a management API that you can use to do almost anything in Azure. You can use this API directly, or from a number of clients, including the Azure Command Line Interface (CLI)
* Use your Integrated Development Environment (IDE) with the Azure SDK
    * The Azure SDK is available for most modern IDEs, like Visual Studio and Eclipse, and enables you to work with Azure from there. This also enables you to deploy your application straight from your IDE
Let’s look at deploying your application from your favorite IDE to an Azure Web App. You can do this for development and testing purposes, but you shouldn’t do this for production. You should deploy to production using an automation tool, like Azure DevOps or the App Service deployment center. 
Deploying from an IDE is easy. You just need the Azure SDK or relevant Azure tools for your IDE. For Visual Studio, the Azure SDK is already included. You do need to make sure that it is enabled. You do that by indicating that you want the Azure workload to be installed in Visual Studio. 
After that, deploying to a Web App is very simple. 
1. From the solution explorer, right-click on your application and choose Publish. This will open the publish window. 
2. In the publish window, select App Service as the publish target
3. You can now create a new App Service or pick an existing one
4. Now click publish to deploy your application
That is how simple it is. You don’t even need to have an existing App Service, you can just create one including an App Service Plan and even an Azure SQL Database or Azure Storage account from the publish window.

Summary

In this post, you’ve learned what Azure Web Apps are.
  • Azure Web Apps are used to run web applications in the cloud
  • Web Apps run on Windows, Linux and you can run containers in them
  • All App Service types can use deployment slots to do zero-downtime deployments
  • Scaling up and down increases and decreases the amount of resources your app runs on
  • Scaling out and in increases and decreases the number of instances your app runs on
  • All App Service types can scale up and down and out and in. You can scale manually and configure automated scaling
  • There are many ways to deploy your application to an App Service, including Azure DevOps, the deployment center feature and deploying manually through the API, CLI or tools like Visual Studio
Copyright Barry Luijbregts © 2022
Created with