Different scenarios require different markets

Up until now, I've never really blogged about different type of markets as exist in other commodity markets. With different type of markets, I mean markets that trade commodities within different time frames. That is, in a normal commodity market model, a difference is made between a futures market and a spot market. When thinking about a cloud computing resource market, it is not difficult to imagine these market equivalents. That is, in a cloud resources market, cloud computing resources can be traded for a specific time frame in the future or directly on the spot. There is however, also a 3th kind of market that needs to be considered: the on-demand market. The on-demand market trades - as the name implies - cloud resources that are requested on-demand; which means that the resources need to be directly accessible, but that no additional information is given by the consumer on how long the resources will be needed.

While all 3 market types share a lot of ideas (e.g. constraint language), each one also has properties that make them different from the other types. Let's have a more in-depth look at each of these 3 markets.

Futures market
If we take wikipedia's definition of a futures market, we can modify it so that it can be applied to a cloud setting:

A futures exchange is a central cloud resource exchange where people can trade standardized futures contracts; that is, a contract to buy specific quantities of cloud resources at a specified price for a specified time interval in the future.

In other words, if we put this on a timeline, a cloud resource future contract is a contract that is traded on time t, that specifies a specific amount of cloud resources (that meet certain constraints) that need to be available from a time t+x until a time t+y.  

Trading on the futures market allows providers to do better resource provisioning in their datacenters. Since trading resources on the futures market allows providers to reduce risk (that is, they can reduce the risk of having idle resources at some time in the future), future markets usually offer resources cheaper than on the e.g. on-demand market. However, there are many situations in which this can be different (e.g. if the electricity prices are expected to be higher in the future, than the future price of an ask might be higher than the current (on-demand or spot price) price).
Speculating on future prices (either by going short or going long) might result in significant financial gains or losses. These principles are not new, and are an inherit part of any futures commodity market. Making future markets a part of my market model is therefor absolutely necessary, if the model is to be considered economically viable.

It might be interesting to combine the on-demand idea (that is, not obligating the consumer to specify when a resource is no longer needed) with the idea of a futures contract. That is, it might be intersting for a consumer to specify that it he will need a specific set of resources in the future, without needing to specify how long he will need them.

This is however, not very interesting from the provider's point of view since in this scenario he no longer has any garantuee on how long the resources will be used. However, if we allow a user to specify a minimum end time and a maximum end time, we allow the provider to make fairly accurate resource provisioning plans while at the same time giving the consumer more flexibility in time specification. This is especially helpful when it is hard for a consumer to specify exactly how long he will need the resources, while it is fairly easy for him to give a minimum running time.

The futures market model as proposed here fits quite nicely in the market model I've been developing until now. For the futures market, an offer (both ask and bid) should contain:

• metainfo
• a price (minprice for asks, maxprice for bids)
• a timeconstraint (which timeframe is being considered)
• a set of constraints (resources, legal, etc)
• an expiration date (until when is the offer valid)

Spot market
Let's again modify wikipedia's definition of a spot market to get a definition for a cloud spot market:

The cloud spot market is a public cloud computing resource market, in which cloud resources are traded and delivered immediately.

Spot market timeline, a bid starts at a time t and runs until t+3 when the spot price of the provider exceeds the maximum price of the bid

Spot markets typically represent the immediate need of the market, that is, providers will sell current overcapacity on the spot market, while consumers buy current undercapacity on the spot market. If demand is high, spot prices will be high, when demand is low, spot prices will be low.
A spot price is the price of a single unit of trade on the spot market. This unit of trade is always exactly defined. For example, on the gold spot market, gold is always traded per 1000 ounces. The spot price at a given time thus reflects the value the market attaches to 1000 ounces of gold at that moment.
However, as with electricity (to some extent), a cloud computing unit cannot be expressed in a single dimension, since the heterogenity between different cloud resources is so large. Multiple dimensions (price, time and type) are indeed needed to specify a single cloud unit. This makes spot trading more complex. In order to trade on the spot market and keep things simple, we will thus have to set one of these dimensions to a fixed value in order to compare separate offers with each other. For now, I fix the time dimension to a single hour (this is also done in the electricity spot market). This means that the price and constraints can vary between offers, but the timeframe for which on offer is valid is always defined as a single hour.

This also implies that cloud providers and consumers will need to resubmit their offers before the start of the next hour. This allows both providers and consumers to adapt their prices based on their current needs.

