Category Archives: cloud service broker

Cloud computing, cloud service broker, Featured, IaaS, IT Management

Are We All Cloud Service Brokers Now? Part II

By John Dixon, Consulting Architect

In my last post, I discussed Cloud Service Brokers and some of their benefits after reading a couple of articles from Robin Meehan (Article 1 here and Article 2 here). In this post, I will break down some of Robin’s points and explain why I agree or disagree with each.

At the end of last post, I was breaking down cloud arbitrage into three areas (run-time, deployment-time, plan-time). Credit to Robin for run-time and deployment-time arbitrage. I really like those terms, and I think it illuminates the conversation. So, run-time cloud arbitrage is really science fiction right now – this is where the CSB moves running workloads around on the fly to find the best benefit for the customer. I haven’t seen any technology (yet) that does this. However, VMware does deployment-time and run-time arbitrage with VMotion and Distributed Resource Scheduling – albeit, in a single virtual datacenter, with individual VMs, and with a single policy objective to balance a cluster’s load across vSphere nodes. See Duncan Epping’s excellent write up on DRS here. Even 10 years ago, this was not possible. 15 years ago, this was certainly science fiction. Now, it’s pretty common to have DRS enabled for all of your vSphere clusters.

A few of Robin’s points…

Point 1:
“The ability to migrate IT workloads dynamically (i.e. at run-time, not at deployment time) is something I sometimes see as a capability under the ‘cloud broker’ banner, but in my view it really just doesn’t make sense – at least not at the moment.”

I agree. Run-time cloud arbitrage and workload migration ala vMotion is not possible today in cloud. Will it be possible within the next few years? Absolutely. I think it will first manifest itself in a VMware High Availability-like scenario. Again, see Duncan Epping’s fantastic deep-dive into HA. If cloud provider X drops off of the internet suddenly, then restart the resources and application at cloud provider Y (where cloud provider Y might even be your own datacenter). This is sometimes known as DR as a service, or DRaaS. And even now, there are some DRaaS solutions that are coming onto the market.

Point 2:
“The rate of innovation in the IaaS/PaaS/DaaS market is such that most of the other vendors are playing catch-up with AWS, as AWS continue to differentiate themselves from the following pack. This shows no sign of slowing down over the next couple of years – so the only way a migrated workload is going to work across multiple cloud vendors is if it only relies on the lowest common denominator functionality across the vendors, which is typically basic storage, virtualised compute and connectivity.”

Also agree, the rate of innovation in the market for cloud computing is rapid as specialization sets in at an industrial level. This also means that downward price pressures are enormous for vendors in the cloud space, even today as vendors vie for market share. As switching costs decrease (e.g., portability of applications increases), prices for IaaS will decrease even more. Now, wouldn’t you, as a customer, like to take advantage of this market behavior? Take in to consideration that CSBs aggregate providers but they also aggregate customer demand. If you believe this interpretation of the market for IaaS, then you’ll want to position yourself to take advantage of it by planning portability for your applications. A CSB can help you do this.

Point 3:
“The bottom line is that if you are going to architect your applications so they can run on any cloud service provider, then you can’t easily use any of the good bits and hence your value in migrating to a cloud solution is diminished. Not ruined, just reduced.”

Disagree. To take advantage of market behavior, customers should look to avoid using proprietary features of IaaS platforms because they compromise portability. Like we noted earlier, increased portability of applications means more flexibility to take advantage of market behavior that leads to decreasing prices.

This is where perspective on cloud becomes really important. For example, GreenPages has a customer with a great use case for commodity IaaS. They may deploy ~800 machines in a cluster at AWS for only a matter of hours to run a simulation or solve a problem. After the result is read, these machines are completely destroyed—even the data. So, it makes no difference to this customer where they do this work. AWS happens to be the convenient choice right now. Next quarter, it may be Azure, who knows? I’m absolutely certain that this customer sees more benefit in avoiding the use of propriety features (a.k.a., the “good bits” of cloud) in a cloud provider rather than using them.

What is your perspective on cloud?
• A means to improve time to market and agility
• A way to transform capex into opex
• Simply a management paradigm – you can have cloud anywhere, even internally as long as you have self-service and infinite resources
• An enabler for a new methodology like DevOps
• Simply a destination for applications

I think that a good perspective may include all of these things. Leave a comment and let me know your thoughts.

Interested in learning more? Download this free whitepaper ‘Cloud Management, Now!’

Cloud computing, cloud service broker, Featured, Public Cloud

