This course will provide you with the practical knowledge and experience needed to master the Designing Web Apps section of the Architecting Microsoft Azure Solutions 70-534 certification exam. In addition to full coverage of all exam topics, this session will focus on the key competencies tested by the exam. We will start by creating a Web App, and we will discuss designing and deploying web apps for scalability and performance as well as the business continuity issues of Web App design.
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 maybe four cores and seven gigs of RAM. Scaling up is going to work well for some workloads. So if you have a workload that isn't going to tax the 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, won't be able to handle the traffic with a single server forever. So adding more servers and load balancing the requests makes 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 menus 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 going to 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 going to 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 going to be spiky or if you don't want to 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 going to 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 maybe 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 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 request. 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's going to 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 C name 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 cost. So it's going to 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 it's 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 going to 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 going to be performance. This is the method that is concerned with selecting the endpoint with the lowest latency and that's 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 lookup 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 managed 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 going to be talking about web apps in Azure. So if you're ready to keep learning then let's get started.
About the Author
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.