- Microsoft Azure: Enterprise Application Development
- Richard J.Dudley Nathan A.Duchene
- 1294字
- 2025-02-28 10:03:57
The service offering that has commonly been referred to as Azure is actually Windows Azure. For the rest of this book, when we refer to Azure, we'll call it Windows Azure.
Windows Azure is just what it sounds like–it is the operating system part of the cloud, with a few other features. The most inflexible part of the Azure universe is the fact that Windows Azure is not designed to provide customized virtual machines; (custom VHDs are a newly announced offering at PDC10, but are a different service than Windows Azure) we are limited to a 64-bit version of Windows Server 2008. We can create VMs of different sizes (the sizes relate to costs), and the OS is highly configurable, but it must remain Windows.
Windows Azure encompasses two areas of functionality–the compute service and the storage service. The next diagram shows how these services fit into the Azure universe. Additionally, there is an Azure Fabric Agent that connects the VM to the rest of the cloud. The Fabric Controller is a modified version of the Windows Server 2008 Hyper-V hypervisor, which sits in between our VM and the hardware, allowing resources to be used by the VM. There is a service that runs on all VMs, communicating the status of the VM back to the Fabric Controller, allowing the Fabric Controller to monitor for faults. Should a VM communicate a fault, the Fabric Controller can initiate a sequence of events to try and get the VM back to the proper status. This could be anything from a VM reboot to a new VM provisioning.
The compute service can be thought of as the actual application code. Applications are further broken down into web roles and worker roles. Web roles are website applications, whereas worker roles are analogous to services on a local PC or server. Application users interact with web roles, while worker roles perform functions behind the scenes. Worker roles can interact with web roles, but application users cannot directly interact with a worker role (except in one special case, which we'll see later).
Worker roles are a separate entity from the web roles. They are a completely separate VM and act independently of each other. It is possible for a worker role to exist without a web role, just as a web role may exist without a worker role.
For local storage of files (both small files consisting of a few kilobytes to large files up to terabytes) and simple data, we have to rely on the storage services. There are three components to the storage service: blob, table, and queue. Each has its own purpose, and we may use any combination of these components or none at all. Storage services can be used to build a highly scalable system as the amount of data and file storage is virtually endless (though every increase in storage space used comes with an increase of monthly cost). Given the way Windows Azure works, we'll more than likely use at least one of these services in any given application, and our sample application will use all three.
On Windows Azure, the local file system is not persistent, so our application needs to store and retrieve its resources from a floating storage location. Data placed in the storage service is persisted if a VM is shut down or if new VMs are brought online. For safety, all storage service data is replicated three times.
If this sounds unnecessary or confusing, think of the storage service options like a roaming profile. Unlike some cloud computing options, an Azure VM is not dedicated to us or our application. They are more like the PCs in the college computer lab. One day you may find space on one PC, and another day you have to use a different PC. If we saved information on the file system on one PC, we wouldn't have access to it on days where we sat at a different PC, and we probably wouldn't want others to access our files when they use the same machine where we stored them. If we turn our Azure application off and then on again, or switch between a staging and production VM, we're actually changing VMs. We need our information to be available immediately, and preferably without a great deal of work to distribute it – hence, the floating storage service.
Blob is an abbreviation for binary large object. Blob Storage is designed to contain large amounts of binary data such as images, music files, or complete documents and spreadsheets. Blobs are stored in containers, and each container can be up to 50 GB and contain a number of blobs. Up to 8 KB of metadata can be stored with each container in name/value pairs (note that metadata is at the container level, not the individual blob).
If an Azure-based web application displays a logo, that logo will be called from a Blob Storage endpoint, rather than a local file. We could also build a document management system or content management system using Blob Storage. To access a blob, we use a standard REST interface or a .NET client library.
This is the part where people get the most confused with all the Azure options. Windows Azure Table Storage is not the same as SQL Azure. Table Storage is not relational, does not have a defined schema, and does not use a query language for data access. In contrast, SQL Azure is an almost feature complete version of SQL Server 2008.
Table Storage operates more like a hash table or an indexed array. We do connect to table storage using ADO.NET Data Services, and we can also retrieve data through either Linq or REST. Table Storage can be used to store all manner of data, with a capacity of terabytes. Table properties (columns or values) can be strongly typed to a number of data types, and data is partitioned to improve scalability. Despite the large capacity of a table, the total combined size of the properties in a record can be a maximum of 1 MB.
Tables are created and managed programmatically from code we build, and although they seem limited, tables are actually a powerful storage method. A single table in Table Storage can actually contain more data than a single SQL Azure database, and contents can be loaded into generic or strongly types objects for ease of programming.
Queue Storage is unlike the previous two storage services. In Windows Azure, a queue is a holding area for requests waiting to be processed by a worker role. Web roles interact with worker roles by adding requests to the queue. Unlike tables and blobs, which persist data for repetitive use, the Queue Storage is a container for transient data. One example of a common use could be the usage of Queue Storage to deposit messages based on events that occurred. Here, a worker role can pick these messages on a timed interval and perform event-based workflows, coded into the worker role, based on the message contents.
Each Windows Azure account can have multiple queues, and each queue can contain up to 8 KB of metadata in addition to the requests. Queue Storage is accessed via a REST interface, or .NET client library and can be accessed by any client with the correct storage credentials for the account.