1. Home
  2. Training Library
  3. Microsoft Azure
  4. Courses
  5. 70-534 - Design Web and Mobile Apps

Web App scalability and performance


Start course


This course covers the Design Azure Web and Mobile Apps part of the 70-534 exam, which is worth 5–10% of the exam. The intent of the course is to help fill in an knowledge gaps that you might have, and help to prepare you for the exam.


Welcome back. In this lesson, we'll be talking about designing Azure web apps for scalability and performance.

Now, both scalability and performance are important for apps of all sizes. These days, an app can go viral in mere moments and users expect apps to be highly available and they expect interactions with those apps to be fast. We mentioned scaling a bit in the overview. However, let's dive into it a bit more here.

Let's talk about scaling up and scaling out. Scaling up means that we increase the capacity of the server through additional hardware.

So if we have a server with two cores and three gigs of RAM and we wanted to scale up, we could then move to a larger server with many four cores and seven gigs of RAM. Scaling up is gonna work well for some workloads. So if you have a workload that isn't going to tax a server too much, then this may be a viable option.

However, for some workloads, we'd scale up and then we'd hit a hardware cap so before that happens or if that is expected, then we can scale out. Scaling out involves adding servers to help distribute the workload. An example of this would be web servers.

A site with a fair amount of traffic we won't be able to handle the traffic with a single server forever so adding more servers and load balancing the requests make sense. Okay, we have a conceptual understanding of scaling up and scaling out, so let's explore the topic further by scaling web apps with Azure.

Alright, we're in the Azure portal and we're on the page for the web app that we deployed in a previous lesson. And if we scroll down, you can see that we have under the settings menu some options to scale up and out.

We're currently on the app service plan that doesn't allow for us to scale out so it's a D1 shared plan. Now this is gonna give us a great opportunity to actually see scaling up. As you can see, we have some options here in the list. Each tier provides a bit more in the way of features.

You can see here the basic tier doesn't give us the option for deployment slots and that's something we'll be covering in a later lesson and we don't get Traffic Manager with basic either. Traffic Manager is a tool that allows us to geographically distribute our apps.

Now moving up the tiers, we have the standard tier which does have five deployment slots and Traffic Manager as well as daily backups. And then moving up to the premium tier, we have pretty much the same features as standard with increased stats for each.

For this, we're just gonna go with the standard one or S1 option because that will allow us to scale out so we'll save that. Now, if we wanted to scale up further, we can move to an S2 or an S3 as well as move up to the premium tier which provides increased hardware resources.

And for apps that have a fixed amount of traffic, this may work out. However, if we need to scale out, we have some options. So under settings, we have scale out and by default, you can see that we have the ability to manually select the amount of instances that we can select. However, we also have the ability to automatically scale.

Now, this is optimal when you expect traffic that's gonna be spiky or if you don't wanna deal with manually scaling. For automatic scaling, you can use the CPU-based option. This is a common metric so Azure makes it easy just to jump right in with it. We can adjust the instances and the CPU range.

Now, there's another option that allows us a bit more granularity and it's the schedule and performance rules. This allows us to specify a metric and a range and you can see that we have a few in the list. We have things like CPU percentage, memory percentage as well as others.

So when it comes to scaling web apps, we can scale up and out and we have options for how we can scale them. Besides being able to scale up and out, we have another service that's called Traffic Manager. Now that's gonna help us with high availability as well as with failovers.

In a real world scenario, you may have multiple instances of your web app. You may choose to have these instances or endpoints in different data centers around the globe to provide a fast and reliable experience for your users who may be using your app from a variety of locations.

When a user sends a request to your app, you may want that request to be handled by the closest endpoint to that user. You may also want them to be directed to another instance if that particular endpoint is down or may be having issues.

The Azure Traffic Manager provides domain name system or DNS level traffic management which we'll discuss in detail. The job of the Traffic Manager is to direct the users to the most appropriate instance based on a set of configurable rules. Now, this is pretty cool.

