Lately I started discussing Brokering in a group conversation and took the NIST definition expecting all attendees would immediately relate to what brokering actually meant. Halfway through the conversation however somebody intervened and asked me why I was not just using a web page with links for all the services that needed to be accessed. This got me to realize brokering may not be obvious to everybody. So, let me try to explain what we are talking about and what it implies.
As companies evolve from a single environment to consuming services from multiple providers, being private or public cloud services, SaaS services or any combination here of, they are making their environment more complex to access and manage.
In that process, they move from a single, homogeneous and managed environment to a disparate set of architectures, often managed separately which results in diverse security problems, availability issues and potential risks. Such environments are easily exposed to external threats due to the lack of end-to-end thinking. They are extremely common in enterprises where the business is consuming IT services outside the control of IT, what we call “shadow IT”. In 2014, Gartner predicted that “by 2017, 50% of total IT spending will be spent outside the formal IT organizations”, and in many companies this is happening. IDC on the other hand pointed out last year that” more than 80% of enterprise IT organizations will commit to hybrid cloud architectures by 2017, vastly driving the rate and pace of change in IT organizations”. This trend needs to be recognized, but at the same time, organizations should understand what they are getting into and how they can maintain security, consistency, ease of use and compliance of their environments. And here is where the cloud broker actually comes in.
What is a Cloud Broker?
NIST, the National Institute of Standards and Technology (US based), defines brokering in following way: “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.”
With this in mind, the cloud broker has two different connotations. On the one hand it refers to the body that negotiates the relationships, which overlaps with provider management in general and on the other it refers to a system that manages the use, performance and delivery of the services. I keep the term “body” rather vague as this can be a partner management team in procurement as well as an automated system that negotiates relationships. Although today it is most often the first, we can definitely envisage the second.
Let’s look at Broker Use Cases.
To stick to the NIST definition, there are three cloud broker use cases:
- 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 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.
There are other use cases we will talk about later, but here are the three that have been identified by NIST. What is interesting is to look at the interaction with the providers and how those differ in each of the cases.
Intermediation, a back to back contract
In intermediation, the cloud broker resells one service sourced from a provider. Although the broker may enhance the service, he is directly dependent on the service provider. So, for example, the service provider may guarantee an SLA of 99%. The broker might be tempted to propose 99.9%, but he is fully dependent on the provider and takes a risk by offering a better service level. He can improve security by ensuring appropriate end-to-end protection mechanisms, he can facilitate provisioning/de-provisioning, he can enable single sign-on, single billing etc. These are the type of enhancements he can create, but the fundamental characteristics of the service are the ones provided by the provider. The broker will charge the customer and may decide to meter the utilization himself or depend on the supplier to do so. His options are open
Aggregation, it’s all in the broker’s hands
Aggregation is a totally different ballgame because now the broker creates a service by assembling services provided by multiple providers, of which he may be one. The consumer consumes one service with its specific characteristics and its cost. To deliver this service, the broker will consume services from each of the providers. To make it easier to understand, I’ll call the provider services “service elements” as they are components of the service delivered by the broker.
Each service element has its own characteristics and costs. It is up to the broker to assemble those characteristics and define what he can commit to the client for the composite service. Fundamentally the approach that needs to be taken is similar to SIAM (Service Integration and Management). The broker measures service consumption, defines the price and calculates the bill. He is responsible to ensure his bills cover the combined costs of all the providers. So in this case the responsibility of the broker is much larger. He is in the front line. Provider management is critical for his success.
Arbitrage, a dynamic version of the previous two
Arbitrage consists in intermediating or aggregating a service, but the difference is that the provider or his characteristics are defined at provisioning time, not at service definition. Let me take a couple examples.
A user of a global company needs to provision a service to analyze privacy data and uses an external provider to deliver the infrastructure. This is a typical intermediation case. There are two ways to set such service up. What is specific is that the service instance needs to be provisioned in a location that is dependent on the geography of the user. So, I can set-up a similar service for each geography and have the user choose the appropriate one. This may be applicable if the same user analyzes data from different geographies. Alternatively, I can create one service that includes a policy. This policy defines the provider each time a user provisions the service. The policy takes the geography of the user and chooses, at provisioning time, the appropriate provider. The advantage of this approach is that I only have one service in my service catalog.
A more sophisticated example could be a dynamic allocation of an IaaS provider depending on the quality of service of a provider. Indeed, similar T-shirt sizes do not have the same performance the public clouds and that performance tends to vary over time. So, you could imagine that, at provisioning time, the latest performance index is used to choose which provider and which T-shirt size is provisioned to deliver the service. This would imply the same service can run on multiple clouds and that remains to be seen. But it demonstrates how arbitrage enables optimization of workloads.
As stated previously, provider management is key to ensure successful brokering. We’ll come back in the next blog entry on how provider management links to SIAM and what you should take into account when setting up your brokering capabilities.