So what is cloudbursting and why would you want to do it?  Cloudbursting is the ability to expand your existing datacenter infrastructure into the cloud.  This could be useful at times of high demand, for instance seasonal peaks around Christmas, or if your existing infrastructure loses capacity in a disaster recovery situation.

One of the major stumbling blocks on the way to widespread acceptance of utilising cloud infrastructure is the fear in the eyes of many executives of losing control of their data.  What happens when your critical data is stored on someone else’s infrastructure?  Is it secure?  Is it reliable?  Is the support good enough?  What are the response times?  Can you believe the providers when they say you don’t have to worry about your fears?

This is why a XenApp workload is particularly suitable to cloudbursting, there shouldn’t be any data stored on XenApp servers.  Also they should all be identical, making them conducive to fast provisioning.

Imagine the situation of a sales call center, over the xmas period they hire temp staff to cope with extra demand, as their software is provided via XenApp, the company needs to have enough infrastructure to cope with the demand peak, but sits idle most of the year.  As EC2 charges per hour then the ability to use EC2 to cope with the extra demand could save large sums of money.

Now we have decided that cloudbursting is a good idea, can we actually do it?  By this I mean are the tools available off the shelf, without a large development effort.

So what do we need?

• A secure link between the cloud and your datacenter
• The ability to quickly provision and decommission servers in the cloud
• WAN acceleration between the cloud and you
• Monitoring to know when to cloudburst
• Automation to control it all

Lets take these needs one by one:

A secure link between the cloud and you, currently Citrix provide an Amazon Machine Image (AMI) template for Citrix Access Gateway (CAG) with one in the cloud and one in the premise you can have a secure channel between the two. You could also use the Vyatta AMI.  Full marks

With the new workflow studio library we can quickly provision our own saved AMI’s and destroy them when needed.  The question here is why are we not using Provisioning server?  It would be best to provision a ‘bare metal’ server and PXE boot to receive a provisioning server vdisk. So Half marks.

WAN acceleration is possible, you can install the software repeater client on the XenApp servers, but a proper Repeater AMI would be better. Half marks again

Monitoring could be done either with Edgesight or the power and capacity management feature, so full marks.

Automation is the big problem, although workflow studio, now it’s 2.0 with more libraries, is getting there, at the moment it simply doesn’t have enough pre-configured workflows or libraries to cope.  We need a way to join the Servers to the domain and farm and publish the applications. (Although XenApp 6 will let us do this using GPO’s). We could script this, but I want to do it without any dev work. It also needs to be able to take in the output from the power and capacity management feature set.

So where does that leave us?  I’d say it leaves us almost there, in fact with a little powershell knowledge and using the tech preview of XenApp 6 it’s possible right now.

If I have time over the holidays I think I’ll try and set it up and let you know how I get on.