Although this model works, it does not take into account that consumers might want to buy resources on the spot market for several hours at once. That is, cloud spot markets (such as Amazon's EC2) are primarily used to run lower-importance applications as long as the current price of the spot market does not exceed a certain threshold. In the model I just described, consumers need to re-buy cloud resources every hour, which implies migrating applications every hour. Obviously, this is not the desired behaviour. We can solve this by adapting our bidding language to reflect cloud spot market principles.

An spot-ask should then contain:

• meta-info
• the current spot price for the hour
• a set of constraints (resources, etc)
• no timeconstraints
• no expiration date (an ask always expires after a single hour)

While a spot-bid contains:

• meta-info
• a maximum price
• a set of constraints (resources, etc)
• no timeconstraints
• no expiration date

A spot-bid will then match with a spot-ask, if the price of the spot-bid is lower than the price of the spot-ask. A match implies a contract between provider and consumer of undefined duration. However, this contract can always be broken by the consumer (on-demand character of spot market), and should only be broken by a provider when it's current spot price becomes higher than the maximum price specified by the consumer in his bid.

Although spot markets allow a lot of immediate flexibility for both consumers and providers, the spot market does not provide consumers with any garantuee on how long their instances will be able to run. That is, it could be that the spot price of a specific provider is very low at a given moment, and very high the next hour (which probably results in a shutdown of the consumers instance, since the spot price would exceed the consumers maximum price). Surely, a slightly more expensive provider that has less volatile spot prices might be more interesting, since the probability that an instance running on that provider is shutdown is a lot lower. This is especially so for jobs that have a high startup cost.

In order to accommodate this desire, I propose to use price history constraints on both spot bids and asks. Such a constraint might for example assert that the average spot price (over a certain time frame) of a specific provider does not exceed a certain value. Using such constraints allows the consumer to have better garantuees over the volatility of the spot price.

Of course, using such constraints raises an issue of trust. Can a provider be trusted to deliver correct history constraints? Probably not. Therefore, cloud providers should use brokers that independently monitor the provider's spot prices and attach the history constraints to the provider's ask when submitting the ask to the market (Note: to bootstrap this mechanism, the data from e.g. cloudexchange.com can be used). Using the custom constraint mechanism discussed in my previous post, these brokers can then distribute their price history constraint to consumers.

On Demand Market
As already said before, on the on-demand market, the traded cloud resources should be directly available, but the consumer does not need to specify how long he will be using these resources.

On demand market

To implement the on-demand market, we again need to slightly adjust our bidding language:
A offer (bid or ask) should contain:

• metainfo
• a unit price
• a unit time granularity
• constraints (resources, etc)
• an expiration date  

That is, an offer should both contain a price as the time indication for which this price is valid. For example, an offer can have a price of 10 ct for a single hour or 100 euro for 1 month. Using this bidding language allows providers with different accounting granularities to participate in the market.

However, if we wish to keep using the price sorted queues (as used by the continous double auction), the market will need to normalize the prices in the queues (e.g. price per minute) and take into account the unit time granularity as an extra timeconstraint when matching offers. Although this makes the matching algorithm more complex, I believe that the improved flexibility for providers justifies this.

Now, the question poses itself, what if the user knows how long he will be using a certain set of resources but also requires his bid to start immediatly. Does this kind of bid that requires a direct start but that also specifies an end time 'belongs' to the futures or on-demand market? The answer is that it can 'belong' to both. However, one would reasonably expect that an offer on the future market is cheaper since the insurance that a resource is used for a specific time frame is worth something for a provider (recall that reducing risk for the provider is the primary idea behind the futures market). By introducing a DurationConstraint alongside timeconstraints in the futures market, we can allow offers on the futures market that need to start directly while garantueeing a minimum resource usage for the provider.

Combining on-demand and futures market

Obviously, an end-user should not need to choose on which market to submit his offer. Brokers should submit a consumers bid on both the futures and on-demand market, and return the cheapest match. Note that in order for this to work, the market must allow matching without obligations for both consumers and providers. Allowing this complicates things, since in such a scenario we need a seperate service that contacts both the provider and consumer to seal the deal. I might shed further thought on this issue in the future since I think it is a good idea to add the match execution verification (do consumer and provider hold their promises?) to the same kind of service.

Component Based Pricing

I'm not entirely sure yet how the component based pricing reverse auction I discussed in the previous blog post fits in the models I just discussed (does every market have a seperate reverse auction, or is there a seperate reverse auction that is shared between the different markets ?). I will be exploring this further in the coming week.

That's about it for now :-) Until soon.