The Virtualization Practice

Tag Archive for Cloud

MokeFive Suite is an enterprise desktop management platform that is used to create and administer layered virtual desktop images called ‘LivePCs’ which execute as guests on a type II hypervisor. LivePC images are authored using the MokaFive Creator which also serves as a test platform to simulate and end-users experience. LivePC images can be stored on centralized or distributed file stores. MokaFive also provides support for Amazon S3 storage, which can be of significant value in managing highly distributed environments, or run directly off USB flash drives. MokaFive LivePCs are effectively hypervisor agnostic; support is currently available for VMware’s free Player and the open source Virtual Box. Beta support for Parallels Workstation is new in MokaFive Suite 3.0, and MokaFive’s own bare metal platform will be shipping in Q1 2011.

Red Hat today announced the acquisition of startup PaaS vendor, Makara, which provides a deployment platform for most of the Open Source application stacks onto most of the IaaS cloud infrastructures. Red Hat intends to use the purchased technology rather than the product itelf. It gains additional application-level management, monitoring and configuration functionality for an emerging stand-alone PaaS offering to drive its customers towards a fully RHEL-cloud.

If you are a hyperscale (such as for the Cloud) data center manager, one of your top concerns is always how to get the maximum amount of computing work done per Watt of power consumed. With that in concern at the forefront Cloud Providers like Google, Microsoft, and Facebook have strong incentives to explore new solutions to delivering compute cycles. Rumors coming out of Facebook suggest that it is looking to move away from its current X86 architecture platform in favor of servers based on ARM Holdings Cortex processor range. Porting an entire service to a new processor platform may not appear to be a sensible direction to take but porting to a new architecture is more a financial consideration than a technical one. If the cost per unit of performance justifies it , it is cheaper to pay a few programmers to rework the apps for a new architecture than it is to buy more servers.

Eucalyptus-based solution that is bundled into the Ubuntu installation from 9.10 onwards and allows you to install a IaaS cloud into which you subsequently install Ubuntu Server instances, rather than directly installing an Ubuntu Server. The Eucalyptus proposition is that the cloud you create is identical from an API – and therefore a tooling – perspective to an Amazon EC2 cloud, and the same Ubuntu instances can run inside it, and even can be cloud-bursted out to it. Canonical make a lot of this duality in their positioning of Eucalyptus and the Ubuntu Enterprise Cloud. It feels very-much like an “onramp” message that we hear from VMware.

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.

Does Public or Private make a difference to Cloud Security?

When we talk about Cloud Security, the main concept is to separate, as an example, Coke from Pepsi. This implies that Tenant’s cannot impact the availability of each others data, the integrity of that data, and the confidentiality of that data. But what does this actually mean? Does this apply to all types of clouds in the same way?

There are three types of cloud families: Private, Hybrid, Public. There are at least 3 types of clouds: SaaS, PaaS, and IaaS. Do the same rules for one cloud family work for all cloud families? as well as for the types of clouds?

I believe the answer is yes.

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. 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 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.