Get an introduction to the Microsoft Azure cloud storage service known as a storage account, and learn about the various storage services encompassed by the storage account. Explore the contrast between Azure Storage and the broader family of relational and NoSQL storage options generally referred to as databases, as well as learn about the pricing and documentation websites.
- [Instructor] Microsoft Azure Storage is a cloud-based service for persisting and retrieving data, so storing and reading objects of various kinds through the cloud infrastructure. An Azure Storage account is the element that you will see in the Azure Portal. The resource manager creates Azure storage account resources and it is the configuration element where we will start for creating storage elements like blobs, tables, queues and file shares. There are two different kinds of storage accounts.
One is considered a general purpose storage account. A general purpose storage account gives you all of the capabilities of blobs, tables, queues, disks, file shares, and so forth, and they come in two flavors. One is premium, as a general purpose storage account, which is backed by SSDs. So for the blobs that contain our disks, specifically the virtual machine, virtual hard disks, we can have them placed on solid state storage, or premium storage, where we get the best possible performance. There's also a standard variation which is for traditional spinning magnetic disk types of drives, and it's also what we will use most of the time for blobs, queues, tables, when we just have a general purpose use case.
The other type is blob specific storage accounts. So when we don't need all the other capabilities, if we only want blobs, then we can create a storage account specifically of type blob storage, and so then we get specialized capabilities for blobs like tiering. Tiering means that we can change the tier of the blob so that we can control what kind of cost implications we have based on our application's usage patterns. So we have hot, cool, and soon archive tiers. And so we can design for whether we have frequent access, we want to cost optimize for that, or whether we have long term storage, and we'd like to cost optimize for that.
So Azure storage accounts have different APIs for talking to the storage subsystem. And there are essentially five options for us as developers. We have blobs, so binary large objects. So these are files of various kinds, media files, documents, stuff like that that's considered unstructured. We have table storage where the API gives us a way of working with structured data. And this is essentially a NoSQL database. We have queues, which is essentially messaging for applications or email between applications.
And we have files, a traditional file share, it looks very much like a network file server, and so we can easily migrate applications that require file shares into Azure by just using Azure file storage. There is also Azure storage disks. So for use from inside a virtual machine, you can actually create a virtual hard drive in Azure storage and attach it to a virtual machine and it behaves exactly like a virtual hard drive. So Azure storage blobs is a highly scalable store for unstructured data.
So of massive scale, millions of objects, hundreds of terabytes worth of storage, and the key thing here is that if we pick a specialized blob storage account, then we can control the tiering, the hot, cool, or archive mode of individual blobs. Azure storage tables is a NoSQL and schemaless key-value store. So if you're comfortable with NoSQL databases, then Azure storage tables would be quite comfortable. But essentially it means we're storing structured data, and we're storing that structured data in the table API where we have the capability to then query or make updates to that data.
Now currently in preview there is the Cosmos DB, which is a multi modal, meaning data structures of different kind or APIs to data of different kind, all put into one. And the table API, which looks exactly like Azure storage tables, will be a part of Cosmos DB. So in addition to a schemaless key-value store, a NoSQL table API, we will also get column family documents, graph APIs, and such things. So it's worth looking at Cosmos DB, especially if you've previously used document DB or Mongo DB, or in this case now, the table API.
Azure storage queues is essentially messaging for applications. If you think of applications communicating with each other in the same style of email, so asynchronously by message passing, then Azure storage queues is that messaging for applications. It is durable, in that messages are, in fact, stored. And we follow the typical queueing semantics of enqueueing a message, or adding it to a queue, and dequeueing a message by reading a message, retrieving a message from a queue. It does support significant parallelization, so we can actually have multiple clients reading and adding messages to and from queues.
And it's a great pattern for decoupling components, so the idea of having an application sending messages to another application without both applications having to be available at the same time or even able to communicate at the same rates. Azure storage files is quite literally a network share in the cloud. So an SMB, a server message block, file share, what you're used to of Windows where you say net use, or on Linux the CIFS file shares, CIFS file shares. So whether you call it a file share, or a network share, the idea of using a network available file sharing service, this is available in Azure storage files.
And because it supports SMB, you can take traditional applications or legacy applications that today depend on file shares and move them as they are into the cloud without having to build your own file server. There are some limitations, it's not exactly identical to SMB, and there are no access control lists in the active directory user sense. So some commands are unavailable. But in addition to the SMB protocol, you do get a REST API. So with these limitations, you can sometimes get even better outcomes by combining the rest API with SMB if you're building a new application or if you're migrating an application.
Azure storage also has a type of blob called a page blob, as opposed to a block blob. Aure storage blobs are generally block blobs. In this case we're talking about a page blob in the same sense of having pages on disks. So page blobs are quite literally for storing virtual hard drives, the virtual disks used by virtual machines. And so they are essentiallY classic, in the sense that Azure storage has the ability to store virtual disks, or they could be managed, in that virtual disks can be managed and so then you don't have to care about which storage account it's on or whether it's competing for resources with other disks or anything like that.
So you will see classic or unmanaged disks in Azure storage accounts from time to time. When you are using virtual disks you'll be aware of the distinction between premium and standard, premium being SSD based or having the high performances disks, and standard being the traditional spinning magnetic platter disks. All Azure storage is triple replicated in the local data center. And that's particularly important for virtual machines. So as the virtual machine is running and you write to disk actually goes to three storage nodes.
This means that your Azure storage, and in this case Azure storage disks in particular, are essentially in something equivalent to a ride volume. So you can be assured of durability. And if you want you can have further replication, ger redundant or similar. Now Azure storage was one of the foundational services, and the first ones available with Azure, but that's not the only service. So do still consider things like Azure SQL, Redis, and so forth because these database systems provide additional layers of services, or higher level abstractions.
So whether it's asset transactions or full tech search or any of these capabilities, you might still be interested in database management systems in addition to just raw storage. Azure storage is surprisingly affordable, especially given the performance we can get out of it and the scale that comes with it. But you do have to plan for the cost of using Azure storage. And so you have to be aware of the Azure storage types and the cost implications for that. The degree of redundancy you select has an impact on the cost. And also the region might impact the cost of your storage.
Typically though, the major component is the size of what you consume in terms of storage, so the price per gigabyte essentially. But given that you are a developer, you will know how you are going to access that storage. So the access type, the access patterns, the operations you do on that storage element, that will also have an impact on pricing. Bear in mind that bandwidth is billed separately, so you'll look at a storage account and its costs and the major factor will be the size, the operations on it, those two, of course, will have a multiplication factor in terms of the redundancy you've selected and so forth.
But what you might not see very obviously on the storage account itself is the flow of data in and out of Azure, which is billed separately. So when you do your cost of ownership calculations, bear these factors in mind, and take a look at the online storage pricing in addition to the storage calculator, and remember to have both bandwidth and the storage account itself in your calculations. So in this course we will look at Azure storage from a developer's point of view and spend a lot of time in code looking at the blob API, queues, tables, and files.
- Azure Storage overview
- Azure Storage security
- Deploying Azure Storage
- Accessing Azure Storage files
- Passing messages with Azure Storage queues
- Storing unstructured data with Azure Storage blobs
- Storing structured data in Azure Storage tables (Cosmos DB)