Carlos CondeARCHITECTING FOR HIGHAVAILABILITY
AWS BUILDING BLOCKSInherently Fault-TolerantServicesFault-Tolerantwith the rightarchitecture Amazon S3 Amazon SimpleDB ...
#1DESIGN FORFAILURE●○○○
« Everything failsall the time »Werner VogelsCTO of Amazon
YOUR GOAL:Applications should continue to function evenif the underlying physical hardware fails or isremoved or replaced
AVOID SINGLE POINTS OFFAILURE.ASSUME EVERYTHING FAILS,AND DESIGN BACKWARDS.
AVOID SINGLE POINTS OFFAILURE.ASSUME EVERYTHING FAILS,AND DESIGN BACKWARDS.
HEALTH CHECKS
#2USE MULTIPLEAVAILABILITY ZONES
US-WEST (Oregon))EU-WEST (Ireland)ASIA PAC (Tokyo)ASIA PAC(Singapore)US-WEST (N. California)SOUTH AMERICA (Sao Paulo)US-EA...
AMAZON RDSMULTI-AZ
#3BUILD FOR SCALE
HEALTH CHECKS+AUTO SCALING
HEALTH CHECKS+AUTO SCALING=SELF-HEALING
#4LOOSE COUPLING
PUBLISH& NOTIFYRECEIVE TRANSCODE
PUBLISH& NOTIFYRECEIVE TRANSCODE
VISIBILITYTIMEOUT
BUFFERING
CLOUDWATCH METRICSFOR AMAZON SQS+AUTO SCALING
BUILD LOOSELYCOUPLED SYSTEMSThe looser they are coupled,the bigger they scale,the more fault tolerant they get…
1. DESIGN FOR FAILURE2. USE MULTI-AZ3. BUILD FOR SCALE4. DECOUPLE COMPONENTS
THANK YOU!
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
AWS Summit Berlin 2013 - Architecting for high availability
Upcoming SlideShare
Loading in …5
×

AWS Summit Berlin 2013 - Architecting for high availability

1,698 views

Published on

AWS provides a platform that is ideally suited for building highly available systems, enabling you to build reliable, affordable, fault-tolerant systems that operate with a minimal amount of human interaction. This session covers many of the high-availability and fault-tolerance concepts and features of the various services that you can use to build highly reliable and highly available applications in the AWS Cloud: architectures involving multiple Availability Zones, including EC2 best practices and RDS Multi-AZ deployments; loosely coupled and self-healing systems involving SQS and Auto Scaling; networking best practices for high availability, including Elastic IP addresses, load balancing, and DNS; leveraging services that inherently are built with high-availability and fault tolerance in mind, including S3, Elastic Beanstalk and more.

Published in: Technology, Travel
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,698
On SlideShare
0
From Embeds
0
Number of Embeds
427
Actions
Shares
0
Downloads
59
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

AWS Summit Berlin 2013 - Architecting for high availability

  1. 1. Carlos CondeARCHITECTING FOR HIGHAVAILABILITY
  2. 2. AWS BUILDING BLOCKSInherently Fault-TolerantServicesFault-Tolerantwith the rightarchitecture Amazon S3 Amazon SimpleDB Amazon DynamoDB Amazon CloudFront Amazon SWF Amazon SQS Amazon SNS Amazon SES Amazon Route53 Elastic LoadBalancing AWS IAM AWS ElasticBeanstalk AmazonElastiCache Amazon EMR AmazonCloudSearch Amazon EC2 Amazon EBS Amazon RDS Amazon VPC
  3. 3. #1DESIGN FORFAILURE●○○○
  4. 4. « Everything failsall the time »Werner VogelsCTO of Amazon
  5. 5. YOUR GOAL:Applications should continue to function evenif the underlying physical hardware fails or isremoved or replaced
  6. 6. AVOID SINGLE POINTS OFFAILURE.ASSUME EVERYTHING FAILS,AND DESIGN BACKWARDS.
  7. 7. AVOID SINGLE POINTS OFFAILURE.ASSUME EVERYTHING FAILS,AND DESIGN BACKWARDS.
  8. 8. HEALTH CHECKS
  9. 9. #2USE MULTIPLEAVAILABILITY ZONES
  10. 10. US-WEST (Oregon))EU-WEST (Ireland)ASIA PAC (Tokyo)ASIA PAC(Singapore)US-WEST (N. California)SOUTH AMERICA (Sao Paulo)US-EAST (Virginia)AWS GovCloud (US)ASIA PAC (Sydney)
  11. 11. AMAZON RDSMULTI-AZ
  12. 12. #3BUILD FOR SCALE
  13. 13. HEALTH CHECKS+AUTO SCALING
  14. 14. HEALTH CHECKS+AUTO SCALING=SELF-HEALING
  15. 15. #4LOOSE COUPLING
  16. 16. PUBLISH& NOTIFYRECEIVE TRANSCODE
  17. 17. PUBLISH& NOTIFYRECEIVE TRANSCODE
  18. 18. VISIBILITYTIMEOUT
  19. 19. BUFFERING
  20. 20. CLOUDWATCH METRICSFOR AMAZON SQS+AUTO SCALING
  21. 21. BUILD LOOSELYCOUPLED SYSTEMSThe looser they are coupled,the bigger they scale,the more fault tolerant they get…
  22. 22. 1. DESIGN FOR FAILURE2. USE MULTI-AZ3. BUILD FOR SCALE4. DECOUPLE COMPONENTS
  23. 23. THANK YOU!

×