- Scalability and availability for Azure Web Apps - Wed, Jun 28 2017
- Managing Azure Virtual Machine scale sets - Wed, May 31 2017
- Azure virtual machine scale sets - Mon, May 8 2017
You can use infrastructure-as-a-service (IaaS) Azure VMs for a wide range of use cases including running your on-premises applications, disaster recovery purposes, or running web applications. Microsoft also has another offering called Azure App Service that lets you create web applications, mobile applications, and API applications without dealing with the underlying VM and operating system configurations.
This is a platform-as-a-service (PaaS) offering, which means Microsoft will take care of the underlying infrastructure, VM, and operating system. Another important difference between IaaS (VM) and PaaS (App Service) is that Microsoft guarantees your web applications will be available 99.95% of the time. In VM-based deployments, you are responsible for your application's availability. But in App Service this is Microsoft's responsibility, so you can just focus on your core application functions.
App Service provides different features, including:
- Web Apps: a platform for developing, hosting, and managing web applications
- Mobile Apps: a platform for developing and hosting mobile applications
- API Apps: a hosted platform for developers to create and consume APIs easily for well-known platforms
- Logic Apps: a workflow orchestration platform that provides some great built-in activities for well-known software-as-a-service (SaaS) apps
These features are all part of the Azure App Service platform, and for most use cases they provide identical functionality.
Creating and deploying applications is a straightforward process, and I'll cover several options in another blog post. But before deploying an application to Azure, you need to start thinking about your availability and scalability options.
Managing App Service plans
The very first thing you should consider is choosing the right App Service plan. The App Service plan is like a container for your Azure applications. This decision will affect your app's location, features, cost, scale count, and instance size.
As of today, we have five different App Service plans available:
Azure App Service plans
Free and Shared plans are usually good for dev/test environments. For production-grade workloads, it's better to start with the Basic SKU or higher. Some other important points:
- Only Standard and Premium SKUs support auto-scaling. We will discuss scaling options, but in short, with Standard and Premium SKUs, you can configure some metrics for your applications to increase or decrease instance counts automatically.
- Only Standard and Premium plans support VPN hybrid connectivity. For instance, if you planned to use your on-premises SQL Server as a backend for your web application then creating a hybrid VPN connection would make sense. This is only possible for Standard and Premium plans.
- In addition, only Standard and Premium plans support staging environments. This is also an important feature for your application availability. By using staging environments, you can deploy your new or updated application code to a staging environment instead of a production slot. This staging environment will have a separate URL that developers can access to see if everything works as expected. Then you can easily swap the staging environment to the production slot.
- Another important feature in regards to availability is automated backups. Although you have a service level agreement (SLA) for your application, you may want to make automated daily backups. Again, only Standard and Premium plans support this feature.
Basic, Standard, and Premium plans also have three different pricing tiers within each plan.
Azure App Service pricing tiers
Within a SKU, the feature set is identical across different piercing tiers, but assigned compute resources differ. So you need to decide the right compute resources for your application.
Scaling Web Apps
After you choose your App Service Plan and deploy your web application, you can also scale it. Microsoft allows you to scale up by changing the pricing tiers or scale out by introducing an additional instance for your web application.
Normally, scaling out is a more straightforward process, and you can configure auto-scaling for Standard and Premium plans. Below is a sample auto-scale configuration for my application. If the average CPU percentage across my instances is > 70 then Azure will fire up an additional instance. I configured Azure to create a maximum of 10 instances for my application.
I also configured another condition. If my average CPU percentage across all instances is lower than 20% then Azure will kill one of my instances. But I also made sure I will have minimum of two instances available all the time.
Scale out Azure Web Apps
This is a great way to manage your performance and cost optimization together.
You can always visit your application properties and change the pricing tier, which means scaling up. Scaling up is useful when you want to increase the workload volume that a single instance can host. It's like putting more memory and CPU on a single box to meet the application demand.
App Service Environment
Another important feature for Azure App Service is the App Service Environment (ASE). It's an isolated and dedicated environment for your application. If your application requires highly scalable compute resources, isolation, and network access, using App Service Environment would be a good idea. It's part of the Premium service plan, and you can use it for Web Apps, Mobile Apps, and API Apps.
From a network architecture perspective, deploying your application to ASE will deploy it onto an Azure virtual network. This means you will have greater control over inbound and outbound network traffic. You can use network security groups to restrict unwanted traffic to your subnet or use public and private IP addresses along with an Azure internal load balancer. Other than network resources, you will have a dedicated 500 GB of storage for your application and an Azure SQL Database instance.
Another important feature available with ASE is that your application will have dedicated compute resources. You can dedicate up to 50 compute resources to a single application that requires high performance and availability.
Scaling is also possible in ASE. Actually, you don't need to scale up (change the plan), as you are already at the Premium pricing level. But you can scale up by changing the size of compute resources used in a resource pool (e.g., from P1 to P4).
In ASE, you have front-end and worker compute resources. Front ends are HTTP/HTTPS endpoints for your app; they usually determine SSL termination and load balancing. Workers are the compute resources on which you run your actual app workload.
You can have up to three different worker roles and choose different compute resources for each. One of your worker roles can have P1 compute resources for dev/test, and another one can have P4 compute resources for production. Therefore, our scaling options either change the compute resources assigned for pools or change the number of instances.
If you click the Scale option on the App Service Environment page, you will see both options on the same dashboard.
Scale App Service Environment
Scaling compute resources and instance counts
As you can see from the above screenshot, I can change the configuration of my compute resources for each pool and change the instance count for each pool as well. One important point here is that the scale operation will take a minimum of three hours to complete.
It's also possible to scale out (and auto-scale) individual pools from the settings page. If I open up the Worker pool 1 properties and click Scale out, I have options to configure auto-scaling by metrics or schedule.
Subscribe to 4sysops newsletter!
Auto scale individual Azure worker pools
In my next post, I will discuss deployment options for Azure Web Apps.
Hello,
Just to be sure: when autoscaling available for azure web app tiers, does pricing change in function of web app scaling. If it scales out to 2 web apps for example, do I pay twice the price ?
From my understanding, the autoscaling feature is included in the price of the selected service tier.
Thank you