Types of Intercloud: Federation and Multi-Cloud
Lately, more and more people are talking about cloud interoperability.
Unfortunately it's become almost a "marketing war" - who can gain the most momentum with "their" approach, the soonest. There's two camps, and it's really confusing to understand - they are actually different!
Hybrid Cloud is not Intercloud
Intercloud Brokers/Exchanges
We can broadly classify Inter-Clouds as:
Which to choose?
Unfortunately it's become almost a "marketing war" - who can gain the most momentum with "their" approach, the soonest. There's two camps, and it's really confusing to understand - they are actually different!
Executive Summary
Multi-Cloud are User API's
One approach which has the support of OGF and also roughly equivalent is the approach the FP7 Helix Nebula project has taken is called the "Multi-Cloud" approach. This is ideal in situations where there is a user (like a Grid or HPC user) wanting to access several clouds to fulfill his/her computing requirements. Generally this is for academic and research computing constituencies as this technology architecture is "from the User into the Network" type of "explicit demand for resources" where the user is very specifically controlling the computing they want. This also can work for companies who absolutely must access different public clouds and have the IT staff to operate a specific gateway box, or can write code, to do so.
Basically, Multi-cloud "leaves it to the user", even if there is a layer that doesn't make it seem so.
Basically, Multi-cloud "leaves it to the user", even if there is a layer that doesn't make it seem so.
Federation is like the Internet
Another approach which has the support of several Tier 1 Telcos, several commercial Labs, different FP7 projects including those from universities in Naples, Amsterdam, and Helsinki, is called the "Intercloud" approach, which is the subject of the work of the IEEE P2302 Working group as well as the IEEE Intercloud Testbed. This is ideal for large public/commercial Mobile and Internet scenarios, or Enterprise cloud deployments in conjunction with Telco MPLS/VPN. This technology architecture is "from the Network to the User" with "implicit demand for resources" where the user is unaware of what is happening behind the scenes. Think of it as similar technology to Mobile Roaming, or the Public Internet ability for any browser to access any web site on the Internet.
Basically, Federation "makes it invisible", just like the Internet or Phone network.
Basically, Federation "makes it invisible", just like the Internet or Phone network.
A Closer Look
Professor Raj Buyya from Melbourne University has produced some great explanations for this in a recently published paper. I extract from his work to dive into what really differentiates between these - Federation and Multi-Cloud.
- A Federation is achieved when a set of cloud providers voluntarily interconnect their infrastructures in order to allow sharing of resources among each other.
- Multi-Cloud denotes the usage of multiple, independent clouds by a client or a service. Unlike a federation, a multi-cloud environment does not imply volunteer interconnection and sharing of providers’ infrastructures. Clients or their representatives are directly responsible for managing resource provisioning and scheduling.
Federations are like the Internet, or the Phone System
In a Federation, the clouds have decided to join together and create mechanisms which are largely transparent to the users. Connections between clouds are made underneath via special protocols from cloud to cloud. Actually, it's quite hard to view the independent clouds as independent any more! For examples of Federations, think of the Internet, where any browser can access any website - this is enabled by DNS, routing protocols, peering/exchange agreements - set up by the IP transit providers in advance, and transparent to the users. In the phone network, standards for interconnections of phone companies utilize SS7 networking, standardized numbering plans, and origination/termination agreements to result in a system where any phone can dial any other phone worldwide. The mobile phone system adds a roaming layer on top of this providing and even more comprehensive notion of Federation.
Multi-clouds are like Social Networks, or like Calling Cards
In a Multi-cloud, the underlying separate clouds are still quite visible as separate clouds. Connections between clouds are made via over the top via user APIs. In other words the user has placed a mechanism - a box or a software API - in front of the multiple clouds (unbeknownst to them) which makes enables that user to view and use them all at once. It's like a Social Network of today. When you participate in one social network, it's completely separate from another social network. You might be members of many social networks, but they are "walled gardens" and don't have any substantial interoperability across them. If you want a "merged" friends or contact list, you must use a utility perhaps found in your email program, or an program deigned to "aggregate" social networks. It will use the different API's of the social networks to access each one, using your credentials on each, and provide a layer merging together the most important (say "contacts") features of each Social network. Another example is the Calling Card. In the phone network, you may choose not to use the Federation capabilities, perhaps because they are too expensive (direct dial long distance and mobile roaming can be expensive!) for example. In this case you can use a Calling Card, where you manually use the phone network at hand, say through a "toll free" mechanism, to connect to your Calling card, and then through that system, you manually direct it to dial the end phone. 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.
Hybrid Cloud is not Intercloud
Another term used is Hybrid Cloud. It has been defined as a
composition of two or more different cloud infrastructures - e.g a private and
a public cloud. Thus a hybrid cloud is a type of a Multi-Cloud that connects
miscellaneous clouds in terms of their deployment models. Often hybrid clouds
are used for cloud bursting - the usage of external cloud resources when local
ones are insufficient.
Intercloud Brokers/Exchanges
The term Inter-Cloud broker or exchange has been used with different meanings. In most cases it
means a service that acts on behalf of the client in order to provision
resources and deploy application components. A Cloud broker or exchange is an
automated entity with the following responsibilities:
- Automatic resource provisioning and management across multiple clouds for a given application. This would include allocation and de-allocation of resources (e.g. VMs and storage).
- Automatic deployment of application components in the provisioned resources.
- Scheduling and load balancing of the incoming requests to the allocated resources.
Intercloud Architectural and Topological Taxonomy
Now, let's follow Prof. Buyya's scientific classification methodology to better understand all this.
- Volunteer federation - when a group of cloud providers voluntarily collaborate with each other to exchange resources. This type of Inter-cloud is mostly viable for governmental clouds, private cloud portfolios, or a public cloud system.
- Independent - when multiple clouds are used in aggregation by an application or its broker/exchange. This approach is essentially independent of the cloud provider and can be used to utilize resources from both governmental and private clouds. Another term used for this is Multi-Cloud.
- Peer-to-Peer - in the architectures from this group clouds communicate and negotiate directly with each other without mediators.
- Centralized - in every instance of this group of architectures there is a central entity that either performs or facilitates resource allocation. Usually this central entity acts as a repository where available cloud resources are registered, but may also have other responsibilities like acting as a market place for resources.
From an architectural perspective
Independent Multicloud developments
can be further classified as:
- Services - application provisioning is done by a service which can be hosted either externally or in-house by the cloud clients. Most such services include broker components in themselves. Typically application developers specify an SLA or a set of provisioning rules and the service performs the deployment and execution in the background, in a way respecting these predefined attributes.
- Libraries - often custom application brokers that directly take care of provisioning and scheduling application components across clouds are needed. Typically such approaches make use of inter-cloud libraries that facilitate the usage of multiple clouds in a uniform way.
And we can consider the topology
of the different Inter-Cloud architectures as follows:
How to Choose the Right Intercloud Architecture
To answer this, lets look to a formal definition of
Inter-cloud computing (from the GICTF):
“A cloud model that,
for the purpose of guaranteeing service quality, such as the performance and
availability of each service, allows on-demand reassignment of resources and
transfer of workload through a [sic] interworking of cloud systems of different
cloud providers based on coordination of each consumers requirements for
service quality with each providers SLA and use of standard interfaces.”
The "Multi-Cloud" approach, which is the subject of the work of the OGF, several academic projects, and also proprietary "CloudSwitch" like boxes for enterprises, is ideal in situations where there is a user (like a Grid or HPC user) wanting to access several clouds to fulfill his/her computing requirements. Generally this is for academic and research computing constituencies as this technology architecture is "from the User into the Network" type of "explicit demand for resources" where the user is very specifically controlling the computing they want.
The "Intercloud" approach, which is the subject of the work of the IEEE P2302 Working group as well as the IEEE Intercloud Testbed, is ideal for large public/commercial Mobile and Internet scenarios, or Enterprise cloud deployments in conjunction with Telco MPLS/VPN. This technology architecture is "from the Network to the User" with "implicit demand for resources" where the user is unaware of what is happening behind the scenes. Think of it as similar technology to Mobile Roaming, or the Public Internet ability for any browser to access any web site on the Internet.