In the last couple of days there have been a few good posts on Cloud Interoperability from Reuven, Greg and Stu. I also had written a blog about standard cloud couple of months ago. To understand the cloud interoperability, we do not have to go that far – from the clouds I mean – just taking a cue from the world of UFOs would be enough !
- Cloud Interoperability of the 1st Kind => Clouds exist and can be observed. This is the state we are in
- Cloud Interoperability of the 2nd Kind => Cloud services can talk to each other
- Cloud Interoperability of the 3rd Kind => Clouds can observe each other and some form of intelligent communication can happen
- Cloud Interoperability of the 4th Kind => Cloud are abducted by each other – just VM movement from one cloud to another
- Cloud Interoperability of the 5th Kind => This is where “joint, bilateral contact events produced through the conscious, voluntary and proactive … cooperative communication” happens. In essence, the clouds can work together
With this enlightenment, we can examine the POV of the cloud luminaries …
- Reuven says “Cloud Interoperability is to make it easier to use multiple cloud providers who share a common set of application interfaces as well as a consensus on the terminology / taxonomies that describe them” – Yes aliens and earthlings can talk the same language and understand each other, but we cannot change the fundamental nature of aliens and earthlings. So a common API layer does not work here and it should not.We do not want to convert aliens to earthlings or vice-versa. They both have their place in the universe and we should respect that. So Common API is a non-starter.
- Reuven defines “Cloud Portability” as mobility irrespective of OS/technology platform and format. Portability is Cloud interoperability of the 4th kind – mobility between homogeneous format and OS/technology platforms. We are not looking for antidote against platform lock-in, but are looking for cloud provider/vendor lock-in and btw, there is nothing like a cloud lock in. Unfortunately Reuven, in his blog, has a little confusion on this aspect. One has a choice of multiple OS platforms and one can always choose to write apps in one platform, if one wishes so. There are valid reasons for choosing one or more platforms. Windows folks will write in Azure, Google folks would like to work with Python and rest of the folks will use EC2. A cloud substrate should not mitigate the OS platform difference.
- Stu first talks about protocol interoperability only a network engineer can love, Yummy Stu ;o)
- His startling observation, that Microsoft has a clue, based on the .NET services architecture, itself is startling ! It is just interfaces between services. I do not think that is interoperability in any sense. OK, I will give it the Cloud Interoperability of the 2nd kind, if a cloud service on another OS/technology platform can talk to Azure services, and they can (I think)
- I liked Stu’s deployment flexibility and that is one of the key components for interoperable clouds – not translation, semantic or not, not common APIs but just deployment flexibility between cloud providers, on the same OS/technology platform.
- Stu has some interesting predictions – yep, no new run time (read my lips – those who remember that)
- As I have said earlier, we have to look at this from the four planes viz: policy, control, management & data. For Cloud Interoperability of the fifth kind, we need :
- A declarative policy plane that can be interpreted in a common way but implemented in proprietary ways as the platform sees fit
- A control plane that can be dynamic with rich attributes that are semantically equivalent across clouds (I do not care if they talk the same words so long as I know how to map them and do equivalence)
- A management plane – again built on semantically equivalent attributes so that I can make (collective and individual) inferences as and when needed
- And A data path which is the OS/technology of my choice and I do not want the cloud to change my data path characteristics.
- And A mature metering plane [Update - March 15,09 : James Urquhart convinced me that this is a fundamental requirement!]