Types of Intercloud: Federation and Multi-Cloud
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!
Multi-Cloud are User API's
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
Basically, Federation "makes it invisible", just like the Internet or Phone network.
A Closer Look
- 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
Multi-clouds are like Social Networks, or like Calling Cards
Hybrid Cloud is not Intercloud
- 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
- 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.
- 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.