Over the last 6 weeks I’ve had a unique opportunity to try out the European implementation of VCHS (multi-tenant Organisation, not the DC version). It was part of a client exploration of public Cloud and of course there was a particular use case that needed to be satisfied. I’m not going to comment on that use case but only from my personal point of view of the service. During the Beta period it was a VCD 5.1 installation however it recently changed to a VCD 5.5 interface and now allows for the newer features such as the versioning of templates in the catalog.
Firstly there is the interface. Instead of logging in via the regular VCD interface there’s a clean dashboard view which I would suggest is aimed at managers to view consumption of the service and also for novice users who don’t need complicated vApp designs (think fenced networks and multi-tiered vApps) and just want a VM to play with. Frankly as an experienced vCloud techie I just skipped past it and went straight into the VCD interface. As you would expect you’re presented with a regular Organisational view and all the trappings there of. Authentication into VCD is done via the initial VCHS portal which is a bit of a shame as you have to pass through the initial dashboard interface first.
The speed of instantiating a VM seemed snappy and quite usable. There was no way to tell if Fast Provisioning was on for our Org vDC however the test deployments I conducted of one of the VMWare supplied CentOS 6 templates seemed to be on a par with a full clone having been conducted on the back end, taking around 30 seconds before it was ready to be powered on.
From a networking point of view it was simply an implementation of a VCD Edge (in Private Cloud) connecting to another VCD Edge (in VCHS) via an SSL VPN. Very straight forward and quick to implement. The challenge then is to make sure your core network routing tables are setup so that all traffic destined for the VMs in VCHS is relayed back and forth without issue. Not a small task but fairly straightforward for the network guys involved.
From the testing I conducted it was pretty quick to deploy 50 VMs to the point of login within 15mins however it should be noted that the when I deployed all the VMs in one go the backend system seemed to stagger the deployments and not do it all in parallel. This is pretty typical of the behaviour of vCenter when asked to clone multiple VMs at the same time. It implies that the limitations in our private vSphere stacks seem to be the same as in VCHS, i.e. VMWare may not have tuned the cloning process to conduct more clones in parallel. This might have changed when they upgraded to 5.5 at launch so I’m reserving judgement on that one!
From an API point of view you still can use orchestrate via VCO your deployments as the vCloud plugin was as usable in our Private cloud as it was in VCHS. I was executing using the 5.1 schema and there was no obvious issues that caused deployments to fail. Not surprising of course but the box has been ticked on that one. Using vFabric Application Director (vFAD) and setting the endpoint as VCHS caused no discernible difference in deployments other than our private cloud deployments being around 10% faster than VCHS.
My only wish for VCHS was that it was as open to the public to use just as easily as AWS. From what I could see on the VCHS site you must have a member of VMWare’s sales team contact you for access to VCHS. While the service is being obviously targeted to the enterprise user there are guys like myself who would like to hook up their personal private clouds to an external provider on a PAYG basis. I’d happily hand over a credit card and pay a small subscription cost for an Org vDC and then PAYG for any deployed VMs. I can only hope that this will be the logical progression as I think VMWare may miss a trick with Startups and with Dev teams who need to burst into cloud for a Sprint. I’ve seen how small dev teams who, armed with the bosses credit card, can just deploy a bunch of VMs in AWS on a Monday morning and be developing their latest app by lunchtime.
To sum up, I wrote on Twitter (@RossWynne) yesterday:
VCHS is a means to an end, frankly it’s JUST compute. It’s what you do with it that matters 😉
VCHS adds the flexibility of deployment of IaaS components so you can just get on with the job in hand… Running your applications, it just happens to be in the Cloud!