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
The Azure Fabric Agent is one
of four things that have "fabric" in their name in the Microsoft Azure
menu. The Windows Azure Fabric is part of the overall Azure Fabric, and
is an interface between the Azure Fabric Controller and the individual
VM and the VM's contents.
