Can reap economies of scale.

Because of scale can afford specialized skills.

Web developers can concentrate on their core competencies that give them market advantage.

Shorter lead times.

Lower capital requirements.

Multi-tenanted.

Computing power becomes a commodity as did electric power in early 20th century.

Shared pool of compute resources.

compute, storage and network

cheap commodity hardware

i.e. readily available cheap identical servers/routers etc.

easily replaced when faults occur

may be optimised for cloud and purchased in bulk by cloud vendor

Multi-tenancy: shared subsets allocated to customers as needed and subsequently returned.

Workload Patterns suitable for Cloud Computing

On & off workloads (e.g. batch job)

e.g. scientists running modeling software for new drug

installed capacity is wasted when not being used, but:

users idle while waiting for jobs to finish…

Growing fast

successful services need to grow and scale e.g. new Internet game that catches on

deployment and scaling lags stunts market growth at key critical moment

need capital for software development or marketing instead of building data centre

Predictable bursting

many services have seasonal trends, either macro (festivals) or micro (sports events) or peak hours

peak load can exceed average load by factor 2x-10x

but: few users deliberately provision for less than the peak

result: server utilization in existing data centers ~5%-20%!!

dilemma: waste resources or lose customers!

Unpredictable bursting

Unexpected/unplanned peak in demand e.g. important breaking news events

can’t afford to provision for extreme case, but failure to handle it well can destroy business

important that service level agreement for such business areas e.g. the press, are previously agreed

When Cloud may not be useful

Control over Server

CPU, memory, other specs

Latency Concerns

Slower

Legislative Issues

Access to data

Geopolitical Concerns

Cloud out of UK

Main Principles of Cloud Computing

Pooled Resources

Virtualisation

Elasticity

Automation

Metered Billing

Pooled Resources

commodity computing

pay as you go

available to anyone

exploits economics of volume

massive replication of identical hardware units

multi-tenanted

potential security/legal issues

shift from capital expenditure to operational expenditure

lowered barrier for project starts

Virtualisation

facilitates consolidation i.e. the need to get maximum utilisation of physical cloud servers by hosting multiple virtualised servers on each

to efficiently use space/power/cooling...

the large pool of virtualised servers is the primary unit to be allocated to consumers as needed

applications must be able to exploit this

sandboxing aids multi-tenanting

each virtual server becomes a (system) virtual machine

technical details in future lecture

Elasticity

dynamic scaling i.e. change how much of a resource is consumed in response to how much is needed

normally need a base set of resources but much more under peak conditions

scale out rather than scale up

we add more identical virtual servers

we do not add more hardware to underpin a single virtualised server

Automation

infrastructure is required to:

for the user and system admin to create and delete virtual servers both manually automatically

and to pick how many resources they have, where they are located etc.

automatically monitor performance metrics (CPU loads, queue lengths...) and scale accordingly

or scale at set times e.g. a peak time of the day

Metered Billing

typically have startup and annual contract fees

beyond that pay as you go

based on CPU, no. virtual server instances, storage used, I/O...

entry barriers much lower than for traditional projects

easier for entrepreneurs as no capital investment

cost associativity: 1,000 computers for 1 hour same price as 1 computer for 1,000 hours

access to huge computing resource

universities, R&D companies

access to Big Data and its processing

Hadoop/Map-reduce

IBM’s Watson

Service Level Agreements (SLAs)

For commercial success, cloud data-centres need to provide customers with strict Quality of Service (QoS) guarantees

documented as Service Level Agreements

only then can customers be confident in outsourcing their jobs to a cloud infrastructure

may differ in application type and workload e.g.

transactional applications require response time and throughput guarantees

non-interactive batch job concerns performance (i.e. completion times)

web applications tend to be highly unpredictable and bursty in nature

may be complex to supply an infrastructure that can satisfy these competing goals whilst at the same time using the data-centre hardware efficiently

basic discussion of cloud SLAs at:
🔗 Service Level Agreements in the Cloud: Who cares?

Data in the Cloud

Relational Data

there’s lots of it and people want their existing database in the cloud...

basically the relations between tables limit its scalability

