Today, the predominant public cloud is Amazon's AWS, so for us it seems natural to choose that API as the first API for us to do. We can do others, it's possible for Eucalyptus to support other public cloud APIs on-premise, but overwhelmingly at the moment what we see in terms of opportunity is the ability to allow on-premise resources and public cloud resources to interoperate via the same API.

Another reason is a great deal of fear of lock-in in the space. Whenever one develops one's own API, unless it's for something that is open source where it can't really go away, there's some fear that the vendor that supplies the software that has that API may have an advantage and may be able to lock-in a customer. It's early days for the cloud, there's a lot of trepidation over lock-in.

The fact that Eucalyptus is open source and supports an API that is also supported by Amazon, which means the source code is available and Amazon which is substantial and not going away, can back stop your development on-premise and vice versa. I think that familiarity is another reason why the Amazon AWS API turned out to be a good choice.

What plans are on the horizon for Eucalyptus?

What we see with this particular product offering ... is a step towards the direction of a Eucalyptus platform that allows you to combine multiple virtualization technologies. The first product is Eucalyptus on vSphere, but there's really no technical impediment (other than engineering time) to allowing you to combine virtualization technologies within the same cloud -- open source and propriety and different features sets, this kind of thing.