Are We All Cloud Service Brokers Now?

By John Dixon, Consulting Architect

 

Robin Meehan of Smart421 recently wrote a couple of great posts on cloud service brokers (CSBs) and the role that they play for consumers of cloud services. (http://smart421.wordpress.com/2014/02/24/were-mostly-all-cloud-services-brokers-now/ and http://smart421.wordpress.com/2014/02/25/cloud-brokerage-and-dynamic-it-workload-migration/). I’m going to write two blogs about the topic. The first will be a background on my views and interpretations around cloud service brokers. In the second post, I will break down some of Robin’s points and explain why I agree or disagree.

Essentially, a cloud broker offers consumers three key things that a single cloud provider does not (these are from the NIST definition of a Cloud Service Broker):

  • Intermediation
  • Aggregation
  • Arbitrage (run-time, deployment-time, plan-time)

My interpretation of these is as follows. We’ll use Amazon Web Services as the example IaaS cloud provider and GreenPages as the example of the cloud broker:

Intermediation. As a cloud broker, GreenPages, sits between you, the consumer, and AWS. GreenPages and other CSBs do this so they can add value to the core AWS offering. Why? Billing and chargeback is a great example. A bill from AWS includes line item charges for EC2, S3, and whichever other services you used during the past month – so you would be able to see that EC2 charges for January were $12,502.90 in total. GreenPages takes this bill and processes it so that you would be able to get more granular information about your spend in January. We would be able to show you:

  • Spend per application
  • Spend per environment (development, test, production)
  • Spend per tier (web, application, database)
  • Spend per resource (CPU, memory, storage, managed services)
  • Compare January 2014 to December, or even January 2013
  • Estimate the spend for February 2014

So, going directly to AWS, you’d be able to answer a question like, “how much did I spend in total for compute in January?”

And, going through GreenPages as a cloud broker, you’d be able to answer a question like, “how much did the development environment for Application X cost in January, and how does that compare with the spend in December?”

I think you’d agree that it is easier to wrap governance around the spend information from a cloud service broker rather than directly from AWS. This is just one of the advantages of using a CSB in front of a cloud provider – even if you’re like many customers out there and choose to use only one provider.

Aggregation. As a CSB, GreenPages aggregates the offerings from many providers and provides a simple interface to provision resources to any of them. Whether you choose AWS, Terremark, Savvis, or even your internal vSphere environment, you’d use the same procedure to provision resources. On the provider side, CSBs also aggregate demand from consumers and are able to negotiate rates. Why is this important? A CSB can add value in three ways here:

1) By allowing you to compare the offerings of different providers – in terms of pricing, SLA guarantees, service credits, supported configurations, etc.

2) By placing a consistent approval framework in front of requests to any provider.

3) By using aggregated demand to negotiate special pricing and terms with providers – terms that may not be available to an individual consumer of cloud services

The approval framework is of course optional – if you wish, you could choose to allow any user to provision infrastructure to any provider. Either way, a CSB can establish a request management framework in front of “the cloud” and can, in turn, provide things like an audit trail of requests and approvals. Perhaps you want to raise an ITIL-style change whenever a cloud request is fulfilled? A CSB can integrate with existing systems like Remedy or ServiceNow for that.

Arbitrage. Robin Meehan has a follow-on post that alludes to cloud arbitrage and workload migration. Cloud arbitrage is somewhat science fiction at this time, but let’s look forward to the not-too-distant future.

First, what is arbitrage and cloud arbitrage? NIST says it is an environment where the flexibility to CSB has the flexibility to choose, on the customer’s behalf, where to best run the customer’s workload. In theory, the CSB would always be on the lookout for a beneficial arrangement, automatically migrate the workload, and likely capture the financial benefit of doing so. This is a little bit like currency arbitrage, where a financial institution is looking for discrepancies in the market for various currencies, and makes various transactions to come up with a beneficial situation. If you’ve ever seen the late-night infomercials for forex.com, don’t believe the easy money hype. You need vast sums of money and perfect market information (e.g., you’re pretty much a bank) to play in that game.

So, cloud arbitrage and “just plain currency arbitrage” are really only similar when it comes to identifying a good idea. This is where we break it down cloud arbitrage into three areas:

  • Run-time arbitrage
  • Deployment-time arbitrage
  • Plan-time arbitrage

In my next post, I will break down cloud arbitrage as well as go over some specific points Robin makes in his posts and offer my opinions on them.

 

To learn more about transforming your IT Department to a broker of IT services download this ebook