A financial brokerage model for cloud computing

It is generally accepted that on-demand pricing for cloud computing resources offers benefits to consumers [1, 2]. They have full operational control of costs by being able to start and stop resources on demand, and they do not have to engage in the capital expenditure of building their own infrastructure, hiring IT systems support staff, or investing in maintenance of physical machinery. Furthermore, if different providers of cloud computing resources could interoperate, a federated cloud would in principle allow units of cloud-computing resources to be traded as commodities on an open marketplace, thereby allowing for the price of resources to smoothly vary while the market mechanism enables matching of consumer demand to provider supply [3].

But would open on-demand trading of cloud-computing resources with variable pricing actually benefit a cloud service provider? Purchasing goods and services in advance of delivery allows the provider to plan and prepare for the future. How can the provider ensure they are maximising profit and reducing cost if they must provide resources without knowledge of future demand?

Such knowledge offers benefits to providers in multiple ways. The provider must ensure that there is a physical capability for demanded resources, but when consumers engage in on-demand pricing the providers must predict what usage is required, and ensure that the infrastructure is there.

When do they invest in new infrastructure? As manufacturing processes improve and economies of scale increase, the real cost of infrastructure decreases while its technological capability increases. So it is better for the provider to wait for as long as possible before investing in additional capability so they get the best value for money [4]. But how do they know when is the best time?

As for any business, the provider has variable costs, which are related to the output being generated. How can these be planned? Running a thousand servers instead of just one will require many more support staff and engineers: if too few are employed, failures can mount up and cause service outages or downtime. This downtime is not only costly in terms of SLA (Service Level Agreement) penalty fees and refunds, but also in terms of reputational risk; yet if too many are employed, expenditure is wasted on staff that are surplus to requirements [5].

Electrical power consumption is another key variable cost [6]. If the provider has a good view of future energy demand, they may gain a discount by forecasting their requirements and supplying this to their energy supplier.

It is also difficult to schedule customer instances to servers efficiently, without advance notification of usage [7, 8]. Most cloud computing providers require no duration of execution to be stipulated when the instance is started. So efficiently scheduling instances such that the number of powered servers is reduced is a very tough challenge.

A simple method of capacity planning is simply to track trends in demand, and ensure there is enough capacity (with an additional margin) to meet the maximum previously experienced. However, enterprise cloud computing resources have only been available to consumers for a relatively short amount of time, and it is likely that demand information is too variable and incomplete to build a reliable forecast without the considering users own predictions.

Currently, most providers offer fixed price models for immediate delivery. Market-leader Amazon Web Services (AWS) also offer a spot price model, where the price varies depending on current supply and demand, and winning bidders gain access to the resource until the spot price moves above their maximum bid. These schemes do not aid in capacity planning.

There are a number of alternative schemes that could be used. Users could instead purchase derivatives contracts, which give the user contractual rights to a resource at some specified later date [9]. Futures contracts are a type of derivative that give buyers guaranteed access to the resource in advance of when it is delivered, usually in return for an upfront payment on signing the contract followed by a final settlement when the resource is delivered: the user is obliged to take ownership of the resource on the delivery date that the contract specified. Alternatively, options contracts give buyers the legal right (but not an obligation) to purchase a resource for an agreed strike-price on (or sometimes on-or-before) some later delivery date [10]. Derivatives such as futures and options are commonly used in a number of commodity markets for industrial inputs such as wheat, oil, natural gas, and metals, and various types of financial derivatives have also in recent decades become notoriously commonplace in the global financial markets for equities, currencies, and bonds.

In a limited sense, current commercial cloud-computing vendors are already offering both spot and forward contracts. Amazon Web Services (AWS) is a major supplier of cloud infrastructure services, and in the AWS terminology a remotely-hosted virtual machine and its associated software is known as an Amazon Machine Instance, often abbreviated to AMI or simply referred to as an instance. AWS offer two types of fixed price asset classes: On-Demand Instances and Reserved Instances. AWS on-demand instances are fixed-price resources that are delivered as soon as they are purchased, and the purchase price is set by AWS. AWS reserved instances allow users to pay a reduced price per unit time for a resource, by paying an upfront fee. This fee guarantees them a reduced on-demand charge for a specified period, either 12 or 36 months.

The key question that we explore in this paper is this: is it possible for a cloud-computing services broker to use these derivative contracts in combination to reliably provide cheaper resources to the consumer and also aid in predicting future usage?

