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

Business Continuity


Web App Overview
Wrap Up
1m 32s
Start course


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're going to be talking about some of the ways that we can design our web apps for business continuity.

Web apps are usually more than just deployed code. So that means they consist of more than just an underlying VM and the code that lives on it. We usually will have a database. It can be SQL or NoSQL. We'll have a content delivery network, which is usually abbreviated CDN, as well as some other components. So in addition to talking about web apps, we're going to talk about some of those additional services as part of this lesson.

Here are some of the things that we're going to be covering. We're going to talk about scaling SQL servers up and out, we'll talk about geo-replication, and we'll talk about designing a data tier, and then we're going to talk about the Azure Resource Manager Templates, often abbreviated ARM Templates.

Okay, let's start with talking about scaling SQL up and out. Now before we can talk about scaling a database, we need to talk about DTUs, which stands for Database Transaction Units. So what is a DTU? It's a unit of measure for the resources that are guaranteed to be available to a standalone Azure SQL database. The way it's calculated is by blending a measure of CPU memory as well as data and transaction log IO. So if you were to double the DTUs for a database, you're doubling the set of resources that that database has access to.

The example that Microsoft gives is that a premium P11 database with 1,750 DTUs provides 350 times more DTU compute power than a basic database with five DTUs.

Okay, now that we understand what DTUs are, we can talk about scaling. If you want to scale a database up, which is increasing the hardware resources, it involves selecting a pricing tier that increases the amount of available DTUs.

Let's check out how. From the blade of a database that we want to scale, we're just going to click on Pricing Tier and select the option that we want. With this, we can scale up or down very easily. Here, I'm going to select S1 and we'll click OK. And after a little while, it'll update, and really that's all there is to it.

Now when it comes to scaling a database out, it's a bit different than scaling out web servers. With a web server, we're just adding new servers to a load balancer and the servers will be all the same. They're all going to have the same configuration and same software.

With a SQL database, you have to deal with data. So if you just add a bunch of databases, then you'd need some method to replicate the data between these servers so that they all stay in sync. Would you use data replication that's synchronous or asynchronous? And answering these lead to additional questions and it becomes quite the rabbit hole. There's a lot to consider here.

However, what we're going to focus on are read-only replicas that are geographically separated. This is considered geo-replication. Using geo-replication with read-only replicas allows us to distribute the reads across multiple databases. So users can read data from a server that's physically closer to them. So that's one benefit because it's going to give us additional performance. The other is that we have additional databases with our data replicated, and that allows for a form of disaster recovery. This gives us protection from failures that are occurring in a specific data center or multiple data centers in a geographic region since we can have the geo-restore restore our database to a data center that's operational.

And we can optionally purchase active geo-replication, which gives us a lower recovery point objective, which is usually abbreviated RPO, and you can enable these features, such as active geo-replication, using the Azure Portal, PowerShell, T-SQL as well as the Rest API.

Using read-only replicas with geo-replication isn't the only way to scale out a SQL database. We can also use elastic data pools, and what an elastic data pool does is provide us the ability to manage the costs by creating a pool of resources that we can share across multiple databases. So if we have databases that have a lot of burst traffic, then we can add them all to the same pool and it's going to allow them to share resources.

Now you might be wondering how this helps with scaling out. The way it helps with scaling out is that we can use the split-merge tool to shard these databases, and those shards can be part of our pool. So scaling isn't as easy to do with a database as it is with a web app, but Azure makes it pretty easy nevertheless.

Now we mentioned CDNs previously. The Azure content delivery network, CDN, offers developers a global solution for delivering content to clients by caching the content at physical nodes across the world. This allows clients to retrieve the data from nodes closest to them, now that's going to reduce latency and improve transfer times, and the blobs are made available on the CDN for seven days. So to put it another way, blobs have a seven-day time to live, and after this, they're going to be refreshed from the source location. A CDN makes for lower latency for users. However, it is also a highly available way to serve up content.

Okay, next up, let's talk about what options are available for data storage. Data storage is divided up into multiple categories. However, we're just going to look at a few. Now first up, we'll talk about relational databases. We've already seen throughout this course that we have access to Azure SQL, in addition to a lot of different potential databases, that we could run on our own iSVMs. Next up, we have some key/value databases, we have Redis Cache from the marketplace, and then we have again the ability to host our own key/value databases on iSVMs. The next one we'll talk about are document databases. Azure offers DocumentDB, which allows us to store data in a JSON format. And we can also host our own options, such as CouchDB or MongoDB, etc. And then we have unstructured data, such as files. And for this, we can use stored solutions. So we have a lot of different types, and we have a lot of options to choose from for each. I've only listed a few here, but it's worth checking out all of the different available options.

Okay, to wrap up our business continuity discussion, we're gonna be talking about Azure Resource Manager, also called ARM. ARM allows us to use templates that are JSON-based to create sets of resources. This can allow us to very easily create an entire text stack. So ARM templates allow us a lot of flexibility. We can use them for continuous deployment or for disaster recovery amongst many other uses.

Azure makes it easy to get started with ARM because they provide us with a tool to generate templates based on existing resources. And not just the JSON templates, but also options for the command-line or for .NET, PowerShell, or Ruby. So we can easily take these, modify them, and then redeploy. And we can use these to back up a set of resources. So ARM is a fantastic tool, and it's worth investing more time to learn about.

Alright, that's going to wrap up this lesson. In our next lesson, we're going to take a summary of the course and what we've covered so far. So if you're ready to wrap up this course, 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.