Architecting for the cloud
-
Upload
leonidas-tsementzis -
Category
Technology
-
view
807 -
download
0
Transcript of Architecting for the cloud
![Page 1: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/1.jpg)
ARCHITECTINGfor theCLOUD
leonidas tsementzisaka @goldstein
![Page 2: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/2.jpg)
# get social
#awsuggr
![Page 3: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/3.jpg)
leonidas tsementzisaka @goldstein
# who’s talking
* software architect, engineer[all major web/mobile platforms]
* devOps[enthusiast, not a real sysadmin]
* entrepreneur[n00b]
![Page 4: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/4.jpg)
# format
* the problem
* development
* deployment
* failure
* limitations
* conclusion
* questions
![Page 5: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/5.jpg)
# the problem
* increasing/decreasing resources on
the fly using auto scaling
* availability
* performance
* multi server painless deployment
![Page 6: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/6.jpg)
:development:
![Page 7: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/7.jpg)
# 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
![Page 8: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/8.jpg)
# memory
* avoid application level variables/
sessions
* centralized storage:
✔ fast
✔ scalable
✔ efficient
AmazonDynamoDB
![Page 9: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/9.jpg)
:storage:
![Page 10: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/10.jpg)
# storage - single server
server
![Page 11: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/11.jpg)
# storage - multi server
server 1
server farm
server 2 server 3 server 4
- scripts
- static files
![Page 12: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/12.jpg)
# storage - multi server - S3
server 1
server farm
server 2 server 3 server 4
- scripts
- static files
![Page 13: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/13.jpg)
# storage
application
/local/a
ddress/s
ite
\\unc\path\site
S3 API
STORAGE MIDDLEWARE
![Page 14: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/14.jpg)
# 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...:
![Page 15: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/15.jpg)
# storage
...and hopefully we don’t have to:
![Page 16: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/16.jpg)
# 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:
![Page 17: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/17.jpg)
:task queuing:
![Page 18: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/18.jpg)
# 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:
![Page 19: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/19.jpg)
# 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
![Page 20: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/20.jpg)
:database:
![Page 21: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/21.jpg)
# 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
![Page 22: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/22.jpg)
:deployment:
![Page 23: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/23.jpg)
# 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!
![Page 24: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/24.jpg)
# requirements
* 50+ deployments per day from n devs
* secure
* fast rollbacks on failure
* zero downtime
* dependency handling (restart
services, migrate dbs etc.)
![Page 25: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/25.jpg)
# 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
![Page 26: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/26.jpg)
# where the magic happens
![Page 27: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/27.jpg)
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
![Page 28: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/28.jpg)
# continuous deployment
* master is always production safeuse pull request for large teams
* bootstrapped pre-configured AMIs
* handle stale servers with care
assumptions:
tools:
![Page 29: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/29.jpg)
:failure:
![Page 30: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/30.jpg)
# failure
“Design for failure and nothing will fail”
“Everything fails, all the time”
~ Amazon CTO
![Page 31: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/31.jpg)
# failure
* backup/restore strategy
* bootstrapped AMIs
* multi-AZ deployment
![Page 32: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/32.jpg)
:limitations:
![Page 33: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/33.jpg)
# limitations
* disk I/O
✔ use multiple EBS in RAID config
* database
✔ sharding
✔ multiple read-only
✔ clustering
* ram
✔ memcache/redis replication
![Page 34: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/34.jpg)
# recap
* the problem
* development
* deployment
* failure
* limitations
* conclusion
* questions
![Page 35: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/35.jpg)
:one more thing:
![Page 36: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/36.jpg)
:vendor lock-in:
if you’re still following, there’s no such thing on AWS
![Page 37: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/37.jpg)
# vendor lock-in
* S3
✔ pluggable storages
* EC2
✔ normal unix box
* DynamoDB
✔ fully compatible NoSQL
* RDS
✔ fully compatible MySQL/Oracle
![Page 38: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/38.jpg)
:conclusion:
![Page 39: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/39.jpg)
# conclusion
* use best practices and you’ll be safe
* your stack matters
* Cloud != high availability
* Cloud != high performance
* Cloud != magic (but it’s close)
![Page 40: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/40.jpg)
# questions? challenges?
?@goldsteinaka leonidas tsementzisleotsem [at] gmail.com
![Page 41: Architecting for the cloud](https://reader034.fdocuments.in/reader034/viewer/2022042715/559deb931a28ab44148b46d2/html5/thumbnails/41.jpg)
# thank you
@goldsteinaka leonidas tsementzisleotsem [at] gmail.com
!