Each week, new insights from the world of interoperability and cloud standards bubble forth, yet despite the constant chatter, there are still dramatic hurdles that must be overcome before interoperability becomes a reality.

Among some of the voices advocating for a change in how cloud computing standards might evolve into workable, sustaining solutions recently was John Considine, former Director of the Platform Products Group at Sun (which he entered following the company’s acquisition of Pirus Networks). Considine is the founder and CTO behind Boston-based CloudSwitch.

In a recent opinion piece, Considine stated that although cloud’s end users desire genuine interoperability–to be able to find the most suitable cloud offering for their needs without being burdened by the concern that the cloud they choose might lock them in later—the current state of offerings makes this impossible in the near term.

Ideally, if we lived in a world of true interoperability, a customer would be able to pick a cloud provider for a particular workload and then, if she decided to move on or the general needs altered, it would be possible to seamlessly move that workload back to the company datacenter or into any number of other cloud environments—all without a major undertaking, which is what such a shift would likely cause.

In Considine’s view, the true enemies of interoperability are as follows:

• There are many types of requirements from end users feeding into the cloud definition; customers are looking for architectures in the cloud that match their application configurations, performance requirements, geographic locations, and security concerns.  They want specific infrastructure capabilities (think SANs, network gear, and hypervisors) because these are existing enterprise standards, and look for specific flavors of architecture/topologies/OS that most closely match what they already have.

• This range of customer requirements creates opportunities for cloud providers to differentiate based on features and services that let them serve specific market segments better than their competitors – think security, performance, specialties (like government or medical), or even different hypervisors (for compatibility with in-house platforms), networking architectures, and pricing models.

• The competition among cloud providers in turn leads to intense “land grabs” by technology vendors in the cloud market. This includes the big guys like VMware, Microsoft, and Citrix as well as startups like Eucalyptus, Cloud.com, and Nimbula.  It also includes most of the networking players and many of the IT ops providers. Each of these vendors has a different view on how cloud infrastructure should be built and managed (using their solutions and core components), and these differences alter the design of the cloud as well as the attributes of the cloud that the end users can control. 

Considine’s more recent experiences with CloudSwitch provide him with something of a unique point of view in that he works with both enterprises and the cloud providers in bridging the needs of both. He provided some context for one of the largest enemies of interoperability, which is rooted in architecture, stating:

“What we’ve seen is that the cloud providers—the people providing the core infrastructure, at least in the IaaS sphere—have to make choices on their architectures…If someone builds a cloud they have to pick everything from hypervisors, storage, servers, storage networking and the core network, but those choices are always informed by the design center, which dictates who and what market they want to go after and what they want to provide to with their cloud offering.

He gives some context to this idea, noting that in the early days of cloud computing, the architectures were structured according to the dominant needs of the time. Thus, in the case of Amazon, the design center’s goals were to structure clouds around Web 2.0 concepts since customers were driven by web-facing applications and an associated architecture to support them.

“Invariably they were driven toward highly stateless architecture; storage was not very important because the driving factors were really read-only. They were trying to optimize for the public facing website networking capabilities so that architecture became the basis of those clouds…As you can imagine that decision in terms of equipment and architecture was not a good match for backoffice applications or even potentially HPC.

So you see, the cloud providers have to make these decisions and it kind of permeates everything they do; when you start talking about formats for machine images or network options or even applications (in the early days in Amazon there was no persistent storage so if you shut down your instance or it crashed, everything was gone) you see how this is not a good fit for enterprise applications.”

In short, the decisions that cloud providers make dictates the kinds of workloads they can support, but with this differentiation rooted in the design center—the hub of these decisions based on what markets they want to chase—comes even further divergence from any goal of convergence.

“Image formats, storage and how you manage it, pricing and SLA agreements, quality of service—these all have different parameters because the fundamental architectures are different. So instead of cloud providers trying to drive to a common architecture they’re actually driven to an uncommon architecture; an unshared vision of how the cloud should be built.”

Near the end of our chat, we discussed the issue of possible solutions, or at least hopeful signs of progress in the right direction for interoperability. Perhaps not surprisingly, his answer was rather bleak.

He stated that while he doesn’t see anything hopeful on the horizon, there are some interesting projects that do show some sparks of progress in the right direction, including OpenStack, which is the open source collaboration that is being promoted by Rackspace. Again, despite the designation of “open” and NASA involvement, the primary vendor behind the push is one of the world’s largest hosting companies, which does change the nature of the offering to some extent.