'That's a great deal to make one word mean,' Alice said in a thoughtful tone.
'When I make a word do a lot of work like that,' said Humpty Dumpty, 'I always pay it extra.'
- Through the Looking Glass
“Cloud brokers” are a hot topic, thanks in part to their inclusion in the NIST Cloud Computing Reference Architecture [1]. NIST’s definition derives, in part, from a 2009 Gartner report [2]. As Ben Kepes points out [3], these definitions of cloud broker are at odds with the accepted meanings of the word “broker”. Ben also makes the point that the issue is more fundamental than what names we use to call the various actors in a multi-provider scenario. The article suggests the term “service intermediary” as more descriptive of the kinds of things that companies like enStratus and RightScale actually do – where “service intermediary” is defined as an actor that does service intermediation and/or service aggregation but doesn’t do service arbitration. Although I agree with much of Ben’s article, I think it misses the main problem with the NIST definition.
The Boat Analogy
Suppose I wanted to buy a boat. For various reasons, I decide to use a boat broker. I expect the broker to (among other things) introduce me to the parties selling boats and help me work through the process of buying the boat. The interaction pattern is three-way. The seller, the broker, and I are all aware of each others existence and expect different things from one another. For example, if the engine seized the day after I bought the boat, it is doubtful that I would hold the broker responsible.Suppose that, instead of buying a boat, I simply wanted to rent one. Now, instead of seeking out a broker, I would look for a boat charterer. In contrast to my dealings with the broker and the seller, my interactions with the chartering company are two-way. The chartering company may or may not own the boat. I don’t know and, ultimately, I don’t care. All I care about is that the boat is made available for my use over a specific period of time. Any problems with the boat are the responsibility of the chartering company – regardless of who owns the boat.
The main problem with the NIST definition is that it lumps “brokers” and “charterers” together and, in so doing, masks the significant differences in the interactions and expectations of the parties involved.
It’s the Relationships
The first step to unraveling this hairball is to stop focusing on the functional aspects of what (for argument’s sake) I will simply call “the intermediary”. Whether the intermediary simply arbitrates requests amongst (nearly) identical back-end providers or synthesizes an aggregation of different providers to create a new service is not as important as whether or not the consumer does or doesn’t have a contractual relationship with these back-end providers.Regardless of how many back-end services an intermediary uses and regardless of how imaginatively it might use them, if the consumer doesn’t have a contractual relationship with those back-end providers, their interactions with that intermediary are no different than those of any other cloud provider. While the intermediary may have more fodder for excuses (“our storage provider failed in exactly such a way as to expose a heretofore unknown bug in our billing provider”), an SLA is an SLA and, if the intermediary fails to meet their SLA, the consumer is entitled to whatever compensation is specified in the service contract.
If you squint at the NIST definition you can infer that the distinction it draws between “given services” and services that “are not fixed” are a reference to the visibility (or lack thereof) between the consumer the back-end services. If this is the case, this distinction needs to be made explicit and unbundled from the definitions of intermediation, aggregation, and arbitrage.
Functional and Business Relationships
Most of the discussion around cloud brokers tends to focus on the functional relationships (i.e. who sends requests to whom and how are the results processed). Above, I point out the importance of the business relationships (i.e. who has contracts with whom). Obviously both sets of relationships are important. What makes multi-party cloud scenarios interesting is that the two sets of relationships are independent of one another. This can lead to a fair number of different scenarios.Take, for example, the “punch out” scenario found in many enterprise purchase portals. The consumer (an employee) has both business and functional relationships with the intermediary (their employer). At some point there is an SSO exchange and the consumer is redirected from the intermediary to the provider (the supplier’s website). Although the consumer now has a functional relationship with the provider (in that they are sending requests and receiving responses from the supplier’s site) they do not have a business relationship with the provider (i.e. they aren’t asked for their credit card). Behind the scenes, there are both functional and business relationships between the employer and the supplier (the order information is sent back to the portal and the supplier expects to be paid by the employer).
If we confine our considerations to a cloud consumer, a single intermediary, and a single cloud provider then further restrict ourselves to consider only those cases in which the consumer has, at a minimum, a functional relationship with the intermediary and a business relationship with at least one other party – I figure there are 26 possible scenarios (you may want to check me on this). Granted, many of these combinations may not have a workable business case, but here are some discrete examples:
Jamcracker
- consumer has business and functional relationships with intermediary (Jamcracker)
- consumer has business and functional relationships with the cloud provider (e.g. WebEx)
- intermediary and cloud provider have business and functional relationships
- consumer has business and functional relationships with intermediary (SpotCloud)
- consumer has no business or functional relationship with cloud provider
- intermediary and cloud provider have business and functional relationships
- consumer has functional but no business relationship with intermediary (Akamai)
- consumer has functional and business relationships with the cloud provider
- intermediary and cloud provider have business and functional relationships
The Taxonomy Challenge
Obviously we can’t simply give each of the possible multi-party scenarios a unique name; there are too many to remember. What we have is the classic problem of taxonomy. The scenarios are distinguished along a number of different axes and it is difficult to tell which axis is “the most important”.While I don’t have a complete answer to this problem, it seems to me that it makes the most sense to do the “top level split” around the existence or non-existence of any business relationship between the consumer and the back-end provider(s). Although it pains me to admit it, the industry is coalescing around the term “cloud broker” to refer to scenarios in which there is no business relationship between the consumer and the provider (exactly the opposite of how the term is used in the real world). This leaves the term “service intermediary” to refer to those scenarios in which there is a business relationship between the consumer and the cloud provider.
When describing new things it is easy to fall into the trap of wasting time arguing about their names. Regardless of what terms people use, it would be helpful if we consistently used the same, separate names to refer to the top-level cases I outlined above. “Broker” and “intermediary” are as good as any others.
Final Digression
I suspect that the term “cloud broker”, as it is currently used, derives from an older term – “message broker”. This makes sense because “message broker” is misapplied in exactly the same way as “cloud broker”. “Message broker” is commonly used to refer to an architectural pattern in which you use an intermediary to minimize or eliminate the producer’s and consumer’s awareness of each another.References
[1] NIST SP 500-292, “NIST Cloud Computing Reference Architecture”, http://collaborate.nist.gov/twiki-cloud-computing/pub/CloudComputing/ReferenceArchitectureTaxonomy/NIST_SP_500-292_-_090611.pdf[2] Gartner, “Gartner Says Cloud Consumers Need Brokerages to Unlock the Potential of Cloud Services”, http://www.gartner.com/it/page.jsp?id=1064712
[3] Diversity, “NIST Decides to Redefine the English Language, Broker != Service Intermediary”, http://www.diversity.net.nz/nist-decides-to-redefine-the-english-language-broker-service-intermediary/2011/09/12/
