Why do I say this? Well today you have the vSphere API that many vendors are using to integrate and automate many functions when it comes to enhancing VMware functionality. In particular areas such as deployment, backup and replication.
Vendors such as Veeam, Vizioncore, DoubleTake, BMC, Altiris (and many others the list would be long) perform actions through using the well understood VMware APIs. However we know that in the future, and hopefully thats a near term concept, the idea of performing these actions on a local VMware implementation only is going to be limiting.
Tomorrow, organisations are going to want to perform all of the operations they do with these applications with the Cloud, and that Cloud is not going to accept or integrate with those existing API standards. Instead the vCloud API is the mechanism to control external environments outside your organisation. Eventually it may also be the means of manipulating your internal systems as well, your Internal Cloud, or the Community Cloud you have built with other partners.
Lets take replication (closely related to backup) as an example. Organisations will want to deploy a replication destination appliance in the Cloud. Rather than replicating to their own second site, hey now replicate to this appliance within Cloud. Now that its in the Cloud the storage required can be consumed in an elastic, opex manner, capacity planning is all taken care of for you and you are not paying to have the computer power sitting there just incase you need it. DR to the Cloud.
However when you want to recover a machine for a test or for a real recovery scenario all you want to do is click the button in the software and it talks to your cloud provider backend, creating and deploying machines on the fly. Could not be simpler. But remember the Cloud does not support the vSphere API, thats all hidden and under the control of the Cloud provider. If you, the customer, want to manipulate the cloud you need to use the vCloud API, and thats why your software vendor needs to have support for it.
This is more important for the application or OS deployment tools. What destination do you want me to deploy that new server image and application stack to? Do you want it on your internal vSphere environment, then thats the vSphere APIs. Opps not enough internal capacity or the economies for this profile work better in the Cloud, off and deploy it to my federated Cloud, thats the vCloud APIs.
Of course this is a burden on the third part vendors to support another API but much of the operations will be similar. The engineering won't be trivial but there are good parallels between the two sets of operations in each API set.
Will we see the two sets of APIs merge? I don't think so in the short term, there will always be more feature and function that would be available when you control the infrastructure down to the hypervisor layer, even if its your own internal cloud. However over time you could see either more compatibility or merging of the APIs.
I hope VMware are talking to the vendors about this and giving them a good roadmap on future API integration. I also hope more important for the shorter term that that software vendors are looking at the large opportunity this can bring for additional uses and wider adoption of their technology when it comes to integrating with the Cloud. Those early to market might just be able to make a good land grab for themselves.
From my conversations with organisations, they are keen to use the Cloud where its function and economies fit, and they are going to be looking to their software vendors for good support and automaton.
Keen to hear peoples thoughts on this, so post in the comments.
Rodos
Rodos,
ReplyDeleteYou are clearly a lot closer to vCloud than most. Is VMware not supporting backwards compatible APIs between vSphere and vCloud? While the underlying implementation would be complex, providing a compatibility layer so that third party apps could see a public cloud that a customer has operations in as a vSphere cluster would surely smooth the migration path.
Yes and no. The vCloud API is public and has been around since last year, been submitted to the DMTF for becoming a standard.
ReplyDeleteNo they are not compatible, but I do comment that I think eventually we will see them merge. First of there may be a glue layer so you can talk to your internal vSphere environment via the vCloud API but without having to run the actual Cloud platform.
Rodos
The vCloud API is itself a translation layer to the vSphere API is it not?
ReplyDeleteIf so logic would suggest that coding to it when you already support vSphere is a complete waste of time that will only buy you inferior performance.
Sam that is not my understanding. The vCloud API has a number of constructs that are not in vSphere such as organisations and all sorts of things. Of course when you interact with the whatever is the recipient of the vCloud API (such as RW or vCloud Service Director) it is going to use the vSphere API to talk back to the VC/ESX environment. But I don't think you could go as far as saying its simply a transition layer thats adding overhead.
ReplyDeleteRodos
It's certainly possible that it augments functionality but API translators rarely perform well do to "impedance mismatch" (for want of a better term). I think you'd want to do some testing for your application(s) before you made the decision to switch over (at least for applications that already support vSphere APIs anyway).
ReplyDelete