The Virtualization Practice

Tag Archive for Rackspace

Kaviza developers one of the first all-in-one “VDI-in-a-Box” solutions for small and medium business, have been acquired by Citrix. The acquisition adds a fast-track VDI-only solution to the Citrix portfolio geared at the SME/SMB market. The Kaviza “VDI-in-a-Box” product is billed as complementing the Citrix’s XenDesktop product line for enterprise-class desktop virtualization.

The acquisition of Cloudlick by Rackspace points out the need for IaaS cloud vendors to get serious about offering an Infrastructure Performance Management solution to their customers – but fails to deliver such a solution to the customers of Rackspace. Cloud customers should focus upon finding true cloud ready Infrastructure Performance Management and Applications Performance Management solutions as a part of putting performance critical applications in public clouds.

One week after Austin, TX-based Virtual Bridges Inc. announced that IBM is using its flagship VERDE solution to provide virtual desktop management and provisioning capabilities for the IBM Cloud Service Provider Platform, Chelmsford MA based Desktone Inc. today announced two major steps forward on the road to ubiquitous public cloud-based virtual desktops – The release of Desktone 3.0, and its partnership with Rackspace Hosting to provide public cloud-based virtual desktops for just $1 per day.

Rackspace has got the OpenStack governance model spectacularly wrong, and as a result the whole initiative is in peril. Not only are the Chair and the Chief Architect appointed directly by Rackspace, but 3 additional members are appointed directly by Rackspace, meaning that the 4 independently-elected Community members (even if they could agree) could never form a majority. There is actually no need to gain control explicitly. You control by contribution. Since Rackspace contributes most it will gain most control. Rackspace doesn’t actually need control to satisfy its business objectives. ll it needs is to make sure the project is successful and retain enough control over the project to ensure its own needs are met. So our suggestion to OpenStack is to take their Governance model, rip it up and start again.

VMworld is clearly the largest dedicated virtualization conference, and yet from an Open Source perspective it is slightly disappointing because the VMware ecosystem naturally attracts proprietary software vendors, and also some of the more interesting activities in Open Source are through multi-vendor foundations which do not have the same marketing budgets as vendors themselves.

Nevertheless, there are a number of key Open Source players, and some interesting smaller players, represented at VMworld.

Cloud.com had lined itself up with Citrix by using only XenServer in the commercially-licensed version of its IaaS product, and now is being used by Citrix to ensure OpenStack supports XenServer (which it doesn’t at the moment), presumably to keep Red Hat’s KVM under control and VMware out. We’ve also been trawling through the available OpenStack documentation to understand why NASA thinks its cloud is more scalable than Eucalyptus. It seems to be all to do with how the state information is passed amongst the various servers that make up the system. GPL-based Open Core models break down when you move to multi-vendor foundations because the cross-licensing of IPR under GPL immediately infects the recipient codebase, and precludes commercial licensing of the resulting combined work. The result is that the GPL Open Core business model doesn’t work in the same way, and both Eucalyptus and Cloud.com cannot apply their current business model in these multi-vendor foundations. It is a big blow for Eucalyptus. They have turned their biggest potential customer into a massive and credible competitor, built in their own image (only – at least from a PR perspective – much more scalable).

In OpenStack the API is implemented in a separate service which translates external http requests into commands across the internal message bus, and so it looks (on the face of it) possible for someone (preferably Oracle) to implement the Oracle DMTF submission as a separable new API server module without disrupting the OpenStack architecture. In OpenStack the API is implemented in a separate service which translates external HTTP requests into commands across the internal message bus, and so it looks (on the face of it) possible for someone (preferably Oracle) to implement the Oracle DMTF submission as a separable new API server module without disrupting the OpenStack architecture.

Whilst I have been away on vacation, something fairly interesting has happened in the area of Open Source initiatives for Infrastructure as a Service in the form of a new initiative from NASA and Rackspace called OpenStack. You may remember in our last post in this area, we noted that there was a proliferation of offerings in the IaaS space, and it was in the customer’s best interest for there to be effective migrateability (or even mix and match) amongst public and/or private clouds. However, the API standards to support interoperability are proving elusive.