If you need to deploy a web application that doesn’t have a microservices architecture, then Azure App Service Web Apps is usually the best way to do it. It’s a managed service, so you don’t have to worry about provisioning and maintaining the underlying infrastructure. It’s also very flexible because you can write your application in ASP.NET, ASP.NET Core, Java, Ruby, Node.js, PHP, or Python. Web Apps runs on Windows with IIS, but there’s also a Linux version that I’ll talk about later.

Setting up continuous integration and deployment is easy too because it’s integrated with Azure DevOps, GitHub, BitBucket, Docker Hub, and Azure Container Registry.

Although Web Apps take care of the underlying infrastructure, you do have control over how it scales. There are two ways to do this: scaling up and scaling out. Scaling up means adding more resources, such as disk space. You do that by choosing a higher App Service pricing tier. As you go up in service tiers, you can have more apps, more disk space, and more instances.

The number of instances is how you scale out. For example, in the Premium tier, you can have up to 20. To actually spin up extra instances, you can either do it manually or automatically. To do it automatically, you choose a metric, such as CPU Percentage, and set the App Service to autoscale if that metric reaches a particular threshold, such as 80%. When the average CPU percentage across all of the existing instances reaches that threshold, then App Service will add more instances. How many more is determined by the value you put here. This is a percentage, so if you set it to 25, then it will add 25% more instances when the CPU average hits 80%.

You should also set a rule that tells it to scale in when the CPU average drops below a certain level, so you aren’t wasting resources during quiet times. You can even have different rules for different levels. For example, you could tell it to scale by 25% if the CPU average reaches 60%, and by 40% when the CPU average reaches 80%.

By default, the autoscaling rules you set are always in effect, but you can run them on a schedule if you want. You can also have different rules in effect at different times.

Scaling isn’t the only way to increase a web application’s performance. Another way is to use Azure Redis Cache, which stores recently accessed data in memory. This is especially helpful for caching database records that get accessed multiple times. Another example is caching a user’s session information instead of always having to retrieve it from a cookie in the user’s browser. Getting data from an in-memory cache can significantly speed up web applications.

Another way to speed things up is to use a Content Delivery Network (or CDN). When you put static content from your website into a CDN, users can retrieve it from a nearby edge server rather than from your website. This also reduces the load on your web app. If your entire website is static, then you can serve it from a CDN without even having to deploy any compute resources, such as a web app or VM.

A CDN is especially useful for reducing latency in geographic locations far from where your web app resides. There are lots of other great uses for it too, like streaming videos or distributing firmware updates to IoT devices.

Autoscaling, Azure Redis Cache, and Azure CDN are complementary approaches to increasing performance. You can use all three at the same time to get the best results.

The next thing to look at to make your web app perform reliably is high availability. An Azure App Service Web App is only deployed in one region, so to ensure that it can survive a regional outage, you need to deploy a standby copy of the web app in another region. Ideally, you should deploy it in the region that’s paired with the first region. If there’s a major outage, Microsoft will prioritize bringing up at least one region in every pair.

Under normal circumstances, you’ll want all of your users to go to the web app in the primary region, but when there’s an outage, you’ll want to fail over to the secondary region. Azure Traffic Manager can handle this sort of requirement using priority routing, which used to be called failover routing.

If you have a database behind your web app, which is usually the case, then you’ll have to configure a failover solution for that as well. For example, if you’re using Azure SQL Database, then you’ll need to configure active geo-replication.

Even if you’ve set up a secondary region, you’ll still want to configure backups so you can recover from data corruption problems. You can create backups manually, but of course, it’s much better to automate them. It’s quite easy to do this in the Azure portal. You go into the Backup Configuration page for your app and tell it which storage container to use. To protect against regional failures, you’ll want to use geo-redundant storage. Then you turn on “Scheduled backup”, tell it how often to run the backup, when to start the schedule, and how long to retain the backups. If your app uses a database, you can enter the connection string and it’ll back that up too. The backup and restore feature is only available in the Standard service tier and higher.

And that’s it for web applications.