Microsoft Azure is an open and secure cloud platform that enables you to build, deploy, and manage applications. With its broad collection of services, it allows you to build with any programming language, tool, or framework, and integrate your cloud-hosted solutions with your existing IT environments.
Azure services fall into three main categories: Infrastructure as a Service (IaaS), like virtual machines; Software as a Service (SaaS), like Azure SQL; and Platform as a Service (PaaS) solutions, like Office 365. This is a collection of offerings that engage IT specialists, developers, and business owners.
The platform is globally present through a network of Microsoft-managed datacenters, distributed around 19 remote regions (as of writing), which facilitate redundancy and rapid recovery. It is a self-service platform where you can provision your resources and scale them elastically based on your own business needs.
It supports various programming languages such as .NET, PHP, Java, Node.js, Python, and Ruby. In addition, it supports a variety of data services like relational databases, NoSQL, and Big Data solutions. It also promotes hybrid solutions and allows you to extend your datacenters to the cloud using virtual networks.
Below is a brief classification for the services offered:
Compute services such as virtual machines and cloud services
Web and mobile services such as web apps and mobile apps
Storage and data services such as blobs, tables, and SQL databases
Hybrid integration services such as queues, BizTalk, and Service Bus
Networking services such as virtual networks and traffic manager
Analytics services such as machine learning
Identity and access services such as active directory and multi-factor authentication
Media and CDN services
Azure also offers management services, like the portal and marketplace, and developer enriching features such as Visual Studio Online and application insights.
Tip
For all services, you can check them out on the Azure documentation website at http://azure.microsoft.com/en-us/services/.
You can also download the service catalog poster from http://azure.microsoft.com/en-us/documentation/infographics/azure/.
Azure Storage is a highly-available and massively-scalable cloud storage platform that is designed to help you build internet scale applications. It is designed to store huge amounts of geo-redundant data with very fast performance. The platform exposes different abstractions of storage services to target different scenarios. This book will cover four service abstractions of storage, which are blobs, tables, queues, and file storage.
These services, like many other services from Azure, are exposed and accessed via REST APIs. Microsoft also provides a set of client libraries built on top of the REST APIs for different platforms like .NET, Android, and Node.js. These libraries facilitate interaction with the storage services, and add additional advanced capabilities like retry logic and asynchronous programming.
Azure Storage enables new scenarios for applications that require scalable and highly available data storage. These include applications such as social networks, video and image serving apps, gaming, medical records, and much more. Consumers will only pay for what they use based on traffic and capacity. Some of the Azure Storage key design features are described in the next sections.
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.
As mentioned earlier, the service offers different kinds of abstractions that are intended to accommodate different data management and storage needs for applications. For unstructured data, there are Azure blobs; for structured non-relational data you have Azure tables; for reliable messaging between applications you have Azure queues; for standard file shares, there are Azure files.
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.
The Azure storage account is the basic block of the storage service. It manages access to the storage resources and provides a unique namespace for them; it also defines how your data will be replicated and made redundant. In order to create a storage account you need a valid Azure. There are various ways to create storage accounts; the easiest way is from the Azure portal (Azure provides a management portal that we will discuss in later chapters). Following very simple steps, you will be asked to provide a URL, choose a desired location for your data, and a replication option. Another option to create a storage account is to do it programmatically by using one of the client libraries.
Tip
For a step-by-step tutorial on creating storage accounts from the portal, see https://azure.microsoft.com/en-us/documentation/articles/storage-create-storage-account/#create-a-storage-account.
In the following sections we shall discuss the basic and essential features of storage accounts. The following figure illustrates Microsoft Azure Storage concepts:
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:
Blob service:
http(s)://<account-name>.blob.core.windows.netTable service:
http(s)://<account-name>.table.core.windows.netQueue service:
http(s)://<account-name>.queue.core.windows.netFile service:
http(s)://<account-name>.file.core.windows.net
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.
Tip
To gain full understanding of how shared access signatures work, have a look at the following link:
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.)
Tip
Downloading the example code
You can download the example code fies from your account at http://www.packtpub.com for all the Packt Publishing books you have purchased. If you purchased this book elsewhere, you can visit http://www.packtpub.com/support and register to have the fies e-mailed directly to you.
Azure Storage is available at several regions around the world, allowing data to be replicated within the same region or to different regions, depending on your selection. The following are the replication strategies to choose from when creating a storage account:
Locally redundant storage (LRS) stores three synchronous copies of the data in a single facility in the same region.
Zone-redundant storage (ZRS) is where data is stored and replicated across multiple facilities, either within one or two nearby regions.
Note
ZRS is only available only for block blobs storage. Also, once you have created a storage account with ZRS, you cannot later change it. Further information can be found at https://azure.microsoft.com/en-us/documentation/articles/storage-redundancy/.
Geo-redundant storage (GRS) maintains six asynchronous copies of the data. Data is replicated the same way as for ZRS, but is then asynchronously replicated to a secondary far region that falls under a separate fault domain, without allowing direct access to it.
Read-access geo-redundant storage (RA-GRS) provides all of the benefits of geo-redundant storage noted above, but it allows read access to data at the secondary region whenever the primary region becomes unavailable.
You can monitor your storage account by collecting metrics for the requests on your services. Metrics are collected to analyze usage and diagnose issues in order to improve performance of all consuming applications.
Transactional information such as ingress/egress, latency, and success percentages is saved for requests and responses on services. Capacity information is also stored to monitor usage. Data in these tables can be accessed using the table service APIs and .Net APIs. The data is read-only and cannot be manipulated or created by the user.
The purpose of this chapter is to introduce you to Azure Storage and make you familiar with its components and features. Through subsequent chapters, we will explore these topics more and dive into developing apps that consume Azure Storage service using the .NET framework. The next chapter will focus on the way this service exposes its functionality to consumers through Service APIs that allow developers to execute operations on the service platform from any client app.