A broker makes a profit by matching buyer's demands with seller's supplies: the broker uses a variety of methods to achieve a best price between these parties, and typically makes a profit either by taking a commission fee from any completed deal, or by varying the broker's spread, or some combination of fees and spread. The spread is the difference between the price at which a broker buys from sellers and the price at which it sells to buyers.

In a commodity market where goods cannot be differentiated between suppliers on any basis other than price, all that matters to the buyers is that they pay a price they are comfortable with, and all that matters to the sellers is that they receive a price they are also comfortable with [11]; typically the broker's fee and/or spread are tolerated by the buyers and sellers because the broker acts as a provider of liquidity: the buyers and sellers do not have to spend time finding potential counterparties to their transactions and then negotiating with them, and they do not have to worry about there ever being no counterparties to trade with.

The broker aims to satisfy these parties' requirements while ensuring that he or she makes a profit. In this work, we focus on a simple way of achieving this by purchasing advance rights or obligations on resources, via derivative contracts. When the derivatives contract matures and the corresponding resources are delivered, the broker can then sell the resources to clients who need to use them: in this context, the broker is using the derivatives as a mechanism for hedging risk in the uncertainty over future demand and supply.

The broker's skill lies in forecasting when to purchase the resources in advance and when to simply provide their clients with resources purchased directly from the spot market or from the broker's own private stock of resources.

A simple broker model consists of two stages. In the first stage, the broker plans what to buy. The broker will make a forecast of demand, determine what and when to buy and then will make any advanced purchases from the provider.

In the second stage, clients approach the broker for a resource. If the broker has previously purchased a resource, they can sell it to the client for a profit if the cost is less than the client wants to pay. If not, the broker must purchase an on-demand instance and provide it to the client.

But how can the broker effectively predict usage? Wu, Zhang, and Huberman suggested a two-period model (which we refer to hereafter as the WZH model) for resource reservation in which in the first period the user knows her probability of using the resource in the second period, and purchases a reservation whose price depends on that probability [12].

Consider N users who live for two discrete periods. Each user can purchase a unit of resource from a service provider to use in the second period, either at a discounted rate of 1 in Period 1, or at higher price C, where C > 1, in Period 2. In Period 1, each user only knows the probability that they will need the resource in Period 2--it is not known for certain until the next period.

f(q _i ) if resource is required

g(q _i ) if resource is not required

The contract can be regarded as an option if g(q _i ) is paid in Period 1 (i.e. as a premium), and f(q _i )-g(q _i ) is paid in Period 2 (i.e. as a price) should the resource be required. In Period 1, the resource is reserved, but the user is not under any obligation to purchase.

Wu et al. showed that if the following conditions could be met, the Coordinator would make a profit:

The following truth-telling conditions are not completely necessary, but are useful, for conditions A and B to hold:

In previous work [13], we validated Wu et al.'s claims though simulation experiments and showed that a simple evolutionary optimization process operating on an initially maximally dishonest pool of users results in the pool of users becoming more honest over time when interacting with the WZH system.

The WZH model can be used to forecast demand as it encourages users to submit an honest estimate of future usage by rewarding them with a reduction in cost over time, compared to buying direct from the provider at the higher rate C.

In our model, we refer to the Coordinator as the broker, as the Coordinator performs a role traditionally performed by a financial broker. In the first period, the broker asks each user i to submit a probability p _i in advance that they will use a resource, and pays a premium g(q _i ).

The broker sums these probabilities, which is the forecast of how many resources will be required in the next period.

Once a forecast has been made, the broker must make a decision on whether to hedge the risk and invest in a reserved instance, or to wait until the next period and buy an on-demand instance. The broker does this by comparing the performance of a reserved instance over the past instance term and comparing it to the amount of capacity it currently has available through reserved instances over the same period in the future. It considers whether another purchased reserved instance will be suitably utilised such that it gives better returns than delaying the purchase and buying on-demand later. The broker does this by using a variable called the threshold--if the resource is likely to be used more than the threshold it invests; if not, it does not. In the rest of this paper we denote the threshold by θ.

The margin resource utilisation (i.e. the likely utilisation of an additional reserved instance) is calculated as follows:

Previous demand profile A = [d _t-36........ d _t ]

Future capacity profile B = [c _t........ c _t+36 ]

Deficit profile C = A - B

For each resource required, the

Marginal Resource Utilisation (MRU) is the ratio of items in C > 0, and the key decision is then:

