Cloud Computing Introduction

Dr Peadar Grant

Cloud Architecture

Recommended reading [Badger et al., 2012].

1 What’s it all about?

Cloud computing is essentially renting computing resources as needed to build-up systems in a quick self-service way. Think of it as booking a ryanair flight (vs buying your own plane), renting a car in a foreign country (vs buying one) or taking an AirBNB (vs buying a holiday home). Like travel planning, learning how to design, provision and utilise cloud computing resources is a learned skill developed through practice.

2 Backend

In this module we will primarily focus on backend processing, as opposed to frontend computing (desktops, mobile devices). As with any computing system, backend processing generally involves three key ingredients:

Compute power:
in the form of CPU cycles in server hardware, possibly shared by a hypervisor and managed by an operating system.
Storage:
in the form of magentic disks, SSDs, tape and other media that is directly attached to server hardware or connected over a network.
Connectivity:
so that the remote computing resource can be utilised by its intended consumers.

The earliest large computers (so-called mainframes like IBM System/360) led to smaller minicomputers (DEC PDP 8/11, VAX, IBM AS/400) and later on to PC-based servers running Linux / UNIX / Windows. Yet many of the ideas we’ll see in Cloud particular around pricing and pay-per-use actually were and are evident in Mainframes.

2.1 Batch processing

Historically a lot of backend processing was batch-oriented. This is still encountered in business processes (e.g. a bank processes payments overnight or utility sends a bill once a month).

2.2 Services

The alternative to batch processing is service-based processing, where a server allows one or more clients to connect and processes data in real time. Services commonly encountered include:

We will assume in this module that all services communicate over standard TCP/IP. For a given service, the client and server implement a common protocol that normally has an associated standard port number.

2.3 Building systems

It is important to remember in practice that a service may be a client of another service, and that most systems of even modest complexity involve multiple interdependent services:

3 Service requirements

Assuming we are dealing with backend server environments, our services are assumed to consist of software running on appropriate hardware. Server hardware requires power, connectivity and cooling in a secure and fireproof environment with appropriate channels to manage the hardware remotely. Normally we require resiliency in the infrastructural services and connectivity so that the service remains available. We can first distinguish among a number of common patterns for where our services are hosted:

On-site
within a suitably equipped data centre environment providing power, connectivity, cooling and security with the appropriate resiliency for the required service availability.
Co-located
where our hardware is located in a data centre facility that provides space, power, connectivity, cooling and security with the appropriate levels of resiliency.
Hosted
where a provider provisions equipment and software that we require.

All of these environments require significant upfront capital expenditure, must be right-sized from the beginning and scaling requires significant effort.

4 Expenditure

Setting up and running any service requires expenditure, which can be broken down into:

Capital expenditure (CAPEX):
money spent on goods/services necessary for future performance. Usually fixed / non-consumable assets. CAPEX is often made using borrowed money.
Operational expenditure (OPEX):
money spent on goods/services necessary for day-to-day running of the business. Often supplies/inputs into output. Needs to be self-financing if the service/business is to survive.

Note that whether a particular item is CAPEX or OPEX depends on the context. To a homeowner, a bale of concrete blocks for an extension represents CAPEX. To the shop supplying them, they are an OPEX to buy.

Key advantage of cloud computing is shifting CAPEX to OPEX.

5 Cloud definition and characteristics

The term “cloud” primarily appeared in its current context when AWS released their so-called Elastic Compute Cloud in 2006. Rather than an explicit definition, Badger et al. [2012] describes five essential characteristics for a particular service to be termed a “cloud service”:

On-demand self-service
allowing consumer to provision required services without human interaction.
Broad network access
allowing consumer to access provisioned services over standard network interfaces (e.g. TCP/IP over internet).
Resource pooling
where provider uses a large pool of resources to serve consumers on-demand, without the consumer having any affinity to a physical resource.
Rapid elasticity
to enable a consumer to vertically/horizontally scale their provisioned capacity.
Measured service
where a consumer pays for provisioned/used services at a relatively granular level, subject to resource limits.

If a service broadly meets these, then it can be termed a cloud service. They key differentiating factors are the self-service nature, the locatation independence, the seemingly unlimited pool of resources on the backend and the ability to control and pay for what you use on a short-term basis.

6 Main providers

The main cloud providers are shown in section 1.

Provider Service  
Amazon Amazon Web Services AWS
Microsoft Azure  
Google Google Compute Cloud
IBM IBM Cloud
Digital Ocean

Table 1: Main providers

7 Cloud service models

Within the cloud Badger et al. [2012] describes three different service models:

Infrastructure as a Service (Iaas):
provider makes available compute power in the form of virtual machines, storage in multiple forms and allows networks to be constructed to link these resources together. Obviously you don’t have access to the hardware.
Platform as a Service (PaaS):
components such as database servers, integration components (queues, notification systems), object storage that can be provisioned directly from the web / CLI.
Software as a Service (SaaS):
provider makes software available for use over standard network protocols (HTTP/RDP/SSH) either by humans or an API (e.g. Github).

In reality, the lines between IaaS, PaaS and SaaS are often blurred. They are probably better thought of as a continuum from SaaS through PaaS to IaaS. It can be difficult to place many cloud services exclusively into one of these three categories, nor is it necessary to. Many solutions built including cloud technologies will include all three.

PIC

Figure 1: Cloud service models

8 Interface

Most cloud providers support a number of channels for provisioning resources and interacting with them:

Web console
providing manual point-and-click interaction
Command-line interface (CLI)
command can be installed on your own computer and can be run from PowerShell / Bash
Software Development Kit (SDK):
for applications running on cloud and elsewhere (local desktop, mobile) that need to interact with cloud resources.

9 Costs

Metered costs for cloud usage depend on the particular service under discussion. Broadly, these will break down into:

Charge type Common units

Remarks

Setup/teardown Per resource unit

Time-based Days / hours / mins / seconds

Often for IaaS components

Usage-based Requests / invocations

Often for PaaS components

Data Storage MB / GB / TB etc

Data at rest

Data Transfer MB / GB / TB etc

Inbound, outbound, internal may differ

Table 2: Cost types

10 Geographic infrastructure groups

The major “full service” cloud providers separate their infrastructure geographically. This is done for two reasons. Firstly it lets cloud providers separate services in different geographical regions from each other for legal and business reasons. Secondly it facilitates redundancy in case of failures.

Regions
are designed to separate data and resources for business and legal reasons.
Non-geographic regions
are purpose-specific rather than geographical, like AWS GovCloud.
Geography
is a region-grouping that Azure use. AWS doesn’t have a multi-region grouping concept.
Availability zones
are a technical construct to tolerate failures in physical infrastructure.
Edge locations
are an entirely parallel structure provididing access points and edge caching for users of customer applications. These are normally a separate set of locations to the provider’s regions/AZs for customer use.

The providers all do a better job on constantly updating their global infrastructure maps than any lecture notes will:

11 Service agreement

Cloud Providers will offer their services as part of a service agreement, which specifies a number of promises, limitations and obligations, section 2:

Promises
are guarantees by the cloud provider of things it will do for the customer.
Limitations
limit the scope of the promises that a cloud provider makes to a customer.
Obligations
specify rules that a customer must comply with when using the cloud service.

PIC

Figure 2: Key aspects of cloud terms-of-service

12 Tips

References

   Mark Lee Badger, Timothy Grance, Robert Patt-Corner, and Jeffery M Voas. Cloud computing synopsis and recommendations. Technical report, Gaithersburg, MD, United States, 2012.