Skip to content

Cloud: Interoperability & Portability

October 12, 2009

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.
One Comment leave one →
  1. Andre Leibovici permalink
    October 14, 2009 8:26 am

    I do not disagree with your ideal Interoperable and Portable cloud environment. However as a Cloud Computing and Virtualization enthusiast I must admit that despite the efforts aiming for the ultimate scenario we are operationally in living hell.

    Even with the advent of hypervisor commoditization, up to this point in time there is no online portability between clouds (public or private). The first ecosystems to help administrators to manage environments from different vendors are only now appearing on the scene and even like that they don’t deliver interoperability and portability.

    VMware has today 70% of the market share and they clearly state that they do not have plans to make their Virtual Infrastructure compatible to other hypervisors. Microsoft announced support to the VMware APIs however how far can they go supporting API’s from a different vendor. There is certainly need of an open API to make the dream come true.

    To see a workload being transferred from Amazon EC3 to Microsoft Azure or to your private Cloud without disruption I think we will all have to wait for a while. In saying that I would not disregard the fact that there is serious money involved in this market and vendors and consumers will certainly make use of it.

    Andre Leibovici

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: