A performance Brokerage for Heterogeneous Clouds

2.4 Deployment Models

A Cloud’s deployment model refers to whether or not it is made publically available to anyone with an Internet connection and credit card, is solely for private use for one organisation, is intended to solve a specific problem for a single community or is a hybrid of these models. Below we provide the NIST definitions of the 4 deployment models.

Public Cloud: “The cloud infrastructure is provisioned for open use by the general public. It may be owned, managed, and operated by a business, academic, or government organization, or some combination of them. It exists on the premises of the cloud provider”.
Private Cloud: “The cloud infrastructure is provisioned for exclusive use by a single organization comprising multiple consumers (e.g., business units). It may be owned, managed, and operated by the organization, a third party, or some combination of them, and it may exist on or off premises”.
Community Cloud: “The cloud infrastructure is provisioned for exclusive use for a specific community of consumers from organisations that have shared concerns (e.g. mission, security requirements, policy, and compliance considerations). It may be owned, managed and operated by one or more of the organisations in the community, a third party, or some combination of them, and it may exist on or off premises”.
Hybrid Cloud: “The cloud infrastructure is a composition of two or more distinct cloud infrastructures (private, community or public) that remain unique entities, but are bound together by standardized or proprietary technology that enables data and application portability (e.g., cloud bursting for load balancing between clouds)”.
The idea of bespoke on-premise private Cloud is perhaps somewhat at odds with the concept of Clouds. In particular, unless the quantity of on-premise resource is greater than expected peak demand, they cannot support elasticity. For organisations with spikes in demand the cost of provisioning may well be high. In this case Hybrid Cloud becomes a useful strategy as it allows organisations to ‘extend’ their infrastructure on-demand, but requires workloads that can seamlessly run on all platforms being used.
The hybrid Cloud has a number of proponents, with one of the most notable being Rackspace, who argued that users should ‘own the base and rent the spike’. By this they mean that predictable constant demand should be met by an on-premise system (of some kind), whilst spikes in demand should be met by resources rented on-demand from the Public Cloud. This argument is mainly predicated upon the costs of long term on-demand deployments. However, deployments of this kind may benefit from the cost savings offered by reserved instances on EC2 for example.
As Cloud use becomes more prevalent, users may determine that different Clouds are better suited for particular types of workloads. Indeed, a workload designed as a set of micro-services can be deployed on different types of service Clouds, which may be public or private. Multi-Cloud refers to the use of multiple Clouds whereby each Cloud runs specific components of a workload/mirco-service. This differs from the typical hybrid model where the Public Cloud is envisaged as an extension of the private Cloud and workloads which can horizontally scale are stretched across both.
As noted, Public Clouds are available to anybody with a credit card and Internet connection. In order to reduce the latency of requests, providers typically operate globally distributed infrastructures, which we consider in detail in the next section.

2.5 Regions and Availability Zones

In order to support elastic scalable systems, Cloud providers deploy massive globally distributed physical infrastructures. However, resources are not widely distributed within a particular geographical location. Providers typically structure their Clouds into Regions, which correspond to distinct geographical areas; EC2, for example, has 15 Regions in locations such as: North Virginia (us-east-1), Dublin (eu-west-1), and Sydney (ap-southeast-2) as of 2016 with 3 more coming online soon. Users can place resources into Regions that are most suited to their needs, for example, resources can be placed in Regions that are nearest to their customers or to satisfy regulatory requirements. Resources are typically only visible and available within the Region they have been placed; however, users can use the same credentials to access all Regions. In many regards, a Cloud resembles a federated system of sub-clouds.

Prices typically differ across Regions, reflecting differences in operational costs between different geographical locations. For those users for whom geographical placement is not a consideration, this may offer an opportunity to obtain better prices – although they will expose themselves to foreign exchange costs and currency risks.
To provide a degree of redundancy, both AWS and GCE structure Regions into at least 2 Availability Zones (AZs). AZs within a Region are physically distinct and isolated from each other, and further, each has its own power and network connections, and so the failure of one AZ should not, in theory, affect the operation of others in the same Region. However, failure cascade amongst multiple AZ has occurred on more than one occasion. Users running more than one instance, or with requirements on availability, are encouraged to make use of AZs by ensuring their deployment spans multiple AZs.
Both AWS and GCE follow the same convention for identifying AZs: region code followed by a letter identifier, for example, in the AWS Region us-east-1 we find the following AZs: us-east-1a, us-east-1b, us-east-1c, us-east-1d, and us-east-1e. In AWS however, the same AZ identifier, such as us-east-1a, may map to different locations for different accounts. Indeed, they state ‘…your Availability Zone us-east-1a might not be the same location as us-east-1a for another account’. Further, not all accounts have access to the same number of locations within a Region. Looking ahead to section 5.5 we will find different locations have different levels of performance on EC2. As such there is potential for performance to vary by account, depending upon the locations users have access to.
EC2 currently consists of 42 AZs, and each AZ contains one or more data centres, with each data centre estimated to contain between 50,000 to 80,000 physical servers (Morgan, 2014). This gives a lower estimate at the time of writing on the total number of physical servers at 2.1 million. These servers are combined with software tools, such as hypervisors⁵, to allow instances and other virtual resources to be created and destroyed on-demand. A hypervisor can partition a physical server into one or more instances, and so this estimate also serves as a lower estimate for number of concurrent running instances EC2 can support.
By the size of an instance we mean the number of vCPUs, and the amount of RAM and local storage if any. However, whilst providers could allow for user-specified sizing, we find instead that instances are made available in standard sizes, known as instance types, which we discuss next.