Compute surface as a traded commodity?

[Simon Plant]

Bruce wrote:
>Will the "Cloud" ever become a pool of hosting providers who pitch their prices, SLA's and storage cost so customers will come to their "cloud" for services?

I foresee a time into the future where the compute surface is virtualized and standardized enough that hosting contracts can be traded as a commodity on a market, rather than the RFP type process we have today.

Such agreement would allow business to place a deal on an exchange much like FX today and get bids to run based on some parameters. IT hosters would price the deal with a spread in the same way as a currency trade today, the deal done in a matter of seconds and hosted for the duration of a contract window.

If virtualization vendors deliver on their hybrid end-vision, this could be a reality of packaging workloads with SLA manifests and using internet vMotion-type tools to migrate. It would fundamentally change the way we write software frameworks and applications themselves to be more self contained and highly standardized to achieve the best 'tradability'.

Interoperability via standards between VM platforms, portability of data, code business logic and processes are all key to how we build out the Cloud.

Such openness may be a far extreme view, but would you want the opposite view of the world where switching costs and lock-in are extremely constraining and we are forever stuck in a platform cycle of distribute-and-consolidate?


Simon Plant

[wayne pauley]

>
> Bruce wrote:
> >Will the "Cloud" ever become a pool of hosting providers who pitch their prices, SLA's and storage cost so customers will come to their "cloud" for services?
>
> I foresee a time into the future where the compute surface is virtualized and standardized enough that hosting contracts can be traded as a commodity on a market, rather than the RFP type process we have today.
>
> Such agreement would allow business to place a deal on an exchange much like FX today and get bids to run based on some parameters. IT hosters would price the deal with a spread in the same way as a currency trade today, the deal done in a matter of seconds and hosted for the duration of a contract window.
>
 

I think it will go much further than that. Consider how an IP connection is negotiated today without human intervention! There is no reason why a workload can't be autonomically negotiated by the private cloud with different providers in the public based on an autonomic-SLA. While we are a long way from this - I think this is the vision that some of us see as the future of cloud computing. Infrastructure will self-manage and our focus will be on helping the software become far more self-sufficient.
 
In the meantime - we need to focus our efforts on the challenges in front of us - private-to-public (and public-to-public) migrations, autonomics, SLA automation, security and privacy improvements, stack orchestration, improved discovery and self-wareness, and eventually standards.
 
-w

---

Send e-mail anywhere. No map, no compass. Get your Hotmail® account now.

[Simon Plant]

2008/12/16 wayne pauley <wayne_...@hotmail.com>

>In the meantime - we need to focus our efforts on the challenges in front of us - private-to-public (and public-to-public) migrations, autonomics, SLA automation, security and privacy improvements, stack orchestration, improved discovery and self-wareness, and eventually standards.

@Wayne, I agree entirely. I'm interested in outlining an end-game to work towards, but certainly for right now the issue I have is getting applications/services on the same virtualization platform internally and externally in a hybrid model, and migrating workloads in and out of the firewall as demand and capacity requires.

