Microsoft Azure: Enterprise Application Development

Straight talking advice on how to design and build enterprise applications for the cloud

• Build scalable enterprise applications using Microsoft Azure
• The perfect fast-paced case study for developers and architects wanting to enhance core business processes
• Packed with examples to illustrate concepts
• Written in the context of building an online portal for the case-study application

Blobs in the Azure ecosystem

Blobs are one of the three simple storage options for Windows Azure, and are designed to store large files in binary format. There are two types of blobs—block blobs and page blobs. Block blobs are designed for streaming, and each blob can have a size of up to 200 GB. Page blobs are designed for read/write access and each blob can store up to 1 TB each. If we’re going to store images or video for use in our application, we’d store them in blobs. On our local systems, we would probably store these files in different folders. In our Azure account, we place blobs into containers, and just as a local hard drive can contain any number of folders, each Azure account can have any number of containers.

Similar to folders on a hard drive, access to blobs is set at the container level, where permissions can be either “public read” or “private”. In addition to permission settings, each container can have 8 KB of metadata used to describe or categorize it (metadata are stored as name/value pairs). Each blob can be up to 1 TB depending on the type of blob, and can also have up to 8 KB of metadata. For data protection and scalability, each blob is replicated at least three times, and “hot blobs” are served from multiple servers. Even though the cloud can accept blobs of up to 1 TB in size, Development Storage can accept blobs only up to 2 GB. This typically is not an issue for development, but still something to remember when developing locally.

Page blobs form the basis for Windows Azure Drive—a service that allows Azure storage to be mounted as a local NTFS drive on the Azure instance, allowing existing applications to run in the cloud and take advantage of Azure-based storage while requiring fewer changes to adapt to the Azure environment. Azure drives are individual virtual hard drives (VHDs) that can range in size from 16 MB to 1 TB. Each Windows Azure instance can mount up to 16 Azure drives, and these drives can be mounted or dismounted dynamically. Also, Windows Azure Drive can be mounted as readable/writable from a single instance of an Azure service, or it can be mounted as a read-only drive for multiple instances. At the time of writing, there was no driver that allowed direct access to the page blobs forming Azure drives, but the page blobs can be downloaded, used locally, and uploaded again using the standard blob API.

Creating Blob Storage

Blob Storage can be used independent of other Azure services, and even if we’ve set up a Windows Azure or SQL Azure account, Blob Storage is not automatically created for us. To create a Blob Storage service, we need to follow these steps:

1. 1. Log in to the Windows Azure Developer portal and select our project.
   2. After we select our project, we should see the project page, as shown in the next screenshots:

1. 1. Clicking the New Service link on the application page takes us to the service creation page, as shown next:

1. 1. Selecting Storage Account allows us to choose a name and description for our storage service. This information is used to identify our services in menus and listings.

1. 1. Next, we choose a unique name for our storage account. This name must be unique across all of Azure—it can include only lowercase letters and numbers, and must be at least three characters long.

1. 1. If our account name is available, we then choose how to localize our data. Localization is handled by “affinity groups”, which tie our storage service to the data centers in different geographic regions. For some applications, it may not matter where we locate our data. For other applications, we may want multiple affinity groups to provide timely content delivery. And for a few applications, regulatory requirements may mean we have to bind our data to a particular region.

1. 1. Clicking the Create button creates our storage service, and when complete, a summary page is shown. The top half of the summary page reiterates the description of our service and provides the endpoints and 256-bit access keys. These access keys are very important—they are the authentication keys we need to pass in our request if we want to access private storage or add/update a blob.

1. 1. The bottom portion of the confirmation page reiterates the affinity group the storage service belongs to. We can also enable a content delivery network and custom domain for our Blob Storage account.

1. 1. Once we create a service, it’s shown on the portal menu and in the project summary once we select a project.

1. That’s it! We now have our storage services created.

We’re now ready to look at blobs in a little more depth.