If MRU > θ: Buy reserved instance and therefore increase current capacity profile;

If MRU < = θ: Do not invest, "wait and see".

In the second period, users choose if they should execute their right to use the resource. If they wish to, they pay f(q _i )-g(q _i ) to use the resource.

The broker gives the user access to one of their previously purchased reserved instances for the full calendar month. If the broker has not purchased enough, it buys an on-demand resource from the provider. Potentially, the broker could also offer fractions of months for a reduced price, but in our model here, we only offer full-month resources.

We now present results from our computer simulation experiments that explore the performance of the WZH system. The simulation, which was programmed in Python [14], was developed to explore the dynamics of the WZH model in situations where supply and demand fluctuate in patterns directly inspired by historical records of economic activity in a number of distinct real-world market sectors. For each sector, simulations were implemented with a pool of 1000 user agents submitting probabilities, and each simulation was run 100 times with systematic changes in threshold θ, between 0 and 1, in increments of 0.01. These simulations were run for reserved instance contract lengths of both 12 and 36 months. Further details of the simulation are as follows:

Market demand data

We are not aware of any public-domain real-world data-sets showing historical demand data for cloud computing resources, aggregated over a large number of users, over the kind of timescales that a broker such as the Coordinator in the WZH model would need to operate on. Nevertheless, intuitively, we can expect there to be periodic fluctuations in demand from any one user, and yet we can also expect that in some market sectors there will be significant correlations in demand from the population of users (or "user-base") within that sector. If demand across all sectors is sufficiently decorrelated, then aggregate demand would be a constant "white noise" and provisioning for that demand would be relatively straightforward.

However, although such an aggregate white-noise steady-state of demand would be desirable, it is unlikely to be achieved in practice for sustained periods. It is the presence of difficult-to-predict peaks and troughs in aggregate demand from real-world markets that makes the problem of adequately provisioning for that demand a deep and challenging research issue-- the research issue that is addressed here. For this reason, we have used public domain data on real-world market activity that can plausibly be argued to serve as a good proxy for real-world demand for cloud computing in certain market sectors, and where there are known to be peaks and troughs. Our belief is that by demonstrating success on this real-world proxy data, we can plausibly claim that success of our system would also be likely for any other similarly fluctuating pattern of demand.

We assume that demand for computing resources by an e-commerce application will be related to sales being executed by the application (for example, an increase in on-line sales will result in an increase in web server and credit card processing). Following this assumption, datasets were obtained from the UK National Statistics Office on the Non-Seasonally Adjusted Index of Sales at Current Prices from 1988 (earliest available) to 2011 for four different market sectors. These four sectors were chosen as they have a strong relationship to IT usage and they vary differently over the period, therefore allowing the new model to be evaluated in a number of market conditions. The duration over which these statistics were gathered represents a typical period of modern times where demand has changed frequently, with times of both recession and growth. As such, it is a plausible model of market variance. The demand patterns were normalised between 0, where none of the N users submit a resource request, and 1, where all N users submit a resource request. This allows the model to be assessed between the extremities of low and high demand.

All of the demand profiles showed regular annual patterns (such as large increases around Christmas), but to aid evaluation each profile is assigned a name appropriate to its market behaviour over the entire period:

Rapid growth market

(Figure 1)--Data on Non-Store Retailing: All Businesses--Little annual growth followed by rapid growth over smaller period.

Steady growth market

(Figure 2)--Data on Non-Store Retailing: Large Businesses--Steady annual growth throughout.

Recession and recovery market

(Figure 3)--Data on Non-Store Retailing: Small Businesses--Shrinkage in annual demand followed by period of recovery.

Steady market

(Figure 4)--Retail of Computer and Telecoms Equipment--Some peaks and troughs but fairly steady throughout.

Broker pricing

Users are charged a price to access the instance for a calendar month based on the values of f(p _i ) and g(p _i ) suggested by Wu et al:

$g(p_i)=\frac{k{p}_i^2}{2}\text{if}\text{required}$

$f(p_i)=1+\frac{k}{2}-k{p}_i+\frac{k{p}_i^2}{2}\text{if}\text{not}\text{required}$

To incentivize users to use the broker's service, it must save them money compared to going to the provider direct.

If the user is submitting honestly (which was proven by Wu et al. to benefit the user), they will expect to pay:

$w(p_i)=p_{i}f(p_i)+(1-p_i)g(p_i)$