@Jim, I harp back to standards of vm's, AMI's and templates and writing the applications appropriately on top. VMWare started this discussion at least with their Open Virtualization Format (http://www.vmware.com/interfaces/ovf.html)

Right now I don't see a solution for either, unless I'm missing something?

Simon Plant

[JL Valente]

As usual on this group we have very different camps and opinions which makes the whole debate quite useful.
But again I don't think that this an either/or proposition. It depends who the "end user" is really.
Some of the ones we are dealing with go deep and require serious metrics and understanding of what they are really getting from their cloud provider.

---

From: cloud-c...@googlegroups.com
To: cloud-c...@googlegroups.com
Sent: Tue Dec 16 15:02:25 2008
Subject: [ Cloud Computing ] Re: Compute surface as a traded commodity?

From Paul Moxon:
[if you keep it simple, then they will get it]

I agree with Paul. From a cloud-computing, sales engineering perspective, price is based on what you can offer customers, not what it costs the company to provide such services. The latter has to be quantified to ensure profitability, but no matter how much the 'processing-markup' if you have what customers don't want, or do have what they want but make the process to complex, you will loose customers and slow down the migration to 'the cloud' overall. That doesn't help anyone's bottom line.

What the company I work for does is create a formula, with multiple components that averages what a single 'seat' or 'user' will consume with the hosted application they've purchased. There will be statistical outlyers (in the case of AV, these may be part of the formula), but overall it needs to be reasonable and reaslistic. Then they charge the customer in 'seat' tiers (1-1000, 1000-3,000), annualized (can be monthly) and so on. This has so far proven to be both manageable and profitable, and includes lots of SMB and Enterprise sized customers...

So as an SE, I would work it backwards - from the end-customer to the hardware - Price the applications, support model and so on. For example: I just bought a home. I have one utility provider, but am charged by the 'application' (DirectTV, Internet, Phone, etc.). In this example, the utility provider is charging Megawatt hours, which is obviously where this thread was starting, but I think it's folly to separate the two, when the same company can Provide both the Applications and the Power to run them. All the cloud provider have to do is package OEM'ed solutions. Both Sprint and AT&T have dived in head first with this model for the last year or so.

Standardizing on GHz/hour or other hardware based metric is wrong, in MHO, because the applications that are hosted in the cloud will have different efficiency ratings. This may matter to the cloud provider, but the end-customer can care less - and the sales person selling the application/services can care less, and so on. Infrastructure costs will not be a factor, at least in the short term.

Customers also don't care how you provide the service - except for the part they interface with. In Paul's example, the only part he would care about is the price of fuel, the location of the gas station and so on. Nobody cares about oil refinement, oil discovery costs, or the trucking of refined fuel to the gas station. The same should be true of services provided in the cloud. If the customer has to think to much about it, what is the advantage of moving from CPE ot the cloud anyway??

Daniel Scafuto

On Tue, Dec 16, 2008 at 11:26 AM, Paul Moxon <pa...@moxonsonline.com> wrote:

Do end users really need to see this level of complexity? Internally, the cloud provider might want to base the charge rates on various measurements, such as CPU, memory, bus speed, etc. However, the end user will probably want something much simpler e.g. I want to run on a (virtual) single host or on a cluster or, even, I want 24x7 availability. Elastica uses a fairly simple system like this when you build an application to be deployed in their cloud. Anything more complex can make it overwhelming for anyone but the most sophisticated user.

 

To continue Ray Nugent's comparison of petroleum and West Texas sweet light, when I buy gasoline for my car, I get the choice of Regular or Premium at the pump. Now, I don't know what goes into the regular gasoline blend…how much is West Texas sweet light, or Brent light or Saudi heavy oil…and, guess what, I don't care. The regular gasoline is good enough for my 8-year old Jeep and that's all that I need to know. Similarly, end users don't want to be confused by a huge menu of CPU speeds, memory allocations, bus speeds, etc. – if you keep it simple, then they will get it (as long as they can upgrade to a different configuration if needed).

 

Paul.

 

---

From: cloud-c...@googlegroups.com [mailto:cloud-c...@googlegroups.com] On Behalf Of William Louth (JINSPIRED.COM)
Sent: Tuesday, December 16, 2008 12:59 PM

To: cloud-c...@googlegroups.com
Subject: [ Cloud Computing ] Re: Compute surface as a traded commodity?

 

I am not sure why we are looking for one single resource to meter. I would expect that various resource meters will be used as cost drivers in determining appropriate charges that will be passed up to the next layer on the cloud computing stack with each layer in the stack introducing its own meters derived partially from lower level meters - partially because there must be value added somewhere.

Once we get above the bare metal platform I expect to see more diversity in costing and billing approaches. Currently we seem to have carried over a large amount of baggage tied to current (legacy in this context) enterprise system/network management approaches that provide very coarse grain resource metering at the process level or data traffic pattern levels. I am confident this will change to more (user/software) activity based costing with the metering correlated to actual software execution performed on behalf of the user or cloud service. Unlike our opaque OS based process containers threads of execution in the cloud will operate as lawyers do today - billing the client context for every activity perform using various meters (wall clock time, number of photocopied sheets, number of letters dispatches with postage,........). Threads will not touch a resource unless they have a client billing code. This will never be possible with ESM/NSM because one cannot see the computing above it and the other below it.

http://www.jinspired.com/products/jxinsight/meteringthecloud.html

Kind regards,

William


Christopher Drumgoole wrote:

Given the variances in CPU clock speeds, Gigahertz Hour is easier to

compare.

---

Chris Drumgoole 

-----Original Message-----

From: cloud-c...@googlegroups.com

[mailto:cloud-c...@googlegroups.com] On Behalf Of Pittard, Rick

Sent: Tuesday, December 16, 2008 11:50 AM

To: cloud-c...@googlegroups.com

Subject: [ Cloud Computing ] Re: Compute surface as a traded commodity?

Actually, the price of a barrel of oil is for a very specific grade at a

specific location.  The real prices vary depending on quality and

location - maybe just like a CPU-hour should.

Rick

-----Original Message-----

From: cloud-c...@googlegroups.com

[mailto:cloud-c...@googlegroups.com] On Behalf Of Jim Houghton

Sent: Tuesday, December 16, 2008 9:16 AM

To: cloud-c...@googlegroups.com

Subject: FW: [ Cloud Computing ] Compute surface as a traded commodity?

Interesting thread ... I had discussions with executives at a large

investment bank (one of the few still around today!) as far back as 2002

when we were implementing large grids for risk & portfolio analysis that

leveraged 'scavenged' resources for some of the compute footprint.  I

agree

this will happen, but interoperability is not the only obstacle.

Placing

security off to the side - let's assume for the discussion someone has

already overcome their technology or compliance hang-ups - there is a

major

business challenge to overcome.

We all know what an ounce of gold, or bushel of corn, or a barrel of oil

is

around the globe.  So what is the equivalent unit of trade for computing

cycles?

Think before you answer ... 'CPU hour' just wants to jump off your

tongue,

but as we all know not all CPU's are created equal (even by the same

manufacturer).  Then of course there's memory, bus speed, network

