3. Use ARM Templates to Manage Cosmos DB
So similar to the SQL database section, we’re going to look at what are called Arm templates for Cosmos DB. Now, I’m at the resource group level, and I went into deployments, and we can see the deployment that we made to create the Cosmos DB account. And if I scroll down to the template section, I can see here that there’s a template with one resource in it that’s called database accounts. But I can tell by looking at this that we’ve created the Cosmos DB account, but we haven’t created any databases in it. Remember, we created the account, and then we went into Cosmos DB to create the databases using the user interface. So it actually isn’t a part of this deployment.
So if we go back up to the resource group and go into the Cosmos DB, we can scroll a little bit and we can see export template as this menu item under Settings, and it’s going to generate the template for me in real time. And now this template has four resources in it. We’ve got the database account, which is what we created in the initial deployment. We’ve got the SQL database name “DBOne,” for which I created the user interface. We’ve got the container inside the database called DB One. Guess they go together, and the settings in terms of the throughput are: how many 400 request units per second, etc. Or so, there are four resources that are part of this. So if we were to want to keep a copy of this template, we’d have to generate the template to either download it or save it.
The other thing, of course, is that the template that we created for the initial deployment doesn’t get updated when we make changes to the settings for our database. So it’s for this reason that sometimes people and companies choose to develop their resources as Arm templates, and whenever they need to make a change to them, they make a change to the Arm template as opposed to going into the user interface and making a change live. This is called infrastructure as code. And so we can basically store something like this in our code repository, whether it’s GitHub, or I was going to say that visual source code doesn’t exist anymore, or the Team System, or however you store code. You can store your infrastructure as code using something like Arm templates, but in order to do that, you have to keep the templates updated. So this is how we’ve seen two different ways that we can get the template for this Cosmos DB.
4. Cosmos DB Security
So here we are with our Cosmos DB. And we see here that the database was created in the western United States, which is the California coast, if you will, and it has a publicly accessible URL. When we created this database, we assumed that all networks would have access to it. Now, if we go down to the Firewall and Virtual Networks tab, we can see this setting. Now, let’s say we changed our mind. We don’t want the Internet to have access to it, and we only want a brand new virtual network or an existing virtual network to have access to it. So we can effectively migrate the Cosmos DB from the public Internet to a private network.
And then we can control traffic coming into it using firewalls and various other things. In fact, we can see that a firewall setting is not enabled as soon as we see selected networks. Then we can add an IP address to the firewall. It could be my personal, it could be Arange, or it could be your on-premises networks. We do have the ability to add connections from other Azure locations so that only Azure locations can access this and not the public internet, et cetera. So if I say save, then the firewall configuration with my IP address having a whitelist and all public Azure data centres having access to it becomes the setting. Now, you shouldn’t worry, because even if you have all networks selected or even selected networks, the way that Azure deals with security is through keys. So we have both a primary and a secondary key. If you’re holding either of these keys, you have full and complete access to the database, right? So you have the URL and the primary key. You basically have the store open, and you can do whatever you want with this database. It’s full access. Now, there is the concept of a read-only key. This is a safer option. So if you have an application that doesn’t need to modify the database and only needs to access it, you can use that special key to access it and not expose the full read/write key.
Now, with this key, you’re supposed to keep it close to your chest and not share it with anyone you might not trust. If this key is discovered to be leaked, it is exposed in some way. You can regenerate the key. As soon as you regenerate the key, it becomes invalid, and all applications that rely on that key are basically unable to access it. So at this key that I’ve just regenerated, this existing key has been invalidated, and a new key will take its place in a second here. So even if your Cosmos DB is public and open to the Internet, you need the key to get access to it. And the intention is for you to keep your key private. Now, don’t worry if you’re seeing my keys here. I’m going to be deleting this database as soon as I’m done recording these videos. And so I don’t mind exposing it because I’m assuming it won’t be accessible for very much longer.
5. Cosmos DB Geo-Replication
One of the benefits of cloud databases—whether they are Azure SQL databases or Cosmos DB on-premises databases—is their global reach and how simple it is to replicate those databases globally. If we go into the Replicate Data Settings section, we can see a map with a lot of little blue plus signs on it and one blue check mark that indicates that our current database was created and is running in the Western United States. As we can see on the map, it looks like it’s in California. And so it is actually very easy for us to create one or more copies of this database. Only read copies are available. So I can go to the East Coast of the United States. Clicking on that, I can go to Northern Europe. Clicking on that, I’ve just now set up two copies of my database with read-only access.
If I click Save, it will go off and create those database accounts and databases in the Eastern US. and in Northern Europe. It will then replicate the data from Western United States to those two locations, and it will keep it up to date. As a result, any data we write to the Western United States region is almost instantly replicated to the other two regions. What we would then do is give the URL for these two regions and the two application servers running in those regions. So any servers we have in Northern Europe would use the Northern Europe database. Any servers we have in the Eastern US would use the eastern US. database for read-only purposes. Okay, again, these are copies. And so we are basically tripling our costs. We switched from the — I believe the basic Cosmos DB costs around $20 per month. So we just added 40 more dollars per month to our costs by replicating it two more times. There is also this multiregion write feature, so instead of having one write region and two read-only regions, we can basically have three read and write regions.
Now, this doubles our costs in each of those regions, and so we go from $60 a month to $120 a month for this upgrade. So you can see how easy it is to set up replication. If I click save, Azure is going to go do that. It’s going to take care of everything. And within ten minutes, we’re going to have a replicated database around the world, and we just have to change the connection strings for our applications running in these regions. So that’s why they say this is the big, powerful advantage of databases in the cloud: this ability to replicate globally and just through some simple settings. You’re basically going to increase the performance of your application by having the data closer to the servers and reducing the demand on that single server by having two additional regions that can handle that load.