If they purchase resources directly from the provider, they will expect to pay: $w(p_i)=C{p}_i$ where C is the on-demand cost of a resource.

Figure 5 shows the pricing model for the simulation. Wu et al.'s original pricing equations were based on an on-demand price of $2. In our simulation, the cost of an on-demand instance for the entire month is $60. Using a simple iterative algorithm, it was found that increasing Wu et al.'s original pricing equations by a factor of 35 maximises the brokers profit, while remaining cheaper for the user than using the providers service directly.

Although the broker in our model is only offering monthly options, in a practical implementation users would be free to purchase additional on-demand capability from the provider or broker for smaller units of time during periods where demand is above their current quota of options. Where the application has been built to rapidly scale automatically on a cloud infrastructure, this allows a user to make cost reductions through forecasting, without being confined to a limited amount of resources.

An extension of the WZH mechanism was proposed and implemented in an agent-based simulation using real-world economic demand data, using current costs of an Amazon Web Service cloud instance, and where users submit probabilities based on previous demand. It was found that the broker profits in such a situation in a number of market conditions thereby demonstrating that a stable commercial implementation is feasible. It was also found that the broker can increase profits by considering past performance and purchasing longer-term contracts.

In the worst case scenario discussed in this paper the broker still makes nontrivial profit. Small changes to the broker's operating procedures such as purchasing longer term reserved instance contracts can improve profits by over 30%. Considering past performance can also reward the broker with increased profits, by up to 36% in one experiment discussed in this paper. In ideal market conditions, where longer term contract terms are used and an optimum threshold set, profit was seen to increase by 165%.

The WZH mechanism provides a useful theoretical foundation for an options-market in computing resource. However, the service provider would have to provide specific pricing to support the Coordinator, and this might not always be profitable for the service provider. Our extension to this model does not require new pricing to be agreed, but contract restrictions on reselling may be a barrier to commercial implementation.

Our work shows that financial brokering in computing capability has potential as a viable commercial proposition, and that all parties can potentially benefit as a result of such a system. The advantage of this approach is that a forecast of future usage requirements is obtained, which can be subsequently used to plan future capacity requirements and so that targets on performance as detailed in a Service Level Agreement can be met.

The optimum threshold is the value at which market demand is fully anticipated by the broker and which is fully provisioned through reserved instances. Determining this threshold mathematically is likely to be challenging due to difficultly in determining market dynamics over a very long period. However, an empirical simulation using actual market data could produce such a threshold for commercial implementation. It may also be possible for the broker to track performance, and update its threshold in real-time.

Further work should be carried out to translate this forecast information into tangible benefits for the provider, which might include automatic purchasing of electricity swing options, staff scheduling, or more efficient distribution of workloads to meet SLA's.

We believe that the results we have presented here clearly demonstrate that options and other financial derivatives contracts, when appropriately applied and developed for cloud computing, offer benefits to both consumers and service-providers, and (crucially) the brokerage function can also be a profitable business too. Combining the forecasting benefits of both American and European options and other derivatives with the convenience of existing spot and on-demand pricing is likely to benefit all participants in cloud-computing markets: providers, users, and intermediaries.

By taking the results from this paper and extending them with future research into the performance of the extended WZH model under different conditions and in different segments, a commercial offering that is profitable to the broker, beneficial to the user, and with a calculated level of risk looks likely to be readily achievable.

Owen Rogers is a doctoral researcher at the University of Bristol. Owen graduated from Cardiff University with a MEng in Computer Systems Engineering in 2005. Following this, he joined telecommunications firm Cable & Wireless, first as a Graduate Engineer, and then as Product Development Manager for Managed Security Services. In 2009, Owen joined managed services provider Claranet as Product Portfolio Manager, before returning to academia in 2010. He is currently researching financial mechanisms for improving cloud computing's potential as a tradeable commodity. Owen is a Chartered Engineer through the British Computer Society.

Dave Cliff is a professor of computer science at the University of Bristol. He has previously held faculty positions at the universities of Sussex and Southampton in the UK, and at the MIT Artificial Intelligence Lab, USA. He also spent seven years working in industrial technology research, first for Hewlett-Packard Labs and then for Deutsche Bank's Foreign Exchange Complex Risk Group. Since 2005, Dave has been Director of the UK Large-Scale Complex IT Systems Initiative (http://www.lscits.org). He is a Fellow of the British Computer Society.