ARCHITECTINGfor theCLOUD

leonidas tsementzisaka @goldstein

# get social

#awsuggr

leonidas tsementzisaka @goldstein

# who’s talking

* software architect, engineer[all major web/mobile platforms]

* devOps[enthusiast, not a real sysadmin]

* entrepreneur[n00b]

# format

* the problem

* development

* deployment

* failure

* limitations

* conclusion

* questions

# the problem

* increasing/decreasing resources on

the fly using auto scaling

* availability

* performance

* multi server painless deployment

:development:

# your stack matters

* the single most important aspect

* cloud-ready open source libraries

for major platforms

* saves you a lot of development time

* rapid changes

* can lock you in

# memory

* avoid application level variables/

sessions

* centralized storage:

✔ fast

✔ scalable

✔ efficient

AmazonDynamoDB

:storage:

# storage - single server

server

# storage - multi server

server 1

server farm

server 2 server 3 server 4

- scripts

- static files

# storage - multi server - S3

server 1

server farm

server 2 server 3 server 4

- scripts

- static files

# storage

application

/local/a

ddress/s

ite

\\unc\path\site

S3 API

STORAGE MIDDLEWARE

# storage

* local filesystem

* network storage

* Amazon S3

* Rackspace CloudFiles

* database (BLOB)

* GridFS (MongoDB)

* FTP, SFTP

* Azure

using a pluggable storage middleware, we can create storages

like...:

# storage

...and hopefully we don’t have to:

# storage

* avoid using HEAD/GET requests to

check for existing files

* store file list in memory instead

* use S3 “PRELOAD_METADATA”

...but if we have to:

:task queuing:

# task queuing

* image resizes

* external api calls

* low priority updates

* intensive calculations

* big data queues

* preparing hot caches

* indexing updates

* logging

use message/task queues for long running operations:

# task queuing

* organize tasks into different queues

* organize queues into priority workers

* scale workers using AWS auto scaling- send custom alerts using AWS CloudWatch API

* it’s all about priorities

AmazonSQS

:database:

# database

* Amazon RDS does the trickif you’re on MySQL or Oracle

* shard earlymark down table dependencies from the start, work around this while you grow

:deployment:

# huh?

* it’s your code

* you know the dependencies

* you know it’s breaking points

* it’s your job to deal with

deployment failures

* continuous deployment? yes please!

# requirements

* 50+ deployments per day from n devs

* secure

* fast rollbacks on failure

* zero downtime

* dependency handling (restart

services, migrate dbs etc.)

# continuous deployment

repodev

dev

dev

dev

git pull master

git push/pull

0.0.0.1

server farm

0.0.0.2 0.0.0.3 0.0.0.4

$: fab production deploy

# where the magic happens

pull from master ->

run test suite (abort on failure) ->

deploy/compress static files on S3 ->

install new dependencies ->

run db migration scripts ->

cleanup ->

rollback if something fails ->

clone previous production for backup ->

backup live db ->

pre-compile less etc ->

restart services if required

# continuous deployment

* master is always production safeuse pull request for large teams

* bootstrapped pre-configured AMIs

* handle stale servers with care

assumptions:

tools:

:failure:

# failure

“Design for failure and nothing will fail”

“Everything fails, all the time”

~ Amazon CTO

# failure

* backup/restore strategy

* bootstrapped AMIs

* multi-AZ deployment

:limitations:

# limitations

* disk I/O

✔ use multiple EBS in RAID config

* database

✔ sharding

✔ multiple read-only

✔ clustering

* ram

✔ memcache/redis replication

# recap

* the problem

* development

* deployment

* failure

* limitations

* conclusion

* questions

:one more thing:

:vendor lock-in:

if you’re still following, there’s no such thing on AWS

# vendor lock-in

* S3

✔ pluggable storages

* EC2

✔ normal unix box

* DynamoDB

✔ fully compatible NoSQL

* RDS

✔ fully compatible MySQL/Oracle

:conclusion:

# conclusion

* use best practices and you’ll be safe

* your stack matters

* Cloud != high availability

* Cloud != high performance

* Cloud != magic (but it’s close)

# questions? challenges?

?@goldsteinaka leonidas tsementzisleotsem [at] gmail.com

# thank you

@goldsteinaka leonidas tsementzisleotsem [at] gmail.com

!