On the other hand, if the system is unable to perform such a task for an extended period, or there is a larger overhead due to scheduling [4], running more slowly on available systems may be specifically advantageous depending on the value of the results and time at which they are provided. These factors of price, performance, time to completion (availability), likelihood of completion (probability of failure) and penalty (liability) are key to being able to produce such a comparison service, and necessary alongside the description of the required service itself in order to populate the SLA.

In this chapter, we build on previous work in SLAs through experiments with a public cloud, a private cloud and a grid system to determine the relative costing as would be required for such a price comparison service. We use a Value-at-Risk (VaR) Monte Carlo Simulation on a public cloud (Amazon EC2) to obtain costing information, and contrast the performance with a private cloud (Eucalyptus install at the University of Surrey) and grid system (Condor install at the University of Surrey) to determine an exchange rate. While a recent study compared performance characteristics of EC2 and Eucalyptus, addressing storage, CPU, network transfer and network latency [1], start-up time for these systems appears not to have been accounted for, yet can be a major overhead for large numbers of short processes. Applications such as VaR emphasise the importance of overall time to completion, and a Monte Carlo approach is readily parallelised but may favour particular levels of parallelism depending on the number of simulations. In relating price and performance, at minimum we may ascertain when it is appropriate to scale across private and public clouds, and potentially which direction is favoured.

21.2  Background

Commercial grid and utility computing was largely driven by big technology vendors such as IBM, Sun, HP, Oracle and Microsoft. Products and services such as IBM’s Computing On-Demand, Sun’s network.com, Oracle 10g and Microsoft’s High-Performance Computing (HPC) cluster solution were variously labelled as grid and utility, and variously priced and packaged. Sun’s network.com had a relatively clear pricing – US$1 per CPU hour. However, limited uptake meant that the service was eventually closed down. The US$1 price point was used in 2003 to equate computing resources [6]. An updated consideration of this price point suggests that substantially improved performance is now available, but the costs are most likely to vary according to the application when elements of the cost are treated separately: ‘most applications do not make equal use of computation, storage, and network bandwidth; some are CPU-bound, others network-bound, and so on [14]. Specific application requirements need to be reckoned with when determining how best to configure the cloud system. Prices for Amazon AWS are typically used to exemplify this: here, CPU, memory and storage often move together (Table 21.1), while network transfers and persistent storage necessitate further calculations.