Introducing azureQuery: the JavaScript-Windows Azure Bridge

As anyone who follows this blog knows, my twin passions are Windows Azure and modern web development and I especially like combining the two. In this post I introduce a new project-in-the-works called azureQuery, whose purpose is to provide a first-class way for client-side JavaScript to get at Windows Azure. Before going any further, check out a few azureQuery statements to get a feel for it:

// Get a list of containers
var containerList = aq.storage().containers().containerCollection;

// Get a list of blobs
var blobList = aq.storage.container('orders').blobs().blobCollection;

// Store a JavaScript object in a blob
var order = { ... };
aq.storage().container('order').blob('order-1001').json(order);

//  Retrieve a JavaScript object from a blob
var order = aq.storage().container('order').blob('order-1001').json();

// Process each XML blob in a container
aq.storage().container('test').blobs('*.xml').each(function (blob) {
    ... work on blob ...
});

Why azureQuery?

One reason we're developing azureQuery is to give client-side JavaScript easy access to Windows Azure. Microsoft already does a good job of making it possible to get at Windows Azure from a variety of developer environments: if you visit the Windows Azure Developer Center, you'll see there are developer centers for .NET, node.js, Java, PHP, and Python. However, there's nothing for client-side JavaScript. Modern web developers know that a large part of our applications are moving over to the web client side and the role of JavaScript has been elevated: it's no longer just "web glue" but where much of our code lives. So that is one reason for azureQuery, to provide a JavaScript API for web developers.

Another reason for azureQuery is to provide a jQuery-like chaining API. I find jQuery to be simply brilliant, a powerfully-designed API for doing lots of powerful things with elegance and brevity. jQuery is a big inspiration on what we're trying to achieve with azureQuery. Like jQuery, azureQuery has the ability to perform operations on whole sets of things using selectors. Like jQuery, azureQuery is a fluent (chaining) API.

Good JavaScript object support is a key objective in azureQuery. In the blob storage functionality that has already been implemented, you can easily store and retrieve JSON objects to blob storage. We plan to do the same with table storage.


How azureQuery Works

On the web client, azureQuery providea a JavaScript Singleton object named aq using the JavaScript Revealing Module pattern. JavaScript developers invoke functions off of the base aq object to interact with Windows Azure. The library interacts with a server-side service to perform its work.

<script src="~/Scripts/azureQuery.js"></script>
...
var blobsList = aq.storage().container('docs').blobs('*.doc').blobCollection;

On the web server, azureQuery has a matching ASP.NET Web API service that uses the Windows Azure .NET APIs. RESTful URIs are issues to instruct the server.

/api/blob/blobs/?c=docs&b=*.doc&d=true

In an ideal world, this server-side component wouldn't be necessary: you'd just take azureQuery.js and go to town, interacting with Windows Azure's services directly. Alas, Ajax communication from a browser has cross-domain restrictions. This means you have to run some server code to make azureQuery work. The projects you can download from http://azurequery.codeplex.com include both the client-side JavaScript library and an ASP.NET Web API service for the server. It' s possible we'll get around this at some point using JSONP, but for today it is necessary to host a server-side Web API service to make azureQuery work.


Roadmap

The intention with azureQuery is to incrementally build out different functional areas over time.

The first area we're implemented is blob storage, available right now in the azureQuery 0.1 release. You can access containers and blobs, with wildcarding. Operations you can perform on containers and blobs include list, create, copy, and delete. You can store and retrieve blobs as text, byte arrays, or JSON objects.

Next up on the roadmap is table storage, which will appear in the upcoming azureQuery 0.2 release.

Eventually, we plan to include many other functional areas including the management capabilities available in the Windows Azure portal.

We'll be covering each individual area of azureQuery as it comes into being in the successive articles in this series.

You can read about and download azureQuery here. azureQuery is a community donation of Neudesic.


Feedback Appreciated, But Please Be Careful

If you play around with azureQuery in this early stage, be careful. It's new code, so you might be the first to exercise a particular area. It has a lot of power--for example, you could wipe out all your blobs and containers with a single statement:

// delete all blobs and containers
aq.storage().containers().blobs().remove();

azureQuery is also not yet equipped with an out-of-the-box security model, so it's up to you to secure it if you use it at this early juncture.

We'd love to hear feedback as we continue to develop azureQuery, but please be careful in your use of it. We suggest starting out with local Windows Azure Storage Emulator storage, data you can afford to lose.

Stay tuned for more in the series as we go into each functional area of azureQuery.

Windows Azure is a 3-Lane Highway: How to Drive It

With its recent expansion, Windows Azure (Microsoft’s public cloud platform) now supports 3 modes of cloud computing. In this post, we’ll explain the rules of the road using a highway metaphor. Which lane of this 3-way highway should you drive in, and what kind of vehicles are permitted in each lane?