Traffic Manager also performs active endpoint monitoring to detect which endpoints are operational and can handle the requests, meaning that the Traffic Manager can avoid sending clients to endpoints which might be down or having issues. It's worth noting that traffic doesn't actually flow through the Traffic Manager.

The Traffic Manager performs DNS level redirection. So in simple terms, that just means that the redirection only happens when the user's client is seeking the IP address it should connect to to reach your web app. Now once it's connected, the traffic between the client and your web app doesn't go through Traffic Manager at all.

Let's take a look at an example for this. Let's say that a user wants to browse to your web app which is hosted at www.mywebapp.com. The user's browser sends a DNS request for www.mywebapp.com. Your DNS configuration has a CNAME record for the www subdomain of that domain that redirects to mywebapp.trafficmanager.net.

When the user's browser sends a DNS request for mywebapp.trafficmanager.net, the Traffic Manager handles this request and determines the best possible endpoint to send the user to by running through the configured rules.

In this case, the Traffic Manager will respond to the domain name of the specific endpoint which is in our example mywebapp-uswest.azurewebsites.net. The user's browser sends a DNS request for mywebapp-uswest.azurewebsites.net which will provide the IP address that it should connect to.

Let's go through this with a diagram to hopefully clarify this. This diagram is gonna help us visualize the flow of the actual events. Now, this has been simplified for clarity and the domain name to IP lookup has been removed.

So the user requests the address of www.mywebapp.com, the DNS server responds with a CNAME record pointing the user to mywebapp.trafficmanager.net, the user queries the Traffic Manager for mywebapp.trafficmanager.net and Traffic Manager evaluates configuration rules to determine the best endpoint to direct that user to.

Traffic Manager replies with the endpoint domain name mywebapp-uswest.azurewebsites.net. Having resolved the IP address of mywebapp-uswest.azurewebsites.net, the user connects to the actual web app. It's worth noting that because the DNS resolution is going to have a time to live, usually abbreviated TTL, that means we need to consider how long we want that value to be cached for.

The longer we cache it for, the longer it will require the user to wait to be redirected to a healthy endpoint should that cached endpoint go down. However, a TTL that isn't very long means more DNS traffic which equates to additional costs, so it's gonna become a bit of a balancing act.

The last thing regarding Traffic Manager is that it offers several load balancing methods. Each method can define its own TTL and list of endpoints and monitoring configuration. The key difference between these methods is how they affect the Traffic Manager's choice of endpoints when responding to the user.

The first method is gonna be failover and when using this method, the Traffic Manager will return the first endpoint from an ordered list where that endpoint is deemed healthy based on the Traffic Manager's endpoint monitoring.

The next is going to be round robin and as the name suggests, that Traffic Manager endpoint just returns from a list trying to balance the request out evenly in a round robin fashion.

The third method is gonna be performance. This is the method that's concerned with selecting the endpoint with the lowest latency and that's the usually the one that's closest physically to the client. To achieve this, the Traffic Manager uses Azure's latency and monitoring data that describes the latency to various parts of the world.

The Traffic Manager will then use that data as its look up to find data centers with the lowest latency to the client. It's worth noting that all of these methods have a failover component as the Traffic Manager is not going to select an endpoint if that endpoint is detected as being down regardless of the load balancing method.

So let's summarize what we've covered in this lesson. Web apps in Azure allow us as operations engineers to hand off most of the operational tasks to the engineers at Microsoft. This manage platform allows for highly scalable applications and applications that usually perform better than the apps that we host on prem.

Scalability is so important for modern web applications and by using app service, we have the ability to create highly available applications with far less effort than it would take to do the same thing on prem.

Alright, in our next lesson, we're gonna be talking about deploying web apps in Azure so if you're ready to keep learning then let's get started.

About the Author

Learning paths15

Ben Lambert is a software engineer and was previously the lead author for DevOps and Microsoft Azure training content at Cloud Academy. His courses and learning paths covered Cloud Ecosystem technologies such as DC/OS, configuration management tools, and containers. As a software engineer, Ben’s experience includes building highly available web and mobile apps. When he’s not building software, he’s hiking, camping, or creating video games.