however there are some ways round this and relational data will need to be accommodated for the foreseeable future...

Non-Relational Data

scalable

NoSQL

blobs, block storage, key-value stores, queues...

available as native cloud vendor features e.g. Azure Storage or Amazon DynamoDB or Amazon S3 or by installing MongoDB etc.

More about this in a later lecture.

Distributed Systems

Notice that the cloud is implicitly a distributed system.

what we have are a set of multiple virtual servers

these are going to have to communicate to get the work done

and/or access shared data in a safe manner

developing distributed applications is hard

however many of the problems are well understood and their solutions can be leveraged in the cloud

However a cloud deployment probably has many more (virtualised) servers than a traditional distributed system.

many more points of failure

faults are likely and have to be managed, include:

disk failures

network partitioning

bugs

human factors....

on a large scale, faults will be commonplace

Elasticity and Automation in AWS

Monitor the performance => autoscale as appropriate.

Note the load balancing – what are the issues with this?

Distributed Systems

Web applications are generally (but not always) multi-tier.

... and thus distributed applications...

but the tiers and technologies are generally familiar and not new...

web, business logic, relational and non-relational data, message passing...

much of what came before still used but may be tweaked: software design and development, patterns, SOA, web services, OSs, TCP/IP, distributed computing, databases....

A key issue is data-consistency

i.e. how to keep data across servers consistent

imagine sending money between servers– what happens if one side fails but the other works ok?

in traditional systems we use transaction processing

this can still work within single data-centres well to a limited degree

but it will not scale

also if the data is geo-distributed then transactions don’t work either

to describe this we need the CAP theorem

weaker consistency is needed in the cloud (see later)

Topology of Cloud Computing

A good example is AWS which is 3 tier:-

11 high level regions, close to users and in different legal jurisdictions – so both geographically and in network terms distant around world

regions split into availability zones (AZs) – logical subdivision

AZs contain data-centres (>=2 data-centres)

very fast private connections – data-centres in AZ close in network terms but a few km apart in case of a big disaster (e.g. aeroplane strike)

bespoke hardware design of servers and networking purchased at massive scale

46000 servers in a data-centre

above may already be out of date (from 2014)...

Note that the issues for writing distributed applications are different if they are close or distant – with the distant one they are very hard (again transactions vs. BASE...)

Cloud applications are often characterised by having front facing web service APIs.

These might be provided as part of the infrastructure e.g. blob storage through REST.

REST: REpresentational State Transfer

Resource Oriented Architecture

use all of HTTP interface methods as originally intended

lightweight

SOAP:-

SOA/RPC type paradigm using HTTP POST

lots of proven security technologies available

older, heavyweight, now less popular but an important paradigm to know about

Both these technologies are built on HTTP and so ultimately on TCP/IP.

Service-Oriented Architecture (SOA)

A service-oriented architecture is essentially a collection of services. These services communicate with each other. The communication can involve either simple data passing or it could involve two or more services coordinating some activity.

a higher level than classes – here we are talking about the whole self –contained service (application) which is a black box, can be used by consumers from a different ownership domain, is loosely coupled from the user and can be discovered at run-time.

SOA is a principle adopted in modern enterprise distributed system design and is also applicable to cloud computing.

we will also discuss microservices

Data Representation

Web services communicate using structured data represented as text.

everything understands text...

HTTP can carry basically anything as a payload but Web services use:-

XML

JSON

XML has many other uses including machine readable specification of web services and cloud deployments.

Security in Cloud Computing

Top Threats to Cloud Computing (CSA 2016)

Threat #1: Data Breaches

Threat #2: Weak Identity, Credential and Access Management

Threat #3: Insecure APIs

Threat #4: System and Application Vulnerabilities

Threat #5: Account Hijacking

Threat #6: Malicious Insiders

…

Security in Web Services

Message and Transport Security

Technology

encryption

digital signatures

certification

TLS/SSL & HTTPS

OAuth 2.0 for RESTful Web Services

Identity with OpenID Connect

OAuth and OpenID in the cloud

Security in SOAP with WS-Security

📷 Gartner 2016 - Cloud IaaS Players