A performance Brokerage for Heterogeneous Clouds

2.1 Definition and Characteristics of Cloud Services

The U.S. Department of Commerce’s National Institute of Standards and Technology (NIST) (Mell and Grance, 2011) defines Cloud Computing as follows:

‘Cloud computing is a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction.’
Whilst ISO/IEC 17788 (ISO/IEC 17788:2014) defines Cloud Computing as a
‘paradigm for enabling network access to scalable and elastic pool of sharable physical or virtual resources with on-demand self-provisioning and administration’
They both identify essentially the same set of characteristics for a Cloud system, with ISO 17788 listing them as:

1. 
   On-demand self-service [NIST]
   
2. 
   Broad network access [NIST]
   
3. 
   Multi-tenancy
   
4. 
   Resource pooling [NIST]
   
5. 
   Rapid elasticity and scalability [NIST]
   
6. 
   Measured service [NIST]
   

Interestingly, Caithness et al. (2017) note that earlier drafts of the NIST definition included an additional 8 characteristics: massive scale, homogeneity, virtualisation, low cost software, resilient computing, geographic distribution, service orientation and advanced security. These additional characteristics were referred to as ‘common characteristics’ to differentiate them from the 5 ‘essential ones’. However, as these were dropped from the original definition we only discuss the essential ones in further detail below.

On-demand self-service is perhaps one of the most novel aspects of Cloud systems. With a valid credit card, users can create an account for themselves, and once verified can provision resources for immediate use. Further, most Clouds provide an internet accessible API through which resources can be provisioned, allowing suitably written applications/infrastructures to auto-scale in response to changes in demand. This can be viewed as a step towards the development of so-called autonomic computing, which Ganek and Corbi (2003) define as self-managing infrastructures, and as envisaged in research projects such as the Ultra Large Scale Systems (ULSS) (Northrop et al., 2006) and the Large Scale Complex IT Systems (LSCITS) (Sommerville et al., 2012).
ISO/IEC 17788 makes multi-tenancy explicit as a characteristic of Cloud systems, whilst the NIST definition includes multi-tenancy as part of the description of resource pooling. Multi-tenancy is a model whereby physical resources are shared amongst multiple users concurrently. For example, a provider may partition a server into multiple concurrent instances, each of which can be rented to different users. A multi-tenancy model does raise a number of issues, primarily with regards to security and performance, as the provider needs to ensure isolation between instances. For the former, they must ensure that one instance cannot exploit another; for the latter, they must ensure that resource consuming actions of one instance do not impact resource availability for others – the so-called noisy neighbour problem (Lloyd et al., 2017).
Multi-tenancy is a key component of the Cloud economic model, and allows for higher rates of utilisation than typical organisations achieve with on-premise systems. We note, however, a difference as to how a provider may measure resource utilisation compared to how a user does. A user will measure utilisation of the resources they have rented in terms of quantity of application specific work done, or less usefully, CPU utilisation. The objective of a provider is to rent most resources most of the time at the highest tariff – typically on-demand. However, once rented, high utilisation by users incurs higher costs in terms of energy and general wear and tear, and so the less ‘use’ users make of the rented resources the better.
Rapid elasticity and scalability is the ability to acquire resources on-demand from a seemingly unlimited resource pool. Although neither NIST nor ISO 17788 explicitly states unlimited resources as a characteristic of Clouds, Armbrust et al. (2009) describe Clouds as having ‘...The illusion of infinite computing resources available on demand...’ and arguably it is implied by elasticity. In practice, Clouds are not infinite, only sufficiently large to support elasticity across some user base.
A measured, or metered, service means that Clouds employ a ‘pay-per-use’ billing model, with users being charged per unit of resource rented per unit of billable time. This encourages users to release resources back to providers when no longer required, meaning they are available again for rent on-demand to other users. This is important for providers as they can charge a higher price for on-demand access as opposed to longer term rents. Different providers employ different units of billable time for on-demand access. The most common units, and those found on EC2, involve rounding rental times up to the nearest whole hour. Azure and GCE employ finer grained per minute billing, the latter with a minimum billing unit of 10 minutes.
On-demand pricing on Clouds is typically ‘flat’, meaning (per provider) prices are constant for long periods. EC2 spot market employs dynamic instance pricing. Spot instances make use of spare capacity, that is, capacity that is not being used to support on-demand instances. Pricing varies according to availability and is typically, but not always, below the on-demand price. However, these instances can be terminated at any time with minimal warning so that the provider can reclaim resources in order to support higher value on-demand uses; indeed due to the pricing mechanism, spot instances may be re-claimed in order to support higher priced spot bids. Users can make opportunistic use of the spot market to complete work at a lower cost than they can in the on-demand market. As there is no guarantee that bids will be successful, or notice of when spot instances will be terminated, they should not be used to provide for non-interruptible workloads or for support services that require immediate provisioning unless the ability to adapt to significant and sudden price spikes is built in to such a mode of operation.
Google Compute Engine (GCE) also offers so-called pre-emptible instances types. These operate in a similar manner to EC2 spot instances as they can be re-claimed at any time. However, unlike EC2 they are limited to being run for a maximum of 24 hours after which they will be terminated. Further, pre-emptible prices are fixed, and so instances are only re-claimed to support higher priced on-demand use and not to service other requests for pre-emptible instances.
Notably, whilst rapid elasticity is a characteristic of Clouds, providers do not guarantee that on-demand capacity is always available. On EC2 a guarantee of capacity must be purchased in advance through reserved instances. Reserved instances are more akin to traditional hosting, purchased for either one year or three years, and made available in 3 different payment plans offering a mix of up-front payments and reduced per hour charges (as compared to on-demand). If a user is prepared to pay all up-front then they receive the largest discount, with ‘no up-front’ option offering the smallest discount. Note that per hour charges apply irrespective of whether the instance is running or not.
The name ‘reserved instances’ is somewhat of a misnomer, as it is a payment plan that automatically applies to any matching on-demand instance, and so over the course of a 1 year or a 3 year period, may have been realised using many different instances. For users with known long term requirements, a reserved instance can offer a substantial saving. However, should those requirements change then they may well have purchased capacity they no longer require. In order to reduce risk for users, AWS introduced the EC2 Reserved Instance Marketplace (ARIM), through which EC2 reserved instances can be sold.
In general, providers make no provision for either the sale or transfer of resources between accounts, and the inability to re-sell resources perhaps explains the lack of a wholesale market for Cloud resources which would allow for bulk purchasing at a discount for the purposes of resale. Providers do allow for access to resources by ‘end-users’, either directly or indirectly, who may charge for doing so. This makes possible the running of commercial services built atop Cloud resources, without requiring users of the service to also have an account with the provider(s) of the resources. In particular, whilst resources cannot typically be re-sold, they can be sub-let.
As elasticity is arguable the key characteristic of Clouds, we discuss it further in the next section.