Will CPU trading enable an FX market??

I met with Roger Day, Sun's Engineering Director responsible for building Sun's Utility Grid. We had a long conversation. I was eager to explore how one makes the outputs of the grid homogeneous, since the homogeneity of the commodity is one of its axiomatic qualities. He asked me what I thought of the idea of an exchange. I replied that my view is that if we can create a primary market, and it looks like we can, a secondary market will follow. I wonder though if people will look to exchange Solaris CPU/hours for AIX or even Windows CPU/hours. Will we have a cycle FX market?.

tags:

Comments:

This is an interesting subject, and something I've been thinking a lot about lately.

I think the short answer to how to set the price of CPU-hours is to leave it to basic market forces - supply and demand. I see no sane way of creating a fixed price ratio between different system types.

Basically, every customer's program will have a different profile in how it taxes the system. Given this, for a particular workload the amount of work gained from an hour of CPU time is different for every system type. So it would be up to each customer to profile their application and make bids based on that. So if system-A is twice as fast as system-B for a particular workload, then the customer would be willing to pay up to double (maybe more if they care about single threaded performance) for a CPU-hour on system-A.

Conversely, supplies would supply more of whatever system type has the best margins, which of course would depend on their capital and running costs (different OSs would also have different running costs).

From an overall market perspective, the fewer different types of systems offered the better, since it makes life easier for customers. Suppliers may be able to provide "guidance" (eg based on SPECint, SPECfp, common applications or whatever) but basically it should be up to customers to solve their own problems well - like with buying/selling shares.

Given that customers would need a "developer grid" to develop and testing their grid applications, they would get benchmark data from that.

A problem that I only just thought of however, is "what next?" after making a purchase. If the buyer gets a particular number of CPUs in a particular time-slot, that's easy to arrange - though there is the issue of what to do if a customer's job takes longer to complete than the time-slot allowed for. But what if you want fully dynamic allocation of CPUs and precise metering (you only pay for the fractions of CPU-hours that you actually used)?

In such a scenario, the number of available CPUs will be variable since current jobs could end at any time, and new ones could be launched at any time. If the supply is constantly variable, then the price should be too (laws of supply and demand). So what does a buyer get when making a purchase? If you buy X CPU-hours at $Y per CPU-hour, do you have to use it immediately (bad for buyer) or can you use it at any time (bad for supplier)? I don't think either would work.

I think the only way to do this would be to submit a job together with a price. That price is effectively the buyer saying "this is how much I'm willing to pay" and from a CPU allocation point of view, becomes a priority - the grid controller will give highest priority to the most expensive jobs. If a job has a fairly low price (priority) then it may not get processed for some time, and would just sit in a queue. Might want a way for customers to change the price of a job after it has been submitted (though this might make metering "interesting"), or to terminate it if it's still in the queue.

So instead of an exchange in a normal sense to allow customers to choose a grid provider and system type, I guess what they'd need is a portal of some kind, showing current average prices (maybe with a histogram of demand) for each option.

I hope that makes some kind of sense...

Posted by Chris Rijk on March 22, 2005 at 04:12 AM PST #

This is an interesting idea, seeding secondary markets from the grid. Beyond the straight commodity FX analogy, I see a added value market emerging, which I will dub "pimp my batch" (In the sense of "pimp my ride" car customizing show for the non-US folks). I see people submitting / contracting their jobs to grid aggregrators / managers who abstract the underlying (sp?) grids, tune the jobs, segment the jobs and track/schedule thm across many diverse grid providers. Kinda like RSS in reverse . . . We already see this within in other commodity markets.

In response to the previous comment:
I think the only way to do this would be to submit a job together with a price. That price is effectively the buyer saying "this is how much I'm willing to pay" and from a CPU allocation point of view, becomes a priority

The pure payment = priority is too variable for most people's SLA/SLOs - the user is taking all the risk here. Most of the time, users are willing to take some risk but not all. I think this will take a queue from help desk SLA/SLO methodology, you will submit a job and SLA bucket, and the provider will take the risk to capacity plan and schedule the resources. Imagine, high priority jobs queued and/or queued+delivered within 3hr, mdeium priority within 6hrs, etc.

Posted by Ken Pepple on March 22, 2005 at 04:37 AM PST #

Very interesting view - one I've thought about a lot. I think Sun have an ideal opportunity here to innovate and create new market for precisely this kind of compute unit. I think the idea could be expanded a lot further too - take pure exchange mechanisms of supply and demand, and add in the option of exotics etc, and you could create a situation where companies are effectly able to hedge their end of year processing requirements, or perhaps 'buy' competitive advantage (ie, reduce time to market) by looking at the cost / benefit equation of running exotic pricing models quicker. The only issue I see is that of the definition of the commodity. It would need a set of attributes, expressed in business, service and computing terms which would be commonly portable and platform independent. Did someone say Java ? True markets are driven by supply and demand - rather like the idea of selling units on eBay (which could be used a test market ?) by creating the exchange - it may be that the accessability of the final commodity (ie, its portability) would be the principal driver behind its price. The availability of high bandwidth communications has been a key enabler of this.

Posted by Jonathon Traer-Clark on March 22, 2005 at 05:48 PM PST #

I have no doubt that once retail grids exist, customers will start to trade contracted time. This will be particularly true since some of the early adopters will be experts on the time value of delivery contracts. I don't think any of us are arguing about that.

What interested my was that like Foreign Exchange, where you must pay your debts in the incurred currency, programs can only run in their compiled state which requires a given CPU architecture. I'm not sure where the primary exchange market comes from, but a secondary market is very real possibility.

One big difference, is that I can't see a central bank role.

Posted by Dave on March 29, 2005 at 03:46 PM PST #

Post a Comment:
Comments are closed for this entry.
About

DaveLevy

Search

Archives
« April 2014
MonTueWedThuFriSatSun
 
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
    
       
Today