This site uses cookies. By continuing to browse the site you are agreeing to our use of cookies. Read our privacy policy>Close

If you need help, please click here:

Interoperability: The Key to Cloud Applications

/ Part 2 of 2 /

Technical Description

Cloud instances must be able to communicate and interact with each other. Each cloud must be able to find one or more other clouds, for which a particular interoperability scenario is ready, willing, and able to accept a transaction and exchange whatever subscription or use-related information may be needed as a pre-cursor to the transaction.

Thus, an Intercloud Protocol for presence and messaging needs to exist which can support the one-to-one, one-to-many, and many-to-many use cases. The discussion between clouds needs to encompass a variety of content, storage, and computing resources.

  • Topology

The vision is an analogy with the Internet itself: in a world of Transmission Control Protocol/Internet Protocol (TCP/IP) and the World Wide Web (WWW), data is ubiquitous and interoperable in a network of networks; likewise, in the world of Cloud Computing, content, storage, and computing are ubiquitous and interoperable in a network of Clouds.

Reference Intercloud network topology and elements

  • Intercloud Gateway

The Intercloud Gateways are designed to provide a mechanism for supporting the entire profile of Intercloud protocols and standards utilizing a common transport such as Extensible Messaging and Presence Protocol (XMPP). The Intercloud Root and Intercloud Exchanges would facilitate and mediate the XMPP negotiating process among Clouds.

  • Intercloud Roots
As part of the proposed topology, the Intercloud Root providers would be federated, and each federated node in the Intercloud topology would independently manage “root” capabilities that would include Cloud Resources Directory Services, Trust Authority, and Presence Information. Additionally, each Intercloud Root instance will be associated with its affiliated Exchanges by defining the affiliation relationship as part of the Intercloud “root” instance.

∙ Naming

Clouds are, in the end, IP addresses on the Internet, and so the temptation is to use Domain Name Services (DNS) with a Universal Resource Naming-based (URN) naming scheme appropriate to the communications substrate, as DNS, especially Domain Name System Security Extensions (DNSSEC), contain a mechanism to return trusted addresses as a result of name resolution.

XMPP, the envisioned communications substrate, uses URNs for identifying a resource with which one could “chat” and establish identity. While XMPP might be the right communications substrate, a naming system more like Autonomous Systems (AS) might be more appropriate, in which case we are talking about system-to-system federation. This represents one cloud operator’s willingness to federate with another specific cloud operator, to wit, each cloud operator may have several availability zones or regions in their “cloud.” How they manage their own internal cloud, and which parts of it they choose to make available for Intercloud federation is up to them. This mechanism is very analogous to the BGP policies they have in place for network transit.

We call the cloud equivalent of AS to be CS for “Cloud System,” and continue to explore the considerations. Just as in the Internet Exchange, AS management is the job of the exchange routers or the route server. In the Intercloud architecture, CS management is the job of the Intercloud Exchange. Eventually, there will need be some kind of numbering authority for the CS names, the role for which IEEE has currently assumed.

∙ Communications Substrate

In the initial designs, the end clouds will each have Intercloud Gateway code affixed to them. They will support the conversational protocol (XMPP) as well as the transport protocol (Web Sockets). The Intercloud Root is supporting the conversational (XMPP) server system.

On top of the communications substrate there needs to be a services framework; and, though not as well thought out yet, is imagined to be WebSockets as described in Internet Engineering Task Force (IETF) RFC 6455.

∙ Trust Infrastructure

From an Intercloud topology perspective, Intercloud Roots will provide Public Key Infrastructure (PKI) CA root-like functionality. According to the current PKI-based trust model, once the CA authorizes the certificate for an entity, the entity is either trusted or non-trusted. However, in the cloud computing environment, especially in the Intercloud environment, this model needs to be extended to have “Trust Zone” to go along with the existing PKI-based trust model. Intercloud exchanges will be responsible for the “Trust Zone” model layered on top of the PKI certificate-based trust model.

∙ Audit Trail

The Root servers will support XMPP audit trails. These implementations will likely use XMPP S2S, but have not been designed yet. Raw audit traffic will need to be folded and reduced such that conversations relating to decisions of fulfilling federation requests can be reproduced and proven to have matched the request in the most optimal way. In this way arbitrage will be enabled and trusted.

∙ Semantic Resource Directory

In order for the Intercloud-capable Cloud instances to federate or otherwise interoperate resources, a Cloud Computing Resources Catalog system is a necessary infrastructure. This catalog is the holistic and abstracted view of the computing resources across disparate cloud environments. Individual clouds will, in turn, utilize this catalog to identify matching cloud resources. The technologies for this are based on the Semantic Web which provides for a way to add “meaning and relatedness” to objects on the WWW. Cloud Computing resources can be described, cataloged, and mediated using semantic web ontologies, implemented using Resource Description Framework (RDF) techniques.

  • Intercloud Exchanges

Intercloud Exchanges will leverage the globally dispersed resources catalog information hosted by federated Intercloud Roots in order to match cloud resources by applying certain Preferences and Constraints to the resources. Due to the very large size of the cloud ontology set in the Intercloud environment, we are expecting a very large RDF dataset. We believe that such a large RDF dataset should be stored on a Distributed File System such as HDFS (Hadoop Distributed File System). By storing the RDF dataset in HDFS and querying with Hadoop “Map-Reduce” programs, results will be returned quickly and efficiently.

Exchanges are the brokers and custodians within a Domain-Based Trust environment for their affiliated cloud providers. In other words, cloud providers rely on the Intercloud exchanges to manage trust. As part of the identification process for matching desired cloud resources, individual consumer cloud providers will signify the required “Trust Zone” value such as “Local Intercloud Exchange” domain or “Foreign Intercloud Exchange.”

Conclusion

This exciting project addresses a part of Cloud Computing, which is still a “grand challenge” — global and transparent interoperability among Cloud Computing operators. Progress is being made through contemporary processes that include standards development and experimental test-beds. Our plan and expectation is that Intercloud will soon become a household word.

Part 1 of 2:http://e.huawei.com/en/publications/global/ict%20insights/hw_376150/feature%20story/HW_376286

By David Bernstein

Managing Director of Cloud Strategy Partners, LLC