Traditionally, there was one way to use Windows Azure: Platform-as-a-Service (now called Cloud Services). Recently, the platform was greatly expanded to also provide Infrastructure-as-a-Service capability (Virtual Machines) and a special mode for web sites (Windows Azure Web Sites). Let’s point out here and now that although one area of the platform has “web sites” in its name, you can in fact host web sites at all three levels. The table below will give you a quick idea of what kind of apps belong where, after which we’ll take a look at each of these ways to use Windows Azure and compare them.

Windows Azure Web Sites	2-Tier Simple Web Sites • Web sites using open source frameworks • Web sites using SQL DB or MySQL • Web sites that run on IIS: ASP.NET, PHP, node.js
Cloud Services	Multi-Tier Modern Solutions • Stateless VM farms • Run on Windows Server • Where automated management is required • Require advanced functionality such as service bus, identity federation, CDN, traffic management
Virtual Machines	Legacy Solutions • Stateful single VM or VM farms • Run on Windows Server or Linux • Legacy LOB applications • Enterprise server products • Where portability between cloud and on-premises is required

Windows Azure Web Sites: The Fast Lane

Windows Azure Web Sites provides an accelerated way to work in the cloud for modern web sites. It has the automated management benefits normally associated with Platform-as-a-Service and the portability of workload normally associated with Infrastructure-as-a-Service. Unlike the other two modes for using Windows Azure, which support a great diversity of solution types, WAWS is limited to simple 2-tier web sites that can run on a standard IIS configuration. At the time of this writing, WAWS is in preview and does not yet come with an SLA. A certain level of use is free before charges apply.

Why do we call WAWS the fast lane? First of all, provisioning is lightning-quick: you can provision a web site and accompanying SQL or MySQL database in well under a minute—far less than the 10-15 minutes of provisioning time other segments of the platform require. Second, you have high productivity from the get-go because your web developers don’t have to learn anything new or change the way they work. Your web site can run as-is in the cloud. Deployment is a beautiful thing in WAWS: you can use Web Deploy, FTS, Git or TFS. Moreover, you only have to deploy to a single server regardless of how many VMs your site runs on: Windows Azure takes care of distributing deployments out to all instances. Lastly, one other nice speedy aspect of WAWS is that you can provision web sites ready to go with your favorite web framework by choosing from a gallery that includes DotNetNuke, Drupal, Joomla, Orchard, Umbraco, and WordPress.

The reason WAWS deployment is so fast is that it uses a pre-allocated pool of VMs for web serving. By default, you are working in shared mode, which means you are using this pool and sharing your VMs with other tenants. That might sound a little dangerous, but virtual directory isolation keeps your work and that of other tenants walled off from each other. At a higher cost, you can choose to switch over to reserved mode, in which your VMs are dedicated to you alone. In either mode, you can scale the number of instances using the Windows Azure management portal.

What kind of web technologies can you run in WAWS? Anything compatible with IIS, including ASP.NET, classic ASP, PHP, and node.js. WAWS does come with some limitations. Architecturally, you are limited to simple 2-tier web sites that run on IIS with a standard configuration. However, you cannot change the IIS configuration, remote desktop to the VM, or otherwise make changes that might affect other tenants. If you need more than this, such as a third tier for web services, you should look at Cloud Services or Virtual Machines instead.

From a VM persistence standpoint, disk file changes are persistently saved in Windows Azure Storage. However, all VM instances for a site are sharing common storage—so you need to consider file overwrites.

The bottom line: Windows Azure Web Sites provide a fast lane for web sites in the cloud, offering the best attributes of PaaS (automated management) and IaaS (portability) without requiring web developers to change the way the work—but they can only be used with simple 2-tier web sites that can run on IIS in a default configuration.

See my post Reintroducing Windows Azure: Web Sites for a detailed walk-through of this feature.

Cloud Services: Leave the Driving to Us

Cloud Services are the Platform-as-a-Service (PaaS) way to use Windows Azure. PaaS gives you automated management and a large toolbox of valuable services to compose solutions from. 

PaaS can be controversial: some see it as the modern way to design applications that leverage the differences and advantages of cloud computing environments; others view PaaS with concerns about vendor/platform lock-in. Keep in mind, the expense of preserving full cloud/on-prem portability is limiting yourself to the least common denominator of both; that is, not taking advantage of the special functionality available in the cloud.

The cornerstone Windows Azure Compute service which hosts applications uses a declarative model to specify the shape and size of your solution. Although many kinds of software can run in the cloud at this level, including complex multi-tier solutions, this model must be adhered to. Your solution consists of one of more roles, where each role is a VM farm. There are several kinds of roles, including web roles for Internet-facing software and worker roles for everything else. You can connect your roles to each other or to the outside world using load-balanced endpoints or alternative methods such as queues. The VM instances that make up a role are not persistent, meaning you cannot rely on VM state changes (such as disk file updates) to stay around; for persistence you must use a storage or database service. You’ll need at least 2 VM instances per role in order for the 99.95% (3½ 9’s) Compute SLA to apply. Most of the other cloud services give you a 99.9% (3 9’s) SLA.

