The Nickel Tour of Azure : Explaining Azure to the managers

Explaining Azure to the managers

We aren't all graced by management with a strong technical background, and yet they need a deeper dive into the shallow end to achieve a win-win situation and obtain senior management buy-in to leverage this new platform. Sometimes, it's like you actually do work in the same office as Dilbert.

As we mentioned before, Microsoft Azure actually refers to a menu of services offered by Microsoft; each of these services is contained in the Azure Fabric. The Azure Fabric is essentially every piece of hardware and the software that monitors and controls the hardware. Every server, every firewall, every load balancer, failover services in the event of a failure, the Azure portal where we provision and deploy our application, create and check the health of our current services they're all part of the Azure Fabric. Fabric in this case has a very large definition as far as the Azure universe is concerned, the Azure Fabric is the continuum of space and time.

The three items on the Azure menu are Windows Azure, SQL Azure, and the AppFabric. The following diagram shows how these items interrelate with one another, as well as with applications and databases separate from Microsoft Azure.

One of the most interesting features of Azure is the support for a number of languages and web servers. Many people mistakenly think that because Azure is a Microsoft offering, its usage is limited to .NET and IIS. Nothing could be further from the truth! In addition to .NET 4.0 (including .NET 2.0, 3.0, and 3.5), Azure also supports PHP, C++, and Java, as well as Ruby and Ruby on Rails. There is also choice in the databases and development environments. Web servers include IIS, Apache, and Tomcat; databases include SQL Server (via SQL Azure) and MySQL; and development tools include all versions of Visual Studio 2008/2010, Visual Studio Web Developer 2008/2010 Express, and Eclipse that's a lot of choice! SDKs, toolkits, and plugins are provided for the more common options and others are being developed. Azure supports .NET 4, ASP.NET MVC and Silverlight, and new features are being added in an ongoing basis.

Microsoft has an expanding number of data centers around the world. For compliance purposes, you can select the data center in which your application will reside, or locate your application close by to take advantage of regional prices. Your application is replicated multiple times across the data center of your choosing; so, if there is a hardware failure on the primary instance, the load balancer will direct the traffic to an instance that is alive and healthy!

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.

Compute service

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.

Storage service

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 Storage

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.

Table Storage

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

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.

Azure Fabric Agent and Controller