Cloud Computing for IT Pros (3/6): Windows Azure Computing Model

Technorati Tags: service,cloud,azure,fabric,saas,paas,iaas

The series focusing on cloud essentials for IT professionals includes:

• Part 1: What Is Service
• Part 2: What Is Cloud
• Part 3: Windows Azure Computing Model
• Part 4: Fabric Controller and AppFabric
• Part 5: Publishing Windows Azure Application to Public Cloud
• Part 6: Building Private Cloud of IaaS

In Part 2, I basically said cloud is to provide “Business as a Service” i.e. making a targeted business available on demand. In digital commerce, much of a business is enabled by IT. Therefore, cloud is to  in essence deliver “IT as a Service” or IT available on demand, i.e. anytime, anywhere, on any device. This is what we want IT to become via cloud. Realize that “on-demand” in the context of cloud computing also implies a set of attributes as describer in Part 1 including: ubiquitous network access, resource pooling, pay per use, and so on.

Nonetheless, IT is not about implementing technologies which is a means and not the end. All the infrastructure, servers, desktops, SaaS/PaaS/IaaS, public cloud, private cloud, etc. is about one thing and one thing only. That is to provide authorized users “applications” so that with which transactions are made and businesses are carried out. Either in the cloud or on-premises, it is about applications. So, how is a cloud application different than a traditional one? If so, in what way as far as IT pros are concerned. 

Traditional Computing Model

A typical 3-tier application includes front-end, middle-tier, and beck-end. For a web application, the front-end is a web site which presents an application. Middle-tier holds the business logic while connecting to a back-end where the data are stored. And along the data path, load balancers (LB) are put in place to optimize performance, as well clusters are constructed for high availability. This analytical model is well understood and modeled. And the 3-tier architecture represents a mainstream design  pattern for applications recently developed prior to the emerging cloud era. The concept is illustrated below and some may find there are some similarities to the idea applicable to architecting a cloud application.

Cloud Computing Model

Microsoft Windows Azure abstracts hardware through virtualization and provides on-demand, cloud-based computing, where the cloud is a set of interconnected computing resources located in one of more of data centers. Generally speaking, like a 3-tier design there are 3 key architectural components of a cloud application based on Windows Azure: Compute, Storage, and Fabric Controller, as shown below. In this model, Compute is the ability to execute code, i.e. run applications. Storage is where the data resides. In Windows Azure, Compute and Storage are defined with Roles, and offered as system services. A Role has configuration files to specify how a component may run in the execution environment. While Fabric Controller is a subsystem which monitors and makes decisions on what, when, and where to run and optimize a cloud application. I will talk more about Fabric Controller in Part 4 of this series, meanwhile here let’s examine more on Compute and Storage components.

Specifically, in Compute service, there are Web Role, Worker Role, and VM Role. Web Role implemented with IIS running in a virtual machine.is to accept HTTP and HTTPS requests from public endpoints. And in Windows Azure, all public endpoints are automatically load balanced. Worker Role on the other hand does not employ IIS, is an executable for computation and data management, and functions like a background job to accept requests and perform tasks. For example, Worker Role can be used to install a user specified web server or hosting a database as needed.

Roles communicate by passing messages through queues or sockets. The number of instances of an employed Role is determined by an application's configuration and each Role is assigned by Windows Azure to a unique Windows Server virtual machine instance. An employment of Windows Azure computing model for a real-life shopping list application is shown below. The actual development process and considerations are certainly much more, as discussed elsewhere.

On the other hand, VM Role is a virtual machine. A developer can employ VM Role (namely upload an OS image in VHD) to run Windows services, schedule tasks, and customize the run time environment of a Windows Azure application. This VHD is created using an on-premises Windows Server machine, then uploaded to Windows Azure. Once it’s stored in the cloud, the VHD can be loaded on demand into a VM role and executed. Customers can and need to configure and maintain the OS in the VM role. The following outlines the methodology.

Do keep in mind that VM Role is however stateless. Specifically, VM Role is designed to facilitate deploying a Windows Azure application which may require a long, fragile, or non-scriptable (i.e. can-not-be-automated) installation.This role is especially suited for migrating existing on-premises applications to run as hosted services in Windows Azure. There are an overview and step-by-step instructions readily available detailing how to successfully deploy Windows Azure VM Role.

The other component in a cloud application is Windows Azure Storage services with five types of storage including:

• Binary Large Object (BLOB) for long-term data
  • It is a binary object with <name, value> pair metadata.
  • Each BLOB can be up to 50 GB and replicated three times for reliability.
  • BLOBs are grouped into logical containers and can be accessed from any server or by a URL over the Internet.
• Table for structured, namely entity-based, storage that can be queried
  • A table can have millions of rows and columns and is replicated three times for reliability.
  • It is partitioned by rows and distributed over storage nodes in Windows Azure.
  • Tables are not full SQL tables since there is no join operator.
• Queue for reliable message-based communications between services

And within a Compute node, there are two types:

• Windows Azure Drive, or X-Drive as shown on the right
  • X-Drive  is a page blob and formatted as NTFS single-volume virtual hard drive.
  • A single Role instance can mount a X-Drive in exclusive read/write mode or many instances can mount a single X-Drive in read-only mode. The two options however can not be combined. Typically, one instance mounts an X-Drive in read/write mode and periodically takes a snapshot of the X-Drive. This snapshot can then be simultaneously mounted in read-only mode by other instances.
• Local disk available to each Windows Azure Role in a VM
  • Data stored in a local drive of a VM is however not persistent since a Role does not always get configured and reloaded, as needed, on a particular node.

There are tools to facilitate managing Storage instances. A graphical UI like Azure Storage Explorer can make managing and viewing stored data a productive experience. Notice the above mentioned storage types are however not relational databases which many applications are nowadays built upon. SQL Azure, part of Windows Azure platform, is SQL in the cloud. And for DBAs, either Microsoft SQL server on the ground or SQL Azure in the cloud, you manage it very much the same way.

A example of using Windows Azure storage is presented with the following schematic. This is a hosted digital asset management web application. It uses a Worker Role as the background processor to generate and place images into and later retrieve by Web Role as the front-end from the store implemented with Windows Azure BLOB services.

In summary, much of our architectural concepts of a traditional on-premises 3-tier application is applicable to designing cloud applications using Windows Azure’s computing model. Namely, employ Web Role as front-end to accepting HTTP/HTTPS requests, while Worker Role to perform specific tasks like traditional asp.net services. There are various types of storage Windows Azure provides. There is also SQL Azure, Microsoft SQL Server in the cloud, making it convenient to migrate existing data or integrate on-premises databases with those in the cloud.

[To Part 1, 2, 3, 4, 5, 6]