Introduction to Cloud

ArchitectureChange the way you think about resources.

History of Abstraction

Once there was no operating system

Programmers had to handle all details

Resource management

Low level device programming

Job scheduling

…

Data centers have the same concerns

Programmers still handle the details

Decisions on how to allocate resources

Servers or virtual machines must be configured

Failures occur at scale and need mitigation strategies

Updates must be coordinated

Capacity planning is extremely difficult

…

Business logic development is only a small portion of the work

Paradigm Shift – The Cloud is an OS for

the Data Center

Resource sharing has always been around.

The same patterns you used on a computer to share resources can apply at a

larger level…

Essentially treat the Data Center as a computer and the cloud as the

operating system!

Gives you everything the OS does:

Shared usage of hardware

Readily available and fault tolerant storage

Illusion of endless resources

Managing parallel effort on a single body of work

Why do we use the cloud at all? Via the abstractions we achieve three big wins:

Cheaper

Greater uptime

Easier scale

To achieve good scale and uptime with out the cloud you would have:

Have multiple data center presences and use replicate DNS hosting

Have specialized networking hardware to load balance

With the cloud

Can easily assign computers to multiple data centers

Easily set up global load balancing across the data centers

Notice in both paradigms you must still separate your services to support

multiple simultaneous online instances (and the data must support this also…)

Parallel architecture is necessary

This has always been the key, just difficult for small companies to leverage!

Classes:

Web hosting

Need multiple copies

Stateless is the KEY (REST)

Logic

Need multiple copies

Separating out the work is the KEY

Data

Need multiple copies

This is really hard

Understanding “freshness” and locking data sets during is helpful

Data Segmentation/separation is the KEY

Uptime – Parallel hosting

WEST EASTCoLo A CoLo B

* Supporting this is still hard no matter where you

are…

* *

Old WayCloud Way

Internet/User

Scale – Data AND Logic Separation

Old Way

Cloud WayInternet/User

When your data

and logic are

together, to scale

“JUST” make it

bigger, right?Work is

done in

service

directly

against

DB

Data must be

separated enough

to avoid

contention during

scale out

Logic must be

separated in

smallest chunks

and brokered

through a

“queue”

…

…

…

Parallel Work Flow Example

Let’s take an example of a process that:

Uploads a file

Calculates a checksum

Takes out duplicate entries

Updates client’s total uploaded lines number

Simple right, create

a web service, write

the logic, save the

data, and done …

Save file to S3

Calculate the

checksum

Take out duplicates

and re-save to S3

Count the lines

Update client data

The more finite steps the more scale points you have. You also have more choices of how

scale them; more/bigger/both… Could need more memory for one step but not another,

don’t pay the extra cost on the other work!

Watch out for complexity (no silver bullet)

The relationships of distributed

systems can create complexity to

manage.

The simpler you can make the

relationships and the more you

can flow things in one direction

without touching previous steps

the easier life will be!

In general though if your problem

already has inherent complexity

the building blocks in the cloud

make it easier to wrangle…

References

AWS - Grep the Internet: https://aws.amazon.com/articles/1632

Author: Lawson Caudill – http://www.getthinktank.com