Trading Places

Almost a year ago, I was deep in conversation with other members of the Clouderati discussing (philosophically, I might add) where the future of cloud computing and the associated services might lead and, more importantly, what that may mean for the next generation of enterprise CIOs.

You may be aware of my enterprise background and recent experience in delivering business-aligned IT transformation (which included cloud, lots of it) and, it’s no secret that based on that very experience, I’ve written numerous blog posts that allude to the challenges that today’s crop of enterprise CIOs face when trying to identify, select, procure and manage cloud services to augment or replace their current in-house offerings.

You may not be aware that during the aforementioned Clouderati conversation, I offered the following two suggestions as food for thought:

As businesses demand even more agility, the next generation of Enterprise CIOs will be much more akin to service aggregators than those who managed the traditional but very complex, “buy long and buy for peak” software contracts.  

As the number of truly attractive cloud services increases, and the security, reliability and cost barriers to their adoption decreases, we will see a growing demand for a “Cloud Concierge”, almost a new generation of SI, who acts as a single point of knowledge for the new CIO, helping deliver a range of fit-for-purpose solutions.

(* In fact, I mention the concept of CIOs-as-service-aggregators in this post from November 2010)

Last week, the folks at NIST (who appear to have either been nominated or nominated themselves as the digitized equivalent of the Custodian Of The Two Holy Mosques) released their Cloud Computing Reference Architecture document, which now includes a section on “Cloud Brokers”.

Despite my obvious (yet short-lived) joy at seeing something I had espoused turn up in something as powerful as a NIST document (yawn), I have a really hard time with the word “Broker” in the context of how NIST have tried to define it.

According to Wikipedia, “a Broker is a party that arranges transactions between a buyer and a seller, and gets a commission when the deal is executed.”

For me, it somewhat stereotypically conjures up pinstriped yuppies sipping bottles of Dom Perignon, vastly overpaid, incredibly indulgent, annoyingly arrogant and probably not the best mental poster child for an already over cloud-washed and double-dip recession fearing buying public.

Yet, let’s be sure to give credit where credit is due (pardon the pun).

If you spend a few minutes reading the NIST definition, they’ve done a pretty good job at explaining the specifics of what their “Cloud Broker” might do:

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.

If I remove the myriad of technical, commercial and operational fundamentals that appear to have been glossed over, look objectively at the above, and substitute the word “Broker” for “Concierge”, it is much easier for me to understand, and further embellish, how this might logically work by simply considering what the Concierge at a hotel might do for its guests – typically the Concierge has a great deal of local knowledge of all services in the area, can source quickly, efficiently and usually from a list of known, trusted and proven suppliers.

They provide the guests with their expertise, on tap, 24×7, usually for little or no charge.

OK, so I concede that I might be simply dealing with semantics or I may be taking the word “Broker” too literally, but I prefer to view it this way because it is easier for me to mentally relate to something I have experienced and I am familiar with (Concierge), versus something I have never experienced (Broker).

In addition, I think we are a VERY long way from their being something that even comes close to being able to called a viable “Brokering” service. Cross-cloud management and governance tools such as enStratus & Rightscale are fantastic at what they do. SpotCloud was (is) a brilliant idea but way too early to market to grab widespread adoption today (hello, Zimory?).

None of these solutions, in my opinion, meet the magical definitions set forth above. Sure, they may be used as part of a toolset, but they don’t cover the full spectrum of cloud services, from IaaS to SaaS – nobody does (except the usual suspects who’d sell your Grandmother for a recurring yearly Cloudwash fee).

As NIST states in the opening paragraph of their Cloud Broker description:

As cloud computing evolves, the integration of cloud services can be too complex for cloud consumers to manage.

I would apply the same logic to their definitions….

Advertisements

