3. Pleased to meet you Technical background Loves presenting Loves traveling Loves people Simone, Italian, AWS technology Evangelist Twitter: @simon (tag is #next09 ) Linkedin Facebook Dopplr Friendfeed Amazon Flickr SmugMug
4. Next09, May 6th, 2:00pm 01 - Audimax: "When Money Talks", Jeff Jarvis, Humair Haque 02 - K2: "Social Media", Gary Hoff 04 - K4: "Startup presentations", Victor Henning, Daniel Shaffeld What is happening right now? 03 - P1: "From zero to Cloud in 30 minutes", Simone Brunozzi
9. The one slide sales pitch And yes: I hate bullet points :) Amazon S3: durable storage on internet Amazon CloudFront: Content Delivery Service Amazon EC2: virtual servers on demand EBS for EC2: persistent storage Public Data Sets: Human Genome, Census, Science, etc Amazon SQS: messaging system Elastic MapReduce: instant Hadoop cluster http://aws.amazon.com
10. La Pedrera - Casa Milà, Barcelona - Antonio Gaudi Architecting in the Cloud
11. Architecting in the Cloud 1. Design for failure 2. Loose coupling sets you free 3. Design for dynamism 4. Security is everywhere 5. Don't fear constraints 6. Many storage options 7. AWS ecosystem and community I share lessons learned at Amazon.com
12. 1. Design for Failure "Everything fails, all the time" Werner Vogels , CTO Amazon.com and nothing will really fail Avoid single points of failure Assume everything fails, and design backwards
13. Design for Failure with AWS Tools to make your life easier Elastic IP Availability Zones (AZ) Elastic Block Store (EBS) Real time monitoring Heartbeat, Linux-HA, NFS, RAS: Reliability Availability Serviceability, Beowulf ZFS, BTRFS, cluster file system, AndrewFS, CODA, Cluster Resource Manager
14. 2. Loosely Coupled Systems "Low, Loose, Weak" beats "High, Tight, Strong" Loosely Coupled in time (message oriented middleware) Loosely Coupled in format (data transformation) In Web Services: implementation is hidden from the caller Everything is a Black Box De-coupling for Hybrid models Load-balancing clusters Better scaling SQS prevents failures
15. 3. Design for Dynamism No assumption on health, location Bootstrap, dynamic configuration Management components to scale Architect for change Panta Rei (everything flows, by Heraclitus Simplicius) Scaling-out and scaling-in will change servers you talk to
16. 4. Security is everywhere Physical is free Network is easy The rest can be added Use it Security groups (EC2 cluster) and IP ranges Group-based rules to control access between App layers Encrypt S3, data transfer, file systems (efs)
17. 5. Don't fear constraints More RAM? Shared distributed cache Architectural constraints? Don't embrace, break them Better DB performances? Multiple read-only / sharding / DB clustering Your server is better? EC2 on demand. Static IP? Boot script for software reconfiguration from SimpleDB
18. Example: memcached Distributed Memory Cache System ( mem-cache-dee ) No auth/security; DB speedups with read reduction f get_x (int id) { result = db_sel("SELECT * FROM users WHERE id = ?", id); return result; } function get_x (int id) { result = memcached_fetch("userrow:" + id); if (!result) { result = db_sel("SELECT * FROM users WHERE id = ?", id); memcached_add("userrow:" + id, result); } return result; }
19. 6. Many Storage options Amazon S3: large static objects Cloudfront: distribution SimpleDB: simple data indexing/quering Amazon EC2: local disc drive Amazon EBS: persistent storage Lessons from Amazon.com
20. 7. AWS community and Ecosystem AWS Ecosystem AWS Community Find help, guidance, assistance when you need it
26. Architecting in the Cloud Did you like it? 1. Design for failure 2. Loose coupling sets you free 3. Design for dynamism 4. Security is everywhere 5. Don't fear constraints 6. Many storage options 7. AWS ecosystem and community