Microsoft Azure Storage Essentials: Harness the power of Microsoft Azure services to build efficient cloud solutions

Azure Storage allows you to store petabytes of data, which will always be replicated to multiple locations. Microsoft guarantees 99.9 percent availability of the data when requested through SLAs, a topic we will discuss later. The periodic replication across geographically dispersed locations also ensures data recovery protection against disasters like earthquakes, fire, and so on.

The service is designed to support a strong consistency model, which means that updates on the data are directly reflected to all replication locations where data is distributed. That is opposed to eventual consistency models that propagate changes eventually and not directly. The ability of Azure Storage to be highly available, strongly consistent and distributed is due to the advanced layering system and the design implemented in the storage platform.

The major goal for the service is to enable the storing of massive amounts of data. For this, the service implements a global namespace, which makes access to the data consistent for consumers from any location in the world. You can scale to arbitrary amounts of data over time without worrying about where this data is stored and how it should be accessed.

Blob storage provides a massively scalable object store in the cloud. This includes objects such as documents, large log files, backups for computers, databases, videos, and so on. Blobs are placed inside containers that can contain many of them, not exceeding 500 TB.

There are two types of blobs: block blobs, which are perfect for storing objects that might be streamed and used by applications like media files and documents. The other type is page blobs, which are optimized to support random writes like virtual hard disk drives.

Tables offer a highly available and scalable option for applications to store semi-structured datasets. They are ideal for apps that require a non-relational, flexible data schema like user, device, or any other type of metadata.

You can store key/attribute entities inside tables; tables are schema-less, meaning that you can store different types of datasets inside the same table, which allows to rapidly adapting to data changes in applications.

A NoSQL cloud store is currently being used by several types of applications that do not require relational databases. Data can be accessed using the standard REST interface and OData protocol for querying.

Queue storage provides a reliable, low-latency and high-throughput messaging system. You can decouple components to create more flexible apps that are less sensitive to individual component failures by buffering operations into queues. Also, this allows you to handle traffic bursts by saving operations and not dropping them. It allows scheduling of asynchronous tasks such as large data operations or simply sending emails.

File storage provides cloud-based file shares allowing legacy applications to make use of the cloud, which provides them with mounted shares. File storage can be used to store data that needs to be accessed by virtual machines, such as configuration and installation files. You can create shares and under them create directories and files, all of which are accessed via a REST API along with the standard file access protocol SMB, which we shall discuss later.

As mentioned earlier, each storage account has a unique global namespace, which allows clients to address the service resources. The storage account is a part of this namespace that represents a URI that can be called via simple HTTP and HTTPS requests.

Thus, all data is accessible via the following endpoints:

The account name <account-name> is selected by the user creating it and should be unique among all other storage accounts. This name will be used by the platform to locate where the data is stored in order to route incoming requests.

By default, and for the security of your data, all requests to the storage service must be authenticated. To do this, the platform generates two access keys for each account that should be supplied for authentication. The owner of the subscription can regenerate any key at any time. By having two access keys, the user can use the second key to authenticate while generating a new one, so that no downtime or interruption will occur to the service.

It is recommended you do not share the access keys with other users; they should be kept safe. In order to allow other users to access your data, you can create Shared Access Signatures (SAS). These signatures can be generated for a specific set of resources with a specific access permission for a definite amount of time.

You can also give public read access to blob storage in containers. When a container is set to public, anyone can read the data without authenticating the request. This is perfect for public media files such as images, documents, or videos on websites. (Users will still need valid storage access keys to write or delete data, however.)