A performance Brokerage for Heterogeneous Clouds

2.7 Utility and Commodity

The business model of Cloud Computing is one of mass production of non-negotiable standardised resources, which are available on-demand on a pay-per-use basis. As such, Cloud services have often drawn comparisons with notions of utility and commodity. Foster et al. (2008) describes utility compute models as ‘…packaging compute and storage into metered services…’, and Armbrust et al. (2009) suggests that ‘…Cloud Computing is the long held dream of computing as utility…’. Notions of utility computing have a long history, with a famous quote from John McCarthy⁶ stating: ‘If computers of the kind I have advocated become the computers of the future, then computing may someday be organized as a public utility just as the telephone system’. Indeed, Varghese and Buyya (2017) go so far as to suggest that the utility vision has already been achieved, however, unpredictable and variable performance across supposedly identical instances suggest there is still some way to go.

Arguably, it is the same economic forces that produced, for example, electricity utilities that is producing compute like utilities, namely, commoditisation. A commodity is a good or service which is fungible, that is, has the property of being interchangeable with other goods or services of the same type. Commoditisation is the process by which goods or services may start as unique, but as competitors offer increasingly similar products, consumers begin to consider various offerings as equivalent and differentiate between them on the basis of price alone. The electricity produced by different suppliers is indistinguishable, and as such is considered a commodity. It has been argued that commoditisation is an inevitable process, a view summed up by the famous quote ‘…in the end everything is a toaster’⁷.
Commodity goods are not necessarily identical, but instead are sufficiently uniform so as to be considered equivalent. Indeed, there are few goods which are naturally indistinguishable, for example, gold will contain different levels of impurities. That such variation naturally exists led to the carat rating system for gold and gold rated at the same level being considered equivalent even though differences in impurities may still exist to within the margins of the ratings (World Gold Council, 2017). Interestingly, Berghel (2014) suggests that as Clouds become commodities their value and utility may diminish. Arguably, such a view arises from a conflation of commodity with low-value, and so hard to profit from, and abundance. However, the oil industry has certainly proved profitable and gold is considered a rare metal.
The current Cloud marketplace certainly appears to be in the process of commoditisation. Providers offer resources in standardised forms, and whilst the definition of a standard resource is provider specific, they are increasingly similar to each other. For many type of ‘basic’ instances they are increasingly competing on prices and less so on differentiated service features. Further, we also see providers exiting from the marketplace (Rackspace, HP and Verizon) due to price competition.
Commodities are frequently traded on organised marketplaces known as exchanges. An exchange will define the minimum acceptable standard of goods for each class of commodity traded, known as the grading basis. Coffee, for example, is traded on major world exchanges in 2 types, Arabica and Robusta. In addition to the type of coffee bean, the quality is also specified in terms of defects and water moisture. Similarly, crude oil is traded as many different commodity classes, depending upon its physical characteristics, such as Brent Crude Oil and West Texas Intermediate (WTI) Crude Oil.

If we consider again how providers define instance types, by specifying some number of vCPUs, a quantity of RAM, an amount of local storage and a per vCPU compute rating, then it becomes clear why the notions of commodity naturally arise when discussing Clouds. Each instance type may be considered akin to a commodity class as instances of the same type are interchangeable. Further, whilst instances of the same type may run on hosts with different CPUs, so long as they meet the specified criteria, as defined by an ECU or GCEU for example, they are considered equivalent. This does of course leave room for a degree of variation between equivalent instances, particularly so if the criteria is defined in terms of a minimum.

Weinman (2015), Cartlidge (2014), Garg et al. (2013), and Buyya et al. (2009) suggest that Cloud resources can be considered as commodities and may be traded on exchanges modelled along similar lines to extant financial exchanges. Indeed, it is a small step from various provider specific standards to a standard mandated by an exchange. Such exchanges bring a number of advantages, including continuous price discovery, price stability, liquidity, and reduction in default credit risk and so it is natural to investigate whether or not such advantages can be brought to the compute resource marketplace.
The notion of utility and commodity is not new or specific to Cloud systems. So-called Grid Computing (Foster et al., 2008) was developed in the late 1990s, primarily designed to solve large scale problems arising from the scientific domain, and taking inspiration from utility grids for their architecture. The objective of Grids is to harness the compute power distributed amongst silos of IT, whilst making the system appear unified. Grids are designed to be geographically dispersed with heterogeneous nodes, and middleware, such as the widely used Globus toolkit (Globus, n.d.), used to tie together the nodes in the Grid so as to appear as a single system to users. Access to resources is provided through the use of a queuing system, to which users submit jobs specifying workloads to be run. Queues, however, exist at a location and so access to them requires schemes that can provide for access to their locations.

Grids were initially viewed as potentially being able to deliver a commodity market for compute resources, whereby different providers can sell compute resources on the Grid. Proposals for Grid exchanges and Grid brokers have been made (Aloisio et al., 2002; Buyya et al., 2002; Abramson et al., 2002) and typically the role of the broker is to mediate between the user and a provider who can satisfy bespoke requirements bound together by an SLA. However, the proposed Grid exchanges do not resemble financial commodity exchanges⁸ which operate on a basis of standardized non-negotiable offerings, and where buyers and sellers post buy at and sell at (for particular quantities) onto an order book visible by all participants. So, whilst we have a compute marketplace arguably it is not a commodity one. Further, whilst we can find some examples of successful Grid implementations in academia, such as the particle physics Grid GridPP (GridPP, 2017), it became apparent that Grids suffered from a number of issues which made them unsuitable as general purpose platforms. Indeed, there are no successful publically available commercial Grids, let alone a Grid marketplace.

Cloud services rectify many of the problems associated with Grids: As Grids employ queues they cannot guarantee on-demand access to resources, or indeed even a maximum wait time for resource to be made available. They are therefore not suitable for use cases where resources need to be acquired rapidly in response to changes in demand. Quantities of resources also need to be specified in advance and it is not possible to scale resources for a running job. Further, they are not suitable for running services on as network ports cannot typically be exposed. Indeed, Grids provide a binary execution platform only, with no access provided to lower level resources as would be required for tuning and optimising code or enhanced security. Clouds are accessible to anyone with a valid credit card and access to the Internet, removing the need for access to specific locations in order to submit jobs to queues. Further, they are suitable for a wide variety of workload, from batch processing to the running of services. Finally, resources can be provisioned on-demand, removing queue wait times, and allowing for a job to be scaled in and out as required.
The notions of utility and commodity raise a number of questions that need to be addressed. In particular, with a metered billing model both parties must agree on how to measure usage. In the electricity market usage is measured in terms of the kilowatt-hour (kWh): what should the equivalent unit be for a compute utility? In a commodity market for Cloud resources, on what basis should users consider resources such as virtual machines from one provider as being interchangeable with those from another? Arguably, performance is key to addressing both questions; a metered service can bill on the basis of the amount of useful work that Cloud resources can deliver (or have delivered), whilst instances may be considered interchangeable if they can deliver the same amount of work per unit of time.
The performance properties of instances derive from the performance properties of the servers and other physical resources of the data centre, as well as any software tools used to create and support them. In particular, the performance of CPU bound and memory bandwidth bound workloads is primarily determined by the underlying physical server an instance is running on. Whilst, for I/O bound workloads performance will depend, at a minimum, upon where the storage is physically located.