It's very likely that one cloud service will not deliver all that is needed by the enterprise; so how will enterprises tie together multiple cloud services?
Not every cloud will have the silver lining that you want. If as many predict, cloud services will stimulate the migration from on-premises systems, then working with multiple cloud services is very likely. As the enterprise looks at cloud solutions, it may become attractive to move more and more functions to the cloud--but which cloud, and how many clouds?
It is hard to believe that one cloud service will deliver all that is needed by the enterprise. Further, some applications will work best on IaaS (infrastructure-as-a-service), some on PaaS (platform-as-a-service), while there are already many SaaS (software-as-a-service) services that meet enterprise demands. This situation of multiple cloud services, each delivering a portion of the enterprise applications, will eventually lead to connecting the multiple clouds together. We need cloud interoperability and federation. (See my blog "The IEEE Gets into Cloud Interoperability", which covered the announcement of the IEEE cloud standards efforts.)
Multiple issues will become important to resolve:
* Connecting to multiple clouds as a single enterprise
* Two or more services used to complete a single enterprise function
* Moving data and information requests among clouds
* Multiple cloud resource sharing
* Transferring tasks, licensed software, and workloads among clouds
These are some of the goals of the IEEE standard, CS P2302--Standard for Intercloud Interoperability and Federation (SIIF).
Cloud federation is the ability to interconnect multiple cloud services offered as IaaS, PaaS and SaaS from different service providers operating on separate networks and data centers. These multiple cloud services can be public, private, community, or hybrid solutions.
The CS P2302 Standard's Justification
The description of the standard on the IEEE website states:
"This standard creates an economy amongst cloud providers that is transparent to users and applications, which provides for a dynamic infrastructure that can support evolving business models. In addition to the technical issues, appropriate infrastructure for economic audit and settlement must exist. This standard defines topology, functions, and governance for cloud-to-cloud interoperability and federation. Topological elements include clouds, roots, exchanges (which mediate governance between clouds), and gateways (which mediate data exchange between clouds). Functional elements include name spaces, presence, messaging, resource ontologies (including standardized units of measurement), and trust infrastructure. Governance elements include registration, geo-independence, trust anchor, and potentially compliance and audit. The standard does not address intra-cloud (within cloud) operation, as this is cloud implementation-specific, nor does it address proprietary hybrid-cloud implementations."
Advantages to the Enterprise
There are multiple benefits that will accrue to the enterprise if the federation standard is completed and is adopted by cloud service providers:
* The enterprise can choose the cloud service that best satisfies the requirements for a particular business need, without having to compromise by going with just one service that covers most but not all of its requirements.
* The most appropriate application support infrastructure environment can be selected for the applications to run on.
* Workload locations can be selected anywhere in the world.
* The ability to select the cloud service by function will stimulate greater competition among cloud providers.
* Multiple-cloud federation can avoid provider lock-in.
Why Would the Providers Adopt Federation Standards?
Reviewing the enterprise benefits does encourage the cloud providers to support the federation standard development and adoption. The providers do have some incentives, especially smaller providers and those new to the cloud service market:
* A cloud provider that offered, for example, inventory, warehousing, and fulfillment support could lose a customer who also wanted support for sales applications. The inventory cloud provider could interconnect with a sales application in another cloud, rather than losing that customer to a competitor that offers both the inventory and sales function.
* The provider can sell unused computing resources to cover overload situations, selling to other providers who encounter workload peaks. The cloud with the traffic peak may find it less expensive to work with another cloud than to increase their own resources. This could be very beneficial for cloud services that have seasonal peaks rather a relatively level traffic load over the year.
* The cloud provider could expand their geographic coverage though federation.
* A provider can retain the loyalty of their present customers because new services can be supported through federation rather losing the customer to a competitor.
Open Issues to Resolve
There will be technical barriers to overcome as the federation standard is developed. An example is the fact that SaaS has interfaces, PaaS has APIs, and IaaS has images. How are these resolved among multiple clouds? Will there have to be a number of federation technical testing scenarios, or will there be a need for a federation testing association? Once tested, will the federated cloud providers have to recertify as they change their environments?
But there will also be business and legal issues to be resolved that will be outside the scope of the standard committee:
* A number of privacy and security issues will need to be resolved. Not only will different industries have differing requirements; national and possibly state governments may impose requirements within their jurisdictions that cannot be enforced outside those jurisdictions, leading to uneven privacy and security enforcement.
* If the enterprise moves applications from one cloud to another, how does that affect the software license agreements?
* Can the federated clouds agree on a common minimum service level agreement?
* Will some cloud providers create environments that will enforce vendor lock-in?
* Will the enterprise legal departments impose limitations on the cloud agreements for the enterprise's protection that limit the use of federation?
* What does cloud federation certification mean to the SLAs, security, and privacy agreements with the enterprise?
Cloud federation is not only a good idea, it offers many benefits to both the enterprise and provider. It can be done. Think of the federation that has been delivered with the global PSTN and wireless networks. Cloud federation is more complex but doable.