We use cookies and other similar technologies (Cookies) to enhance your experience and to provide you with relevant content and ads. By using our website, you are agreeing to the use of Cookies. You can change your settings at any time. Cookie Policy.

Business Ecology Initiative & Service-Oriented Solution

Michael Poulin

A dead-end for the cloud federation business process

Vote 0 Votes

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, and
b) policies of service execution context (the one that had been missed in our example with the UK firm).
Such 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.

If you are interested in more unusual information about Clouds, please, visit my BLOG.



Website counter


| Leave a comment

Hi Michael,

Cloud Federation service is very similar to IT Services being provided. Every Master agreement with Service provider includes the clause on Subcontracting and its not a new thing. If the primary Service Provider is allowed for subcontracting then they are responsible for terms and conditions and cannot be delegated to subcontracting company. So in both the above examples, Client cannot be tracking to the level of subcontractors. Its Primary Providers responsibility and accountability to think of the same. And specially in Financial Services, this has been avoided to prevent conditions mentioned above.

But Its interesting if it can be componentized or I shall say super specializations happens where data sits across Data Centers:)

You are right, Girish, "Client cannot be tracking to the level of subcontractors". This is what I am saying in the first place (see "Do we really need identity propagation in SOA and Clouds?")

Nonetheless a lot of people believe that it can and should be tracked. In other words, a Client's ID should be propagated throughout the chain of service invocations as it is frequently done inside the company.

Here is only one fundamental difference between Services and your example of sub-contractors. A Business Service does not allow any consumers/clients to limit its operational model: is the Service, which the Client engages, is an aggregate service, it does not do anything other than aggregating and orchestrating other services and it choose those 'other' services it prefers.The Client is not supposed to know (and influence on) HOW the primary Service Provider fulfils agreed contract (see "Knight Rules of Ownership in Service-Oriented Ecosystem").

'My BLOG' has more information on this subject (http://www.mpoulin.com/my-blog/).


Really interesting read! We have very similar thoughts. I work for Flexiant and we have a new white paper, 'Why Federate When You Can Differentiate?'. I would really like to hear your thoughts on it.



Joe Sherman,

Hello Joe,
I saw your company's presentation at the Cloud Expo Europe 2013 in London. That time as well as now, after reading your White Paper, I feel an uncertainty in your recommendation. In particular, you recommend (as I've understood) that to grow a Cloud provider should not accept all possible consumers (hoping that federation helps it to satisfy consumer's computational appetite) but find its own niche where it can effectively differentiate itself from competitors.

In other words, until this niche is not found, a growing Cloud provider has to deny requests for the service from those whose demand is higher than the provider's capabilities. Well, you try to convince a Cloud provider by scaring him/her with problems associated with the Cloud federation but you offer only a principle, not a mechanism, that can help him/her right away.

At the same time, many of the threats you listed relate to Public Cloud and may be mitigated due to visibility offered by Private Clouds. For example, I can propose to forget a word "hybrid" Cloud (Private-Public) and engage other Private Cloud providers on demand, e.g., to handle accidental peaks in requests from your existing consumer. Recall SOA - a service is accountable to its consumers for the functionality it offers (including peaks) but responsible only for the job it can do by itself; for the rest it hires other services on _contractual_ basis. That is, a 'federation' of services is the essence of service orientation (and this federation is about anything, not only resources but also functionality unavailable otherwise from the same initial service).

So, the problem is not in the federation but in maturity (immaturity) of contractual relationships between Cloud businesses. People still think that Cloud is just another breed of APIs and this is the major mistake. I can offer SOA Patterns to solve many Cloud problems today though finding your own professional niche stays as the priority 1 for a long-term run.

Leave a comment

In this blog, Michael Poulin writes about business and technology ideas, concepts, methodologies and solutions leading to service-oriented enterprise, the primary instrument for obtaining business objectives in fast-changing environments.

Michael Poulin

Michael Poulin is an enterprise-level solution architect working in the financial industry in the U.K. and the United States.

He specializes in building bridges between business needs and technology capabilities with emphasis on business and technical efficiency, scalability, robustness and manageability. He writes about service orientation, application security and use of modern technologies for solving business problems. He contributes to OASIS SOA standards as an independent member and is listed in the the international "Who's Who of Information Technology" for 2001. View more


 Subscribe in a reader

Recently Commented On


Monthly Archives