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
Posts
5 comments: