Interoperability: The Key to Cloud Applications
By David Bernstein, Managing Director of Cloud Strategy Partners, LLC
/ Part 1 of 2 /
The Telephone Network, the Internet, and Clouds
Cloud computing is a new design pattern for large, distributed data centers. Cloud computing offers end-consumers a “pay-as-you-go” model — a powerful shift for computing, towards a utility model like the telephone system or, more recently, the Internet.
However, unlike those utilities, clouds cannot yet federate and interoperate. In the telephone network, any phone can call any other phone with “direct dial.” There is no requirement that the two phone users are connected to the same phone company. The phone network has even evolved, with mobile, to allow a user to carry their phone to any country, “roam” with a provider, and make calls. This is an amazing level of cooperation amongst telecommunications providers.
Within the Internet, any connect browser can access any web site. The Internet Service Provider (ISP) giving connectivity to the browser does not have the same ISP hosting the web site. In fact, browsers can easily change ISPs, even in different countries — and web sites can host in any location as long as their name remains the same — and the system still works.
So far, the global world of Cloud Computing does not have any of the capabilities of interoperability that have made the telephone network and the Internet such indispensable utilities.
As it turns out, early networks were not born with instant interoperability or federation. For example, telephone systems in different geographical areas did not interoperate at all, and required pre-arranged human intervention to manually plug together the phone systems of adjacent countries. International “direct dial” was not available until relatively recently — the 1970’s.
As to the “on-line” world, in a precisely analogous evolution, the original online services such as AOL, Prodigy, and CompuServe had no interoperability between them. Content posted on one service could not be consumed by a client connected to a different service. Email could not be sent from a user on one service to a user on another.
The summary concept for the Intercloud is a Cloud Computing service operated by one service provider or enterprise interoperating with a Cloud Computing service operated by another.
The Multi-Cloud Approach
The first idea a research team comes up with to solve this particular problem may inevitably be a “Multi-Cloud” approach that does not change any of the underlying clouds, and connections between clouds are made via over-the-top user-APIs. In other words, the user places a mechanism — a box or a software API — in front of each cloud, unknown to the cloud itself, which enables that user to view and use multiple clouds concurrently.
Let’s look at our example of the telephone network. Would the Multi-Cloud approach enable direct dialing? How would one create “transparency” across two or more phone companies? Common practice is to set up one box or service that is a member of each and every target phone network. When you want to call some number, you are really calling directly to the box to tell it the number you want to reach. The box decides what phone company is hosting the originating phone subscription, and posing as a “user” on that network, in order to make the connection.
So while it looks like you have access to several phone companies, you don’t have direct dial or “roaming.” The modern day example of this is the Calling Card. In this way you are using the “user API’s” of the phone system (phone numbers) to construct an over-the-top, end-to-end connection.
We discarded the Multi-Cloud approach as insufficient; as it simply cannot provide the transparent interoperability that is needed. Because phone companies and ISP’s decided to work together, they are able to do much better than Multi-Cloud for interoperability by proactively choosing to federate their networks.
The Federation Approach
In looking to how the interoperability problem was solved previously in the phone system, and in the Internet, a theme has emerged.
In each of these cases, special networking protocols were invented to solve these problems. For the Public Switched Telephone Network (PSTN) a collection of protocols called the Intelligent Network (IN) powered a new, out-of-band signaling system — the latest version called SS7 — which allowed for transparent interoperability and federation, and paved the way for new features such as toll free calling, conference calls, call waiting, and network-based voicemail, amongst other things.
For the Internet, a collection of conventions and protocols such as Autonomous System (AS) numbering, Domain Name Service (DNS), Border Gateway Protocol (BGP), Simple Mail Transfer Protocol (SMTP), and Hypertext Transfer Protocol (HTTP), to name just a few, laid the groundwork for the global Internet on which many additional capabilities have been built.
An Example Intercloud Use Case
Perhaps you are having trouble envisioning why an Intercloud federation is needed. Consider the following use case (Figure 1).
Figure 1. Intercloud Enabled Video Calling — Optimized Multi-Carrier Transcoder Placement
As illustrated on the next page, a user in the USA initiates a video conference session from a handheld tablet, calling colleagues in the USA as well as in Europe, each using different devices, a television and a mobile phone. Each device has different screen geometries and requires different transcoders to display the video. Transcoders need to run as physically close to the device as possible to minimize latency and allow the adaptive encoder to produce the highest quality image possible.
The user on one network in the USA is essentially asking the other networks, some in other countries, to run processes on behalf of his call. This requires the use of a computational capability in the clouds of the participating carriers. Using Intercloud protocols, the initiating carrier requests a geographically federated resource, the transcoder placements. Without a mechanism such as Intercloud, the federation of the multiple carrier clouds would not be possible.
Inventing the Intercloud
By now it should be obvious that a set of “Inter-Cloud Computing” conventions and protocols will be necessary to pave the way for future applications, and that the clouds will have to participate in the federation to achieve transparent interoperability.
As the IEEE P2302 project has developed, we have begun to adopt shorthand to communicate these ideas within the group. Just as the term “Inter-Networking” was shortened to “Internet” to discuss the interoperability of networks, the term “Inter-Cloud Computing” has been shortened to “Intercloud” to address the interoperability of Cloud Computing. Working from 2008 to 2009, we have devised a strong blueprint for the Intercloud.
In May of 2009 at the International IEEE Workshop on Cloud Computing/International Symposium on Cluster Computing and the Grid in Shanghai China, we presented a team paper called “Cloud Computing Interoperability Protocols and Formats — Defining the Intercloud.” Later that month, at the 4th International IARIA/IEEE Conference on Internet and Web Application Services in Venice, Italy, a more complete paper was presented: “Blueprint for the Intercloud — Protocols and Formats for Cloud Computing Interoperability,” which won the “best research” award of the conference and is referenced by Wikipedia as the first documented invention of the Intercloud concept. The compelling idea of the Intercloud has spread rapidly, and worldwide, to interested researchers in Cloud Computing.
The new “Intercloud community” has published several dozen academic papers that define a wide range of possible Intercloud protocols, architectures, and security solutions. There have been dozens of talks on the subject with research teams that include University of Melbourne and University of Amsterdam; AT&T, Orange, and NTT laboratories; and many research presentations at IEEE and other conferences, including workshops sponsored by the United States National Institute for Standards and Technology (NIST).
NIST has endorsed the proposed Intercloud architecture as a reference implementation for Cloud Broker in Special Publication 500-293 U.S. Government Cloud Computing Technology Roadmap, Volume III.
A Standard and a Testbed is Formed
In the fall of 2010, our research group proposed through a PAR (Project Authorization Request) that a new standards working group be chartered by the IEEE, and in early 2011, the IEEE assigned P2302 as the standards working group identifier. The first P2302 working group meeting was held in July of 2011, and as of early 2013 the team has focused on delivering the 3rd Draft Standard.
Following the precedent of the Internet — which was constructed on the philosophy of “rough consensus and working code” — the IEEE Intercloud Testbed project was founded to run in parallel with, and be bi-directionally complementary to the IEEE P2302 working group.
Starting with the IEEE P2302 design, the IEEE Intercloud Testbed team would integrate participant clouds into a working implementation of the Intercloud architecture. Issues discovered would be fixed, finished code placed in an open source project, and the system further documented. As needed, the IEEE Intercloud Testbed engineering would deviate, improve, expand, or change the IEEE P2302 specification, and provide feedback of all changes to the standards working group.
Figure 2. IEEE Intercloud Testbed participants and their locations
Why the Big Cloud Operators Haven’t Jumped On This
We toured the world to every Cloud Computing event we could find to promote the standards working group and the Testbed. We found that academic researchers and telecommunications carriers were invariably interested, while the “big boys” of Cloud Computing — Amazon, Google, and Microsoft, among others — just didn’t seem to care. Our understanding of the matter is based on the realization that the typical strategy of an “early dominant player” in an online world is to attempt to “cover the earth” themselves. Similar to the on-line services of the past, major cloud operators of today are incentivized to be “walled gardens” and not simply “interoperable nodes.”
Why Intercloud is Inevitable
Based on the premise that interoperability is inevitable, we are confident that the world of the Intercloud will emerge, just as the world of on-line services became interoperable through the World Wide Web (WWW). Back in the on-line services days, users demanded interoperability because:
•They wanted to send mail from one on-line service to a subscriber on a second or third service. Interoperable email was a huge driving force.
•Content owners did not want to put content in a proprietary format for each on-line service. The idea of a “web site” that anyone could access was a revolutionary idea.
•Users did not want to have separate client for each service. The idea of a “universal browser” was another powerful idea.
•Users wanted to be able to search “everywhere” because AOL keywords were completely useless on CompuServe or Prodigy, and vice versa. A single, interoperable network gave birth to Internet-wide search.
Back then, interoperability begat the WWW; and, in the future, interoperability will cause the emergence of the “Intercloud.” The use-case of global video calling is just one of many cloud-to-cloud interoperability scenarios that will drive this evolution.