bandwidth,

network throughput, operating system, latency to/from your origination

point, disk read/write speed ... I could go on and so can you. I've been

living this for 6+ years working with clients who want to build internal

utilities (clouds), and even there it's difficult to get agreement as

this

forms the basis for what they are going to get charged for the resources

they consume.  It's not much of a 'utility' if users got a flat annual

allocation charge, is it?  Yet that's by far the most common situation

in

large enterprises today.

There's the closet economist in me who feels (hopes) someone will just

start

such a market and soon thereafter the laws of supply and demand will set

the

appropriate prices.  Those with high quality service will be sold out

and

can increase their prices, with the reverse also true.  However,

especially

with the current state of global economic affairs, I am doubtful it will

happen anytime soon.  Nor do I think we can count on any standards forum

to

tackle such an issue, and the major vendors will undoubtedly look at

normalization (translate: commoditization) of their technologies as a

bad

thing.

Anyway, hopefully this provokes some thoughts - look forward to your

responses.

Jim

_________________

Jim Houghton

CTO and Founder

Adaptivity, Inc.

(845) 494-9419

www.adaptivity.com

-----Original Message-----

From: cloud-c...@googlegroups.com [mailto:] On Behalf Of Simon

Plant

Sent: Tuesday, December 16, 2008 7:03 AM

To: cloud-c...@googlegroups.com

Subject: [ Cloud Computing ] Compute surface as a traded commodity?

Bruce wrote:

Will the "Cloud" ever become a pool of hosting providers who pitch

their

prices, SLA's and storage cost so customers will come to their "cloud"

for

services?

I foresee a time into the future where the compute surface is

virtualized

and standardized enough that hosting contracts can be traded as a

commodity

on a market, rather than the RFP type process we have today. 

Such agreement would allow business to place a deal on an exchange much

like

FX today and get bids to run based on some parameters.  IT hosters would

price the deal with a spread in the same way as a currency trade today,

the

deal done in a matter of seconds and hosted for the duration of a

contract

window.

If virtualization vendors deliver on their hybrid end-vision, this could

[Tim Freeman]

On Tue, 16 Dec 2008 16:52:17 -0500
"JL Valente" <jlva...@cittio.com> wrote:

> As usual on this group we have very different camps and opinions which makes
> the whole debate quite useful. But again I don't think that this an either/or
> proposition. It depends who the "end user" is really. Some of the ones we are
> dealing with go deep and require serious metrics and understanding of what
> they are really getting from their cloud provider.

MAybe from a sales perspective, but if we are truly talking about getting 'IaaS
units' traded as a commodity in some future, it probably better be just one,
agreed-upon set of metrics.

I think we have a general consensus that this involves much more than hardware
stats, including external-to-the-host factors like latency and throughput
in/out of the facility and internal choices like VMM versions and
configurations (with both versions and configurations, there are a LOT of
precarious things that will affect performance).

I don't see how it could be done without a set of comprehensive benchmarks
routinely run on the providers (hopefully by auditors we can trust).

Tim

> at the pump. Now, I don't know what goes into the regular gasoline blend___how
> much is West Texas sweet light, or Brent light or Saudi heavy oil___and, guess

> what, I don't care. The regular gasoline is good enough for my 8-year old
> Jeep and that's all that I need to know. Similarly, end users don't want to
> be confused by a huge menu of CPU speeds, memory allocations, bus speeds,

> etc. ___ if you keep it simple, then they will get it (as long as they can

[JL Valente]

Wholeheartedly agree on all your points including the last one.

[sh...@viawest.net]

Simon,

Note that OVF is now a standard at DMTF, and has been implemented by
many of the virtualization vendors.

Steve Hand

On Dec 16, 12:55 pm, "Simon Plant" <si.pl...@gmail.com> wrote:
> 2008/12/16 wayne pauley <wayne_pau...@hotmail.com>>In the meantime - we need to focus our efforts on the challenges in front

[Shane Brauner]

At the end of the day, you want to make sure you get what you pay for, and only pay for what you want and care about.

You can parse this down to clock speed, GB Memory per core, bandwidth & latency - but at the end of the day, what really matters is your application's end-to-end performance.  When someone hits your application, how fast does it respond?  Does that response rate hold true under 10000x load?  And in a federated cloud where you've got your 10gen App server running on a compute system at Peer1 using storage from S3 - whose throat do you choke if that magic number isn't met?

That kind of accoutability/SLA/performance is going to be a cost driver for many organizations.  Add to that the complexity and cost of things like audits and corporate compliance, and $/cpu hr doesn't quite cover things. 

If youv'e set up a compute grid between organizations (even on a campus or within a company), you know that the politics and SLAs involved are just as (if not more!) challenging than the technical side of just getting it to work.  

It's going to be interesting to see how the market adapts to these challenges

Shane
--
http://www.10gen.com/
http://twitter.com/shanebrauner