2. 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
3. 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
4. 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…)
5. 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
6. Uptime – Parallel hosting
WEST EAST
CoLo A CoLo B
* Supporting this is still hard no matter where you
are…
* *
Old Way
Cloud Way
Internet/User
7. 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”
…
…
…
8. 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!
9. 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…
