Rational Survivability

Being an (as-yet) unindicted co-conspirator in the twit-threads around the issues of cloud interoperability and portability, I'm still trying to figure out at this point exactly what the terms mean? And, what do they mean within different contexts of cloud offerings such as IaaS, PaaS and SaaS?
Question: Within the context of Infrastructure as a Service (let's say AWS' and Mosso's services, for example), what does interoperability mean? Does it mean anything other than I can package up a workload on one of the IaaS environments and reinstate it on the other? Doesn't that sound like "portability"?
Q: Within the context of PaaS (e.g. DabbleDB and Intuit QuickBase), what does interoperability mean? Does it mean that I can do a database "merge" operation between collections residing on the two services without an export-import? Have we just reinvented federated database operation? Or does it mean successful export-import… aka data portability?
Q: SaaS? Well, you get the picture.
So, staying within character of asking questions:
Q: In this "cloud" environment, what's the difference between interoperability and portability exactly?
Or, the musical question, with sincere apologies to Tina Turner,
What's cloud got to do (got to do) with it?
(For the record, I think that there are real answers, but we're getting side-tracked by some of the wrong… dare I say it? … questions.)

Got to go with Rich on this one. I don't think there is a difference between portability and interoperability. If you have one, you have the other.
That said, the question you're really asking is do we first worry about being able to move our apps or run the risk of taking longer by including all the metastructure (I like that one) around it.
In the spirit of your incomplete thought, I'll give an incomplete and somewhat stream of consciousness think-out-loud answer.
On the one hand, in many instances (ha! sorry, pun not intended) there won't *be* any metastructure to move. So from a least common denominator we have to first work on just moving the application instance (atomic component).
On the other hand, standards and specifications that are narrowly defined are rarely expanded and future revisions tend to be rarely adopted unless they are very extensible. Think about the RFCs that are extensions to TCP for optimization but don't redefine the core standard; backward compatibility/ability to interoperate without implementation is imperative for some standards.
So to make a long winded answer longer: we can certainly move forward on an attempt to define a standard that allows portability across environments of atomic components as long as we do so in a way that bears in mind we'll need to extend it to support metastructure in the future. That means keeping that metastructure in mind when developing the spec and ensuring that metastructure components with relationships directly affecting the portability (and therefore definition in the specification) of the atomic component have some sort of placeholder.
And really, if you're going to have to do that, why not just write it down and flesh it out the first time through?
Lori

No. Portability is something that comes later in the life cycle of a technology.
Building in a requirement for portability at the outset would tend to retard development of new technologies. If a technology is portable it becomes a commodity. Commodities mean you have no market incentive to beat the competition on anything but price as all products are otherwise equal.
Companies who innovate want to lock in a larger market share by producing something unique and market differentiated. So building in portability means that they would not be rewarded for the innovation. And those innovations are what drive technology adoption by customers and convince VCs to fund technology startups.

Achieve a sufficient level of interoperability and you end up with de facto portability at the application logic and data levels, which is what actually matters.

@Lori,
I'm going to disagree with you.
In my mind (using Web 2.0 examples) portability is taking your Blog from Typepad to Blogger/Blogspot (or vice-versa).
Interoperability is the ability to post your latest Blog post's title and a small blurb on Facebook or FriendFeed or Twitter automatically once a new article has been published.
While you could use the second method to port stuff over, it is something very different and should be considered on its own merits. Historically speaking, it was possible to generate feeds from Blogspot for a long time before it was possible to "backup" (port) all the posts. It is possible to fetch and manipulate Facebook information but it is not possible to move it (lock stock and status-picture) to Myspace or Facebook-competitor-2.
@Hoff, I like the graphic that goes with this article because I think it answers the question for you. Lack of portability means "lock-in" and while you may not care about your Facebook information being locked in, explaining to your CIO/CEO that you lost last years information because you just can't get it out the Cloud (and the Cloud it was on is owned by a company that is no longer) would be a problem.
On the other hand, without Interoperability you are pretty much losing out (mostly) on what the Cloud provides.
In other words… they need to come at the same time.
(To be fair to Lori, both methods (even though I think of them as very different features) can be done by storing the information in a well-thought-out manner and exporting a subset for Interoperability and the whole thing for Portability.)

The discussion about the difference between interoperability and portability isn't new by any means. In the context of Cloud, Portability is the ability to move an application or service from one cloud to another cloud, usually with minimal overhead, or no overhead. Interoperability is the ability of services to seamlessly communicate with each other.

If Mime is a portable format for exchanging the mail attachments in consistent and decipherable format, then the SMTP is an interoperable communication mechanism to transport these messages from one place to the other. Similarly, SNMP is the transport and MIBs are the message codification scheme for portable understanding of these messages. That’s good. We solved this problem number of times. We learned lot from these evolutions. So, combining all these rich experiences and wisdom, I am sure we all can come up with simple but powerful mechanisms for enabling the another level of technological disruptions and innovations.

Christofer Hoff wrote on his incomplete thought on “Cloud Portability or Interoperability?”:

There is a lot effort being spent now on attempts to craft standards and definitions in order to provide interfaces which allow discrete cloud elements and providers to interoperate. Should we not first focus our efforts on ensuring portability between clouds of our atomic instances (however you wish to define them) and the metastructure that enables them

Cloud services are composed from connecting one or more services and combinations of message patterns that takes places between or among these services. This implies that Interoperability (dealing with how to communicate among these services) and Portability (how to move these services and associated data sets from one cloud service provider to the other) are more critical than ever before for Cloud.

Lori MacVittie argued that:

I don’t think there is a difference between portability and interoperability. If you have one, you have the other. We can certainly move forward on an attempt to define a standard that allows portability across environments of atomic components as long as we do so in a way that bears in mind we’ll need to extend it to support metastructure in the future.

Allen Baranov has a different point of view:

In other words… they(portability and interoperability) need to come at the same time.

I do agree with @Allen that the Portability and Interoperability are two inseparable and conjugate concepts that need to go hand in hand. Though how that can be done is different issue. But, both of them are necessary and required conditions to give the customers required confidence that they can move their services and data freely. I am sure @Lori is also meant that Interoperability and Portability are not two separate things and they need to go together. Good news is that as network speeds approach computer bus speeds, the network becomes the computer, Portability starts embracing Interoperability issues and Interoperability can start gleaning the benefits of Portability. So, the distinction or difference between these two started to blur and portability meets interoperability.

Dan Philpott has expressed his interesting view and concern on innovation and standardization:

Building in a requirement for portability at the outset would tend to retard development of new technologies. If a technology is portable it becomes a commodity. Commodities mean you have no market incentive to beat the competition on anything but price as all products are otherwise equal. Companies who innovate want to lock in a larger market share by producing something unique and market differentiated. So building in portability means that they would not be rewarded for the innovation.

Yes, Agreed. But, that is true for specialization. I am not sure if APIs or protocols are their sustainable competitive advantage. The interoperability that results from using standards makes it easier for consumers to mix and match products and it increases competition. In case of Cloud, standards clearly needed because we're talking about some kind of platform on which other applications and services are going to be built. In my view, the biggest economic contribution will in fact come from the platform or the applications on top of this standardized platform. If you are building a specialized service on top of this platform, then competition make sense. Though the competition is definitely a key component in driving innovation, but it's important to question where that competition should be occurring, and where it's mutually beneficial to have a standard. Internet shouldn't have been successful without TCP/IP or portable data formats. XML, MIME, EDI are all standards but innovation thrived around these standards. So, i strongly argue that vendors/cloud service providers need to be more innovative than locking up access protocols or methods.

Finally, we need to make sure we clearly define what we mean by interoperability and portability and try not to gloss over the differences. Interoperability is extremely important as far as Cloud services are concerned.

Then Rich Miller asked three challenging questions to help complete Hoff’s incomplete thought:

Within the context of infrastructure as a service, what does an interoperability means? Does it mean anything other than I can package up a workload on one of the IaaS environment and reinstate it on the other side? Doesn’t that sound like portability?

Within the context of PaaS, what does interoperability means? Does it mean that I can do a database “merge” operation between collections residing on the two services without an export and import? Have we just reinvented federated database operation? Or does it mean successful export-import aka data portability?

In Cloud environment, what’s the difference between interoperability and portability exactly? What cloud go to do with it?

@Rich, you answered your own questions. Interoperability and Portability are not a new topics for any of us. We have dealt with these issues for ORBs, SQL, EDI etc. Posix has been around for awhile giving us mechanism to provide interoperable and portable access to systems all along. In my view, we all need to seriously start thinking about collaboration and standardization to address these portability and interoperability issues. I don't think, protecting APIs or access methods gives any one vendor a sustainable competitive advantage. Any comments?

What do we need to standardize?

It would be very difficult to fully anticipate the needs of the Cloud service consumers. There is a growing need to distribute the application/service globally to be able to meet the demands of growing business needs. When services are distributed or deployed across clouds, latencies and performance guarantees of each other is critical. Ability to switch over to the other service providers who can fulfill these goal is also equally important. User applications or services should be able to balance their requirements like cost, geography, throughput and other efficiencies. As Cloud is all about dynamicity, it is essential to provide a common interface to negotiate, allocate or de-allocate any additional cloud services or resources completely driven by the business needs. All these lead to having a common interfaces or standards to facilitate addressing some of these challenges:

Some of the key standards required for the futuristic cloud services (metastructure) are:

Cloud Resources:Cloud service provider independent mechanism to access metastructure (including the common semantics for cloud resources like Nodes, Load Balancers, Switches, Routers, Firewalls, Network ACLS, Data Access(both structured and unstructured etc)

Cloud Services Directory:Cloud service directory services for service configuration, identification, location, and routes etc. Same interfaces or services should be accessible from other cloud service providers too.

Audit, Assurance, and Compliance Data:Given the growing policy and compliance needs, Cloud service consumers needs some common mechanisms to extract this information from the underlying cloud resources or services.

Accounting and Metering: Cost of resources is a very important factor for any application. Of Course, primary goal of every business is to create value for their shareholders. Traditionally, IT departments have been operating with huge capital expenditure budgets (depreciation curse) or operating leases (off-balance sheet magic). Cloud introduces pay-as-you-go model making it very difficult to predict the cost of these services during the budgeting process. IT leaders need to figure out how these services are budgeted. However, what is very critical in that direction is having an uniform interface and/or semantics for metering and monitoring resources consumed in the Cloud. In addition, these mechanisms also help them to put some governance and financial controls.

Resource Life Cycle Management: Cloud moves the resource ownership to centralized service providers. As consumers started to use Cloud resources, they need better control on negotiating, acquiring, pricing and activation of these resources. So, it is very important to define common mechanism and interfaces to address these needs in the cloud with some common interfaces to negotiate, execute and monitor these contracts or commitments.

Cloud Security Services: Security is becoming increasingly important concern in the cloud. It is not that current applications addressed this problem very well and cloud is not thinking about. Enterprise applications are hosted inside the bricked walls to protect themselves. That gives the users the confidence and assurance required. The moment they move these applications into the cloud, onus will be on the applications themselves protect from any security breaches. Applications need to sense and respond to any threats. It starts with defining the common interface to provide the security protocols required. Again, how this mechanism implemented are left to the Cloud infrastructure providers to innovate and come up with new technologies and innovations. Some cases, we should be able to leverage all TLS, HTTP/S, IPSEC and other technologies innovations already in place. At the minimum, it is important to think of how cloud applications and security aspects needs to be provisioned, monitored, and controlled. So, this leads to my requirement for defining protocol or common mechanisms for provisioning security identities in the cloud.

Cloud Performance Data: Performance monitoring and tuning is going to be another Interesting challenge that InterCloud need to address to provide an ability to predict an application’s performance across different clouds. Unless the Clouds can provide some signals of performance(like what we have today for OSs), it would be hard for service brokers to negotiate these contracts dynamically. To facilitate the service bursting into Cloud having a well defined interfaces to the Cloud resource is very essential. Though initial phases of cloud adoption, application can take care of these initially(that may open some more new challenges though) but we should start thinking at higher level i.e. Cloud infrastructure level.