Scaling App Services: Manual and Automated Methods

Introduction

In our previous lesson, you learned how to enable and configure diagnostic logging. This gave you the visibility needed to understand what's happening inside your running application. Now, we'll take the next logical step: using performance data to ensure your application can handle real-world demand efficiently.

Today's lesson focuses on the learning outcome: Scale an App Service app manually (scale up) and automatically (scale out) based on performance metrics. This is a fundamental principle of cloud computing—paying for what you need, when you need it. We will explore how to make your application robust enough to handle traffic spikes and smart enough to save costs during quiet periods. The monitoring concepts from our last lesson are a direct prerequisite, as the metrics we use for scaling are the very data points we can log and observe.

We will cover:

1. The two primary dimensions of scaling: Scale Up vs. Scale Out.
2. How to manually increase the power of your App Service Plan (Scale Up).
3. How to configure automatic scaling based on performance metrics like CPU usage (Scale Out).
4. Best practices for creating effective and safe scaling rules.

By the end of this lesson, you'll understand how to build resilient and cost-effective applications on Azure App Service.

The Two Dimensions of Scaling: Scale Up vs. Scale Out

When an application needs more resources to handle an increased load, there are two fundamental ways to provide them: scaling up and scaling out.

• Scale Up (Vertical Scaling): This means increasing the resources of the server your application runs on. You're making the instance itself more powerful by adding more CPU, memory, or disk space. In Azure App Service, this is achieved by moving to a higher pricing tier within your App Service Plan. Think of it as upgrading your laptop from a Core i5 to a Core i7.

• Scale Out (Horizontal Scaling): This means increasing the number of instances running your application. Instead of one powerful server, you have multiple identical servers sharing the load. This is the foundation of modern, highly-available cloud applications. Think of it as adding more identical laptops to a pool to distribute the work.

For the AZ-204 exam and most real-world scenarios, Scale Out is the more common and flexible approach, as it allows for dynamic adjustment through autoscaling.

Manual Scale Up

Let's start with the more straightforward method. Scaling up is a manual process where you decide to move your App Service Plan to a different tier.

Hands-On: Explore Scale Up Options

1. Navigate to your MyFirstAzureWebApp App Service in the Azure Portal.
2. In the left-hand menu, under the Settings section, find and click Scale up (App Service plan).
3. Here, you'll see different categories of pricing tiers: Dev / Test, Production, and Isolated.
4. Click on the different tiers within the Production category (e.g., P1v2, P2v3). Notice how the available ACU (Azure Compute Unit), Memory, and features like "Auto scale" and "Staging slots" change with each tier.

