VMware should standardise vCloud API between vCloud Service Providers

[rinf]

I had registered with Hosting.com and Terremark for their vCloud Express API. They seem to be the only ones currently exposing their vCloud API currently (correct me if i am wrong). I started playing with the vCloud API from the two service providers. The first thing that hit me was that Terremark seems to have altered the vCloud API.

The first API call itself to get api version have different output.

Terremark : https://services.vcloudexpress.terremark.com/api/versions

Hosting.com: https://vcloud.safesecureweb.com/api/versions

You can try by hitting the browser.

Terremark seems to have omitted Media Type Mappings.

Again, if you go to this link

https://community.vcloudexpress.terremark.com/en-us/product_docs/w/wiki/a-introduction.aspx

It says

"The Terremark vCloud differs slightly from the generic vCloud. The

vDC has the following children that are not part of the generic vCloud

implementation:

• Catalog

• Internet Service

• Public IP "

I thought the point of having a standardised and versioned vCloud API is to have uniformity between service providers so that developers and users can switch between the service providers seamlessly with just a change in Service URL and credentials. Now if i write code to talk to a Terremark vCloud i am not sure it will work in Hosting.com. How will i certify it for a certain vCloud api version? I think VMware should be more strict about the vCloud implementation of the service providers by at least running a huge Test Suite and make sure they adhere to the API and only certify them as VMware certified vCloud once they pass the Test.

[Steve_Jin]

I see your point. I personally used the Terremark vCloudExpress API for last year's SpringOne keynote demo. The Java code was contributed to CloudTools open source project hosted at Google Code. Check out more: http://bit.ly/4pvWZl

You are right that TRMK implementation is slightly different from the vCloud APIs. I think you've made a great point there for standardize different implementations, and that is the direction we should go.

Steve JIN

Author of VMware VI and vSphere SDK (Prentice Hall)

Creator of open source vSphere (VI) Java API

Blog: DoubleCloud.ORG

[BLjellis]

I'm of the same mind - the implementation can be a bit loose, especially when perusing networking configurations

This becomes more evident when you look at jclouds (a cloud Java API) implementations between providers. We've tried to keep the BlueLock vCloud API implementation as close to the Express reference implementation as possible, and I think those providers that keep close to the Express... errr... expression will probably stay true to the original intent.

It's tough because schemas aren't enough to constrain things like network provisioning. If vendor-specific extensions are allowed in future revisions that will likely help a fair deal.