8 thoughts on “Trading Places

  1. I think it is incorrect (or misleading) to mention Rightscale or enStratus here as this really is largely about point-to-point service interactions possibly part of a bigger service supply chain (workflow). I don’t really see provisioning of VM instances as such a service interaction as the setup costs are prohibit for any transaction optimization or enhancement (quality, performance, augmentation,….) These are more so facilities mgmt or real-estate mgmt if we see VM’s as landing/location points for execution…something along that lines though I have not given them much thought.

    This [brokerage] is really up at the application runtime layer on a per request / flow basis across such services.

  2. I read the NIST definition of a cloud broker, as a technical service provided by a third-party, not an independent advice and management service.

    From the NIST document, 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.

    To me, this defines a third-party organisation, providing a common, unified interface to multiple cloud providers for multiple cloud consumers.

    As a trivial example, if a cloud comsumer wanted:

    1) Compute services from Rackspace Cloud
    2) Storage from Rackspace Cloud
    3) Storage from AWS as part of a DR plan

    then the cloud broker would be in a position to provide one management layer for all 3 services.

    The cloud broker would also be able to negotiate bulk discounts from cloud providers, and could choose to pass on some of those bulk discounts to the cloud comsumers, or keep them, depending on the business model of the broker.

    Because of the ability of the cloud broker to profit from both ends of the sale – the smaller cloud providers would want to work with larger cloud brokers to direct consumers to them, and the consumers may pay more for the service than the broker is charged by the provider, I wouldn’t expect the cloud broker to provide independent advice about which provider is “best” for a specific consumer.

    I think there is a role for a “Cloud Concierge”, but for them to provide the right advice, I think I’d want them to be in a position where the concierge is only paid by the consumer, not in a position where their advice could be coloured by the profits available from one provider over another.

  3. Even your trivial example would be pretty much impossible for any “cloud broker” today (or tomorrow) assuming its be driven largely by cost because it fails to take into account the dynamics of the env, model cost drivers & predict deviations (good or bad) ignoring other cost elements including co-ordination/co-operation/communication costs across the multiple suppliers.

    You might as well hand the money over to me now….so I can spend it as I please.

    Before one could even contemplate this the client would need to have data and models to have sufficient insight to make the right call never mind the broker. We are trying to drive a car before the wheel has even been invented.

    • I’m not sure I agree about the impossibility of a cloud broker providing this kind of service, or that it needs to be driven by cost (in the example I gave, I specifically gave the reason for a second source of supplier as DR).

      Working in telecoms, it’s a fairly standard practice for a telephone company to route different calls over different network providers, based on things like the cost of calling a specific destination, the source of the call, reliability of the external network provider, and so on.

      In a very real sense, your home telephone provider is operating as a broker for a service, without them knowing in advance what you’re going to do with that telephone service – that’s a big part of why they’ve got datawarehouseses and advanced analytical tools. It’s all about working out who’s the cheapest network provider to route calls over, without causing a failure or noticeable degradation in service to the customer.

      Is the perfect call routing system ever achieved? Absolutely not, there’s always imperfect routing going on, and new negotiations with network providers over routing changes, but you can still save significant amounts of moner over just going over a single supplier network, including your own network. Having the opportunity to redirect calls away from one provider to another gives you significant negotiating leverage to drive down costs and move profit from the network provider to the broker, or to pass on cost saving to the customer.

      Those cost savings more than cover the additional costs for the broker of having multiple links into multiple network providers and managing them all.

      While telephone calls are significantly more commoditised than computing resources today, that’s unlikely to remain the case over the next 10-15 years, especially in the area of “pure” IaaS, where Openstack is going to deliver a consistent layer across multiple cloud providers. Once this is achieved, I expect that the “cloud broker” will take on a significant role.

  4. Firstly, Christian, you should take great joy in the fact that Gartner has a nearly identical definition of Cloud Brokerages:
    http://www.datacenterknowledge.com/archives/2009/07/27/cloud-brokers-the-next-big-opportunity/

    Secondly, I think the idea for Cloud Brokerages needs to be split for services (SaaS and to a light extent PaaS) and compute (most PaaS and all of IaaS). Arbitrage can be possible for compute if you have a common platform (hypervisors, platforms, etc) but is nearly impossible for services. Arbitrage is well suited for large enterprises with enough spend that having a brokerage platform, or paying a fee for a brokerage service, makes sense because of the potential cost savings. Something like SpotCloud might work for this (ask @benkepes if they are still in business), but you still need solutions like RightScale and enStratus to manage the environments.

    On the other hand, I see smaller and medium sized businesses needing cloud brokerages for SaaS, and this is along the lines of intermediation and integration. After purchasing CRM, ERP, financial and accounting solutions, how is data shared and identities integrated? An enterprise has the resources and skills to do this, but smaller businesses (less than 1000 employees typically) do not. This is where the cloud broker acts like a mortgage broker – having negotiated wholesale pricing, having integrated to the providers using their APIs, and understanding the intricacies of all the various packages, they can offer simplicity. Sure, if you are savvy enough or large enough, you don’t need this service. But a majority of SMBs do require it.

  5. Kudos for taking notice of the significant addition to the NIST Cloud Computing Reference Architecture last week (Sep 2011). Namely, the addition of “Cloud Brokers” as one of the five actors in their Cloud Computing Reference Architecture. You also, quite appropriately, challenge the term “broker” with regard to NIST’s wholesale adoption of Gartner’s suggestion that brokerage takes on three dimensions: intermediation, aggregation, and arbitrage.

    Cloud Service Brokers provide the intermediation and aggregation functions. Cloud brokers can and do provide value-added cloud services, combine cloud services, and accommodate multiple cloud providers. Arbitrage is where the broker definition becomes less obvious and is an emerging service offering. It might be useful to think about intermediation, aggregation, and arbitrage as a stack of capabilities that evolves from intermediation to aggregation then to arbitrage.

    My view is that we have an even more fundamental definitional issue with regard to cloud services brokerage – the meaning of the term “service”. Most perspectives on cloud computing have a technical bias (i.e. NIST) with a focus on IT services yielding a lower cost computing delivery model. Here is where vendors like enStratus and Rightscale operate. Their perspective of arbitrage seems to focus on cloud bursting and dynamically migrating workload to a lower cost datacenter. This is interesting and timely, but this is the continuum of the commoditization of compute and will not offer businesses sustained competitive advantage.

    A more enlightened view of “services” is in the business context. Services encapsulate business functionality that drives business process innovation. This takes the view of the Cloud as a business technology platform to offer new and compelling value propositions to customers. In this context, cloud services brokerage (CSB) serves as a platform for business process design across both on-premise services and cloud services – a unified information architecture and platform for business process innovation. In this context, intermediation, aggregation, and arbitrage of business services has a new and more important meaning.

    My company, Mohawk Fine Papers, has embraced the cloud services brokerage model for business process design (see Gartner Case Study on Mohawk below). Cloud service brokerage is real and is happening today. Like cloud computing, cloud service brokerage is an evolution (not revolution) of value-added networks that have defined supply chains for decades. It’s not a product offering – it’s a philosophy enabled by the convergence of service-oriented architecture and cloud computing.

    http://liaison.com/resource-center/case-studies/mohawk-fine-papers-case-study—gartner

    Paul Stamas
    VP, Information Technology
    Mohawk Fine Papers, Inc.

  6. Hello,

    I have a proposal for an event partnership that you both may be interested in.

    Please contact me on the email used and I can send you more information.

    Many thanks,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s