There are many other cloud services to choose from that provide storage, relational data, identity, communication, caching, traffic management, and more. Many of these services provide extremely valuable functionality for pennies such as federating identity or brokering messages—and they’re managed for you. Most PaaS solutions leverage a combination of cloud services.

The automated management in Cloud Services is very attractive. For the Compute service, this includes automated patching and orchestrated software updates across your VMs. Storage and database services store data with triple-redundancy and have automatic fail-over. The traffic management service can check the health of your applications and fail over from one data center to another when necessary. VM instances and storage units are spread across fault domains in the data center to maintain availability in the event of a data center failure.

Cloud Services do require you to adhere to its model, and sometimes that means designing for the cloud or adapting existing applications to fit the cloud. Sometimes this is a small effort and sometimes it is not. Modern SOA applications based on tiers of stateless VM farms are generally very straightforward to move to Cloud Services. Solutions that have a single-server model, or depend on local VM state, usually require moderate-to-significant changes. These changes can sacrifice portability of your application, especially if you are highly dependent on cloud service functionality not available elsewhere.

Cloud Services provide an SDK and a simulation environment that allow you to develop and test locally before deploying to a cloud data center. To deploy, you must package your solution and publish it to the cloud to a Staging slot or a Production slot. You can promote a cloud deployment from Staging to Production in a fast, one-click operation.

The bottom line: cloud services provide automated management, valuable functionality, and architectural versatility—but apps may need to be adapted to fit its model, and strong dependence on platform-specific cloud services can result in apps that are no longer portable to other environments.

See my post Reintroducing Windows Azure: Cloud Services for highlights of what’s new in this area.

Virtual Machines: Self-Service

Virtual Machines are the Infrastructure-as-a-Service (IaaS) level of Windows Azure. You stand up virtual machines, configure them yourself, and manage them yourself. If you value portability of workload (the ability to move your IT assets between the cloud and on-premises seamlessly) and are fine managing your systems yourself, this lane might be for you. At the time of this writing, Virtual Machines are in preview; however, they do come with an SLA and are not free despite the pre-release status.

Although it comes at the cost of self-management, Virtual Machines provide great versatility. You provision Linux or Windows Server VMs and either compose the VM images in the cloud or upload a VHD you’re previously created using Hyper-V. You can capture a VM and add it your image gallery for easy reuse.

In Virtual Machines, individual VMs are persistent. It’s fine to run just one instance of a VM, you don’t have to worry about losing VM state, and you get a 99.9% SLA. This makes virtual machines the right choice for single-server solutions and server products that use local disk files. You can’t run a product like Active Directory or SQL Server or SharePoint Server successfully in Cloud Services, but you can in Virtual Machines. Virtual machines are also often the best fit for legacy applications.

You can group your virtual machines in a common availability set, which will spread instances across fault domains in the data center for high availability in the event of a data center failure. You can provision load-balanced endpoints to direct Internet traffic to your availability set.

The bottom line: Virtual Machines are for the do-it-yourself IT person (like a driving enthusiast who also likes to work on their car and do their own tuning and maintenance). It's also the only way to run certain kinds of applications, such as single-server stateful solutions and some server products.

See my post Reintroducing Windows Azure: Virtual Machines for a detailed walk-through of this feature.

WAWS, Cloud Services, & VMs Compared

The table below contrasts Windows Azure, Web Sites, Cloud Services, and Virtual Machines.

	WAWS	Cloud Services	Virtual Machines
Level (PaaS/IaaS)	PaaS with the portability of IaaS	PaaS	IaaS
Portability	Fully portable	Design or adapt for cloud	Fully portable
Management	Automated	Automated	Customer Responsibility
Architecture	2-tier IIS web sites only	Versatile	Versatile
Unit of  Management	Web Site	Cloud Service	Virtual Machine
Persistence	VMs share persistence	VMs are not persistent	Each VM is persistent
Provisioning	Under a minute	10-15 minutes	10-15 minutes
Technology platform	Windows Server / IIS	Windows Server	Windows Server, Linux
Deployment	Web Deploy, FTP, Git, TFS	Package and Publish	Compose VMs or upload VHDs
Gallery	Common web frameworks	Microsoft Guest OS images	Microsoft-provided and user-saved VM images
SLA	None during preview	3 9’s / (3½ 9’s Compute) requires 2+ VMs per role	3 9’s (single VM)

Let’s contrast three characteristics that you might care about when using the cloud: automated management, portability of workload between cloud and on-premises, and architectural versatility. As you can see from the magic triangle below, each mode will give you two of the three.

Choice is good, but it comes with the responsibility to choose well. I hope the above has helped to characterize the 3-lane highway that is Windows Azure. Drive safely!