According to different cloud computing experts, a cloud federation is the practice of two or more service providers interconnecting for the purpose of load balancing traffic and accommodating spikes in cloud consumer demand. Cloud federation allows one provider to wholesale or rent computing resources to another cloud provider. Cloud federation is a great technological achievement, right?
If I am a provider and I agree to hold 100 items of 'something,' I will charge the consumer for this service. It is okay if I have enough storage for only 30 items because I can rent the rooms for the other 70 items for a low price from other providers and make my profit. But will I?
Cloud federation forgets about the end-consumer of the cloud services, particularly the contract conditions agreed upon between the end-consumer and the hired cloud service provider. Let me give an example: Assume you want a bottle of fresh milk. You review a farm and find that it has well-fed cows and a clean environment, and you place your order. Now, the farm finds that it does not have enough fresh milk for you and asks a neighboring cow-owner to lend a few cups. Where was that cow fed and with what? Is it healthy? Is the milk clean? You don't know. The farm mixes the milk and delivers the bottle to you. Are you happy?
Exactly the same happens when we contract one cloud provider on agreed conditions but that provider utilizes cloud federation and we have no clue on what conditions this federation is based. This business case is new because inside an enterprise we did not have it even when used grids or other forms of distributed computing, since we controlled all of it. There is nothing wrong technically with cloud federation; but contractually or legally, there is a serious problem.
Here is another example. A firm in the UK that provides a pension to its employees uses a data center that utilizes a cloud provider in Spain. The latter tries to reduce TCO and lower the price-tag for competition purposes by contracting a cloud in Mexico. However, this cloud provider relies on cheap storage costs in the US, where some pension data ended up. Neither the UK firm nor its employees know that their pension data ended up in the US. However, it is more interesting that neither the UK firm nor the Spanish cloud provider know this. The British pension information became available for an audit and received the scrutiny of the American government on totally legal grounds.
Those cloud providers are not at fault - they did not know what data they stored, they just federated storage resources. Thus, who is responsible for this outstanding result? The answer is - everybody and the end-client, i.e. the UK firm. Here's why.
That UK firm had to treat an invocation of the Spanish cloud provider as a business supplier relationship rather than an extension of its own a data-centre for less maintenance cost. In this case, the UK firm would require the supplier to be compliant with the firm's policies as well as with the UK regulations regarding personal data. For the firm's IT, legal compliance was an unusual concern and it had been missed altogether. That is, the UK firm had to have a contract with the Spanish cloud provider that would oblige the cloud provider to provide its service according to the British rules. The same condition had to be applied when Mexican cloud provider was hired, i.e. it also had to preserve the British and EU rules regarding personal data.
This example teaches us that 'mechanic' cloud Federation is far from enough for conducting effective business in the clouds. There is no automation in the sense we used to use in our enterprises because everything is now a business case with all business constraints and compliance duties, which we cannot automate yet.
Uncontrolled cloud federation is not the only problem of cloud computing but one of the most obvious for demonstration that technical dexterity is not enough to work in business. In Cloud Expo Europe 2013, John Considine, CTO of Terramark, said, "Many things we have do not work anymore" in Clouds. The business contractual regulation of relationships within the Clouds is one of the most important of them. Fortunately, we do not need to start from the scratch in this - OASIS RAF for SOA specification defines all needed elements for such regulation - a Service Description and Service Contracts. Since we agree that Clouds provide services to its consumers, aforementioned specification is applicable to Clouds in full.
The major contribution of Service Contracts into the relationships between consumers and the service is the focus on
a) service communication and execution policies, andSuch a contract may assume serious penalties if the provider violates agreed policies, and this is the best 'technical' argument to think twice before getting in any Cloud Federation process. This is a Cloud maturity issue and may be not the total dead-end but it is the time to grow up from technology into business if we don't want business Cloud consumers to look somewhere else soon.
b) policies of service execution context (the one that had been missed in our example with the UK firm).
If you are interested in more unusual information about Clouds, please, visit my BLOG.