A couple of important considerations for interoperability are the application and data.  Specifically:

Data – not only do we have to discuss application portability, but also have to port the data. you may have noticed it is easy to import, but hard to export. The data world is very “sticky”. One of the biggest issues the US government is having with adopting Google apps – They want to know the format of the data, so if they ever decide to migrate away from google apps, they can do it.  One possibility is have multiple copies of the data.

Application – the application that uses the API’s of the cloud provider has to seamlessly migrate to new chosen one. For anybody that has taken a look at the API of a couple of providers, you will notice that there is no significant overlap!! The providers built their API’s based on use cases and for now believe that they are going after different use cases/audiences. Even if this converges, it will be very hard to get the cloud providers to collaborate on a standard API. Standards have the ‘potential’ of further commoditizing their business, which already has low margins. One possible approach would be for the industry to accept a defacto standard.  But for that to happen, the providers have to start believing that they are going after the same use case/audience.  Another possible approach is to have a standards body define a standard. this one is harder, because if multiple vendors drive it then the standard become complex as it has to solve corner cases across the multiple targeted use cases – just as in the WS* standards process.

One possible approach is focus on small slices like cloud security appliance with security. We at Sonoa are hoping the CSA with its customer centric approach might pave the way.

This is a real issue, that needs to be worked on. thoughts/suggestions welcomed.

Why should customers care ??

As a consumer, I have no idea what tools or fabrication process was used to build my car. The percentage of people that want that level of detail is very small. I think the same is true for cloud customers. Do they know what language the EC2 load balancers were written in, I don’t think so.  Nor do they care. Different vendors will take different approaches. Like everything else, all that customers will care about is what are they getting and how much does it cost ?

Open Source is great for innovation and interoperability (de facto standards). Enterprises started adopting OSS because it was “accessable”. Much easier to get a copy of MySQL then a copy of Oracle to start a pilot. Same was true for JBoss vs. weblogic/websphere. Enterprises have successfully used open source for pricing pressure w/ existing vendors. Open Source has a GREAT future. It is mainstream, it has and always be part of our the technology fabric.

Yes, security is a concern when you move to the cloud, but not every API operation in the enterprise needs stringent regulations. There are many enterprise applications that require collaboration with the extended value chain – not every operation has sensitive data. Because of cost and time to market issues it may be easier to do these operations in the cloud.

- Enterprise customers will claim that they have been doing private cloud computing. Have noticed that in our discussion w/ customers also. Even though this does fit w/ the virtualization part of the definition of privates clouds, it is hard to argue w/ them.

- Private/public clouds – interoperability between private and public cloud implementations has to be seamless – security, privacy issues have to be worked out. We have seen an increasing need for ‘gateway’ type technology to solve this issue. We’re already offering a cloud gateway solution at Sonoa – stay tuned on plans for a bigger product line .

Vishal is a smart dude, he needs to get out there and talk about cloud
computing more often.