You are currently on a tier that likely supports basic features. To enable features like autoscaling and deployment slots (which we'll cover next), your App Service Plan must be in the Standard, Premium, or Isolated tier. You don't need to apply any changes right now, but it's crucial to know where to find these settings and understand that the App Service Plan tier dictates the available features.

Automatic Scaling (Scale Out)

Automatic scaling, or autoscale, is where the power of the cloud truly shines. It allows Azure to automatically add or remove instances of your application in response to the load it's experiencing. This is achieved by defining rules based on performance metrics.

Prerequisites and Configuration

First, as mentioned, your App Service Plan must be on a Standard tier or higher to use autoscale.

The primary location for configuring this is the Scale out (App Service plan) blade. Let's explore how to set this up with a video guide.

Hands-On: Configure Your First Autoscale Setting

Let's apply these concepts in the portal.

1. Navigate back to your App Service and select Scale out (App Service plan) from the left menu.
2. You will see two options: Manual scale and Custom autoscale.
3. Select Custom autoscale.
4. In the Default profile, you'll configure your rules. First, set the Instance limits:
   • Minimum: 1
   • Maximum: 3 (This is a safe limit for our test)
   • Default: 1
5. Now, click + Add a rule. This opens the Scale rule panel. We will create a scale-out rule based on CPU usage:
   • Metric source: Current resource
   • Metric name: CPU Percentage
   • Operator: Greater than
   • Metric threshold to trigger scale action: 70 (%)
   • Duration (in minutes): 10 (The metric must be above the threshold for this duration)
   • Operation: Increase count by
   • Instance count: 1
   • Cool down (in minutes): 5 (Wait 5 minutes after a scale event before scaling again)
   • Click Add.

You've just told Azure: "If the average CPU across all my instances is over 70% for 10 minutes, add one more instance."

The Importance of Scaling In

A common mistake is to only configure rules to scale out. Without a corresponding scale-in rule, your instance count will increase during peak load but will never decrease, costing you money.

Let's add a scale-in rule.

1. Click + Add a rule again.

2. Configure the rule to scale in:

   • Metric name: CPU Percentage
   • Operator: Less than
   • Metric threshold: 30 (%)
   • Duration (in minutes): 10
   • Operation: Decrease count by
   • Instance count: 1
   • Cool down (in minutes): 5
   • Click Add.

3. Finally, click Save at the top of the autoscale settings page.

Now you have a complete set of rules. Azure will add an instance when the app is busy and remove one when it's quiet.

Advanced Concepts and Best Practices

For the AZ-204 certification, you need to understand not just how to configure autoscale, but also the logic behind it and best practices. This detailed blog post provides excellent explanations.

Key Best Practices Summary:

• Choose the Right Metric: For web apps, CPU might not be the best indicator of load, especially if your application is I/O bound (e.g., waiting on database queries or API calls). Metrics like HTTP Queue Length (the number of requests waiting to be processed) or Requests can often be more responsive.
• Scale-Out vs. Scale-In Logic:
  • Scale-Out is Aggressive (OR): If you have multiple scale-out rules (e.g., one for CPU, one for HTTP queue length), autoscale will trigger if ANY of the conditions are met.
  • Scale-In is Conservative (AND): If you have multiple scale-in rules, ALL of them must be met before Azure removes an instance. This prevents "flapping" (scaling in and out too rapidly) and ensures the system is truly idle before capacity is removed.
• Use a Cooldown Period: The cooldown ensures that after a scaling action, the system waits for a period before attempting another one. This gives the application time to stabilize and prevents erratic behavior.
• Monitor Your Autoscale History: In the Scale out blade, there is a Run history tab. This is where you can see all the autoscale events and the reasons they were triggered. This is a crucial part of monitoring your application's behavior.
• Consider Schedule-Based Scaling: If you have predictable traffic patterns (e.g., a business application used from 9 AM to 5 PM), you can create schedule-based profiles to proactively increase the minimum instance count during those hours.

A Note on Stateful Applications

Scaling out works best for stateless applications. Since any instance can handle any incoming request, it doesn't matter which server a user hits.

However, if your application stores state in memory (like in-memory session data or, as your C# background would make you aware, data related to ASP.NET's anti-forgery tokens), you can run into trouble. A user's first request might go to Instance A, but their next request could be routed to Instance B, which has no knowledge of the first request's state.

This leads to errors. The solution is to externalize state. For example, session data can be stored in a distributed cache like Azure Cache for Redis, and data protection keys can be centralized in Azure Blob Storage, secured by Azure Key Vault. We will cover these services in later modules. For now, it's important to recognize that designing for scale is as much an architectural consideration as it is an operational one.

Conclusion

You've now learned how to configure one of the most powerful features of Azure App Service. By matching capacity to demand, you can build applications that are both highly responsive and cost-effective.

Key Takeaways:

• Scale Up (vertical) increases the power of a single instance, while Scale Out (horizontal) increases the number of instances.
• Autoscale is a form of dynamic scale-out and requires a Standard tier or higher App Service Plan.
• Effective autoscale settings include both scale-out rules for handling load and scale-in rules for reducing cost.
• The logic for scaling is asymmetric: scale-out is aggressive (any rule triggers it), while scale-in is conservative (all rules must be met).
• When designing for scale-out, architect your application to be stateless by externalizing state to services like Redis or Blob Storage.

Next Steps

Now that we can automatically scale our application to handle more traffic, how do we deploy updates without causing downtime for our users? A scaled-out application makes this challenge more interesting. In our next lesson, we will address this by covering the learning outcome: "Configure deployment slots and perform a slot swap for a zero-downtime deployment." This powerful feature allows you to stage, test, and swap new versions of your application seamlessly.