JimMoyle.com

So the recent furore around Wikileaks has got me thinking about the cloud in a slightly different fashion.  I have always said that one of the big issues with the cloud has to be that you are no longer a big fish where it concerns the infrastructure that your data or applications reside upon.

If you own and run your own infrastructure then you are the biggest fish around when it comes to safeguarding the integrity of your applications and data.  It only takes the CEO to say ‘Jump’ once and everybody in the IT department starts asking ‘how high?’.

If you are a tenant on a shared service in the more traditional sense you may still be the biggest customer and you still may find yourself in the driving seat.

If we start to look at the biggest providers of all, namely Amazon and RackSpace, you are no longer a big fish in fact you will in all probability be a minnow.  Amazon have kicked wikileaks off its servers in response to political pressure, using violation of their Terms of Service as an excuse.

This is the relevant section from their ToS:

11.2. Applications and Content. You represent and warrant: [...] (iii) that Your Content (a) does not violate, misappropriates or infringes any rights of us or any third party, (b) does not constitutes defamation, invasion of privacy or publicity, or otherwise violates any rights of any third party, or (c) is not designed for use in any illegal activity or to promote illegal activities, including, without limitation, use in a manner that might be libelous or defamatory or otherwise malicious, illegal or harmful to any person or entity, or discriminatory based on race, sex, religion, nationality, disability, sexual orientation, or age;

This seems to be needlessly vague and could, in fact, be made to apply to any client.  So what is being made clear is that if you use the cloud, you can be kicked off the service on a corporate whim.  The fact that you are now a minnow means that there is no longer any pressure on the hosting organisation to care about you at all.

This does not just apply to highly politically controversial sites, it means if porn or nudity rules are tightened, childbirth or anti-rape sites, or the Scunthorpe tourist board could be taken down.  It also doesn’t just apply to accidental inclusions, any change of the ToS could mean that you no longer qualify to use the service.

What does this mean?  Well I’d say the old adage of if your data doesn’t live in three places it doesn’t exist might well apply here.  ie use more than one cloud provider and duplicate your data.

The trouble is, if you use the above theory, it completely negates one of the big cloud advantages: Their backup, uptime and data retention policies to ensure the safety of your data are world class so you don’t have to bother.

Whatever the politics around Wikileaks, the willingness of the biggest provider to so publically drop a client, with no recourse, has to make everyone think again before moving into the cloud.

With the release recently of the Amazon workflow studio library for Citrix’s Workflow Studio product, one of the major pieces fell in to place to enable us to cloudburst XenApp into the EC2 cloud.  Now it’s here I want to have a look at whether we now have all the tools we need to start putting this into practice.

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.