One of Azure’s most popular services is App Service Plan. App Service Plans can serve many purposes, including solutions around API, Mobile and Web apps. Today we will explore the web apps offering, which is a compelling choice to use for building new cloud-native web applications.
Azure App Service Plan Overview
As we said in the intro the core component of web apps is the App Service Plan, it cannot exist without it. This is where you define the compute, region, operating system (Windows or Linux) and pricing tier of your project needs. There are a couple of important notes for some key areas worth mentioning.
Region
Obviously, this is the geographical location of where your service will run. Naturally, you will want to keep this close to your user base consuming the application. You can build out some complex designs here where you stack other Azure services, such as Azure Front Door (Layer 7 HTTP/HTTPS layer anycast protocol) to build a truly global scalable web application.
Tiers
There are many tiers to choose from including Free, Shared, Basic, Standard, Premium, PremiumV2, PremiumV3 and Isolated.
These vary massively and I encourage you to make sure the type fulfils your need at the cost point you desire. For example, if there is a pre-requisite to only run on dedicated compute and lock the environment via VNET integration then you have no choice but to use the isolated tier.
To summarise:
- Shared compute: Free and Shared, the two base tiers, run an app on the same Azure VM as other App Service apps, including apps of other customers. Your app receives CPU minutes on a shared VM instance and cannot scale-out. These tiers are intended to be used only for development and testing purposes – do not use for production.
- Dedicated compute: The Basic, Standard, Premium, PremiumV2, and PremiumV3 tiers run apps on dedicated Azure VMs.
- Isolated: This tier runs dedicated Azure VMs on dedicated Azure Virtual Networks thus giving complete network isolation and enhanced security.
Let’s look visually
It is probably easier to visualise the relationship of tiers and compute via the Azure Portal. Let’s look at the different options.
Under the settings of an App Service Plan, you will see options for scaling. This is where you will find the tiers:
As soon as you select “Production” you will see a selection of S and P based tiers. Within the tiers, the compute resources are stated but you also get additional features shown below:
For isolated setups, the below is shown via an App Service Environment (ASE).
This is the true isolation and dedication of hardware. The ASE is normally deployed on VMs that are provisioned on a multi-tenant hypervisor. If you need to deploy on dedicated systems, including the hardware, you can provision your ASE onto dedicated hosts. Dedicated hosts come in a pair to ensure redundancy. As you can tell, this is all dedicated so it is usually deployed to your virtual network so you can expect to integrate other resources within that virtual network too – that is if it is required. The downside of this is cost, something you need to consider before moving to this design.
Talking about costs, from a design perspective you can potentially save money by putting multiple web apps into one App Service plan. However, keep in mind that apps in the same App Service plan all share the same compute resources so be careful of the noisy neighbour effect. It is best advised to consider isolated apps if:
- You know that a key app will be resource-intensive.
- You want to scale the app independently away from other apps you may have within the service plan.
Environments and Slots
The goal is to follow your DevOps / branching processes and have the setup below.
This can only be done if you utilise slots via the standard or premium plans shown earlier. The idea of using slots is to carve out environments for application code releases, for example, a staging slot. You can use this area to deploy and test new code and once successfully tested you would switch out from staging to production (or another layer if needed). If there was an issue, then it is easier to switch back to a previous slot.
As you can see this idea of swaps and slots is useful for those DevOps practices where you can build out CD (Continuous Delivery) pipelines to automatically deploy to staging then to production based on the branching strategy you use i.e., a push on main / master.
As a side tip, if your App Service Plan is using over 90% of available CPU or memory during a deployment, the underlying virtual machine may have trouble processing your deployment. When this happens, temporarily scale up your instance to perform the deployment.
Alternatively, you can do manual deployments, which includes the following methods:
- Azure CLI.
- Zip-deploy.
- Directly from Visual Studio.
- FTP
Azure CLI deployment is very common, below shows the relevant steps you would need to do from the command line.
Login to Azure
az login
Confirm that your web app exists in Azure
az webapp list –resource-group Yourwebappresourcegroup
CD to where your local files are being built
cd F:\Web\API\
Deploy
az webapp deployment source config-zip –resource-group Yourwebappresourcegroup–src yourapi.zip –name <name of your app>
Scaling
Being a cloud-native technology, you have the possibility to scale up and out the App Service Plan. When you scale up, we are saying that we can assign more cores, memory and disk space – all the metrics you would expect. This is basically moving up a pricing tier. This is completely different to the idea of scaling out.
When we scale-out, we are adding more virtual machines to run the app (horizontally), up to a maximum of 20 instances. This goes very well with the auto-scaling feature. For autoscaling, at a high level you need to create an auto-scale job with an associated rule to scale by, so that upon checking if it has crossed the configured threshold for a scale-out, it will occur (or a scale in request). A rule could look like If CPU > 90%, scale-out by 1.
Azure App Service – Web Apps
When you build a web app in Azure it responds over HTTP on port TCP 80/443, they offer many runtime languages, so it is flexible and not locked down to a specific language. Let’s look at a basic example of how we can deploy to Azure.
Let’s look at a basic example within Visual Studio Code, below is a snippet.
I navigate to the Azure section of Visual Studio Code and go through the process of creating an Azure Web App as shown below.
Work your way through the settings which include concepts we have covered in theory such as the region, operating system and tier for the App Service Plan.
Below I define a resource group as you would expect.
I then select the .NET core version I would like.
Then I start building the App Service Plan details.
I decide to make some application code changes then redeploy to Azure (I deploy directly from Visual Studio Code, if you remember this is one of the manual ways you can do it).
If you click browse, it will take you to the web app hosted in the cloud.
You can see the relevant information/metrics within the Azure Portal regarding both the web app and App Service Plan itself.
You will have a wealth of information at your fingertips.
In Closing
So, you can see the benefits of running such applications in the cloud. I no longer have to worry about the underlying hardware, meaning I no longer have to be concerned about patching both the hardware and operating system that the code runs on.
Microsoft generally deploys new runtime versions in a side-by-side strategy so you may have to manually upgrade to that newer version. An example of upgrading via Azure CLI would look like this:
az webapp config set \ –net-framework-version v4.7 \ –resource-group <groupname> \ –name <yourappname>
If the version that you are currently running on is announced for deprecation, you need not worry as Microsoft will state a removal date so you can work on a migration path for your apps.
If you are in need of consultancy before starting development or are looking for a fully outsourced custom software development partner, check out our work in Azure or get in touch.
Azure App Service – Web Apps References
https://docs.microsoft.com/en-us/azure/app-service/overview-hosting-plans https://docs.microsoft.com/en-us/azure/azure-monitor/autoscale/autoscale-get-started?toc=/azure/app-service/toc.json
