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'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 could 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 gonna 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 gonna 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 gonna 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 17 hundred and 50 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 gonna click on pricing tier, and select the option that we want. With this, we can scale up or down very easily. Here, I'm gonna select S1, and we'll click okay. 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 gonna have the same configuration and the same software. With a SQL database, you have to deal with data.
So, if you just add a bunch of databases, then you would 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's hole.
There's a lot to consider here. However, what we're gonna 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 gonna 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 gonna 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 mentions 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 gonna 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 gonna be refreshed from the source location. A CDN makes for a 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 gonna look at a few.
The 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, et cetera.
And then we have unstructured data such as files. And for this, we can use storage 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 gonna wrap up this lesson, in the next lesson, we'll cover Web API, so, if you're ready to keep learning, then let's get started with the next lesson.
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.