Update – I omitted to mention the fact that fellow Kiwi (well sort of) and resident grump Hoff was a big part of the discussion that prompted this post. Even if he thinks it’s not an important discussion to have…
For many of us talking to non technical folks about cloud computing, the NIST definition of cloud computing is an old backstop. While I personally find it a little over the top and instead revert to the fantastic definition thought up by CloudCamp founder Dave Nielsen, NIST has done some great work with the definition. I was interested to read the other day then that NIST has done some more work, coming up with a cloud computing reference taxonomy, an extensive document talking about all the different attributes of a cloud ecosystem. A bit of a battle rages on twitter however about one paragraph of the work, copied below;
2.5 Cloud Broker – As cloud computing evolves, the integration of cloud services can be too complex for cloud consumers to manage. A cloud consumer may request cloud services from a cloud broker, instead of contacting a cloud provider directly. A cloud broker is an entity that manages the use, performance and delivery of cloud services and negotiates relationships between cloud providers and cloud consumers. In general, a cloud broker can provide services in three categories :
– Service Intermediation: A cloud broker enhances a given service by improving some specific capability and providing value-added services to cloud consumers. The improvement can be managing access to cloud services, identity management, performance reporting, enhanced security, etc.
– Service Aggregation: A cloud broker combines and integrates multiple services into one or more new services. The broker provides data integration and ensures the secure data movement between the cloud consumer and multiple cloud providers.
– Service Arbitrage: Service arbitrage is similar to service aggregation except that the services being aggregated are not fixed. Service arbitrage means a broker has the flexibility to choose services from multiple agencies. The cloud broker, for example, can use a credit-scoring service to measure and select an agency with the best score
Note – Apparently NIST deferred to the CSA definition of broker – my comments below apply for both NIST’s (mis)use of the term and the CSAs
In seeking to build some clarity around the cloud ecosystem, NIST has unfortunately chosen a word, broker, that has significant connotations around it. Broker is defined as;
1. an agent who buys or sells for a principal on a commission basis without having title to the property.
2. a person who functions as an intermediary between two or more parties in negotiating agreements, bargains, or the like.
NIST has chosen to use the word to describe three situations, only one of which “Service Arbitrage” encapsulates the commercial meaning of the term “broker”.
More than just a semantic debate however, this gets to an important point of what companies like enStratus and RightScale (who I’d call cloud service intermediaries) do. The value of a service intermediary is in being an honest party with no commercial imperatives – the last thing one wants when using a cloud service intermediary is to be worried that your cloud governance policies are being tempered by some commercial bias on behalf of the intermediary – in the same way that I’m always a little suspicious that my insurance broker is pushing me to go with an insurer that providers her with the best backhanders, so to would it be a sad day when a service intermediary juggled policy based on under the table dealings with cloud service providers.
In talking about this with enStratus founder George Reese, he was quick to explain that enStratus actually has the ability to fulfill a broker role in the true sense of the word. As he said;
We actually have broker capabilities in the sense you are thinking of. Important to note, however, it is not currently an “applied” feature. More to the point, enStratus software can dynamically determine from a number of clouds where a given workload should be deployed and we have agreements that enable us to pool resources from across different clouds… And the ability to bring those together to “broker” workload assignment. We just aren’t actively doing that last part bit.
The important part here is that enStratus CAN perform the task of broker, but choses not to do so. My impression is that the risks involved in introducing perceived, if not actual, commercial bias into a service intermediary role are just too great to justify some potential revenue form providing brokerage.
Reese isn’t sure that service intermediaries can’t find a clear way to perform a brokerage function as well. he says that;
…there’s a real problem of trust. If a broker has control over your workload placement, how do you trust that it is truly the place that is the best for that workload and not the cloud with whom the broker negotiated the best deal? It’s a tricky line to walk, but I do believe it’s one that can be walked. You simply need to put in place the reporting and traceability to create a high level of transparency around the placement decision process.
His solution (for enStratus in particular, but for service intermediaries more generally) is as follows;
- Clarity when placement is done from a brokerage pool versus a private account
- The ability to explain and quantify why enStratus made a specific placement decision
- Never make a placement decision because it was “the best deal” for enStratus. Use random logic or pre-configured customer biases to break any “ties”
While I agree that there is a need for some kind of brokerage service (and particularly in the case of excess capacity), service intermediaries are in my view not the players to provide the service. Brokerage and service intermediation are two completely separate functions and NIST and the CSA do us all a disservice by combining them into one.