Save 37% off PRO during our Black Friday Sale! »

Designing Applications for Amazon Web Services (GOTO Aarhus)

Designing Applications for Amazon Web Services (GOTO Aarhus)

Deploying apps to EC2 is surprisingly not about code, it's about culture, it's about embracing failure.

4d9dd9bd8d3d4d0ba8af2acc41d14006?s=128

Mathias Meyer

October 10, 2011
Tweet

Transcript

  1. Designing Apps for Amazon Web Services Mathias Meyer, GOTO Aarhus

    2011
  2. None
  3. Me — infrastructure — code — databases @roidrage www.paperplanes.de

  4. The Cloud

  5. None
  6. None
  7. None
  8. 10,000 feet

  9. Amazon Web Services

  10. EC2

  11. On-demand computing

  12. API

  13. Pay as you go

  14. Multiple regions

  15. Multiple datacenters

  16. Different instance types

  17. High CPU vs. High memory

  18. 1.7 GB - 68 GB

  19. Elastic Block Store

  20. Mount to any instance

  21. Snapshots

  22. More AWS Products S3 CloudFront CloudFormation CloudWatch RDS Auto Scaling

    SimpleDB Route 53 Load Balancing Queue Service Notification Service Elastic MapReduce
  23. What’s Scalarium?

  24. Automates: Setup Configuration One-Click Deploy

  25. ...for EC2 ...on EC2

  26. Automation

  27. The Dream: Configure a cluster Push a button Boom!

  28. Two ways...

  29. Create image, boot it.

  30. Build once, use forever

  31. How do you handle updates?

  32. Configure from scratch

  33. None
  34. None
  35. Configuration + Cookbooks/Manifests + Chef/Puppet/etc. = Configured cluster

  36. Configuration: Chef Server RightScale JSON Scalarium

  37. None
  38. In the beginning...

  39. Scalarium

  40. None
  41. None
  42. None
  43. Automate, automate, automate!

  44. EC2 is not a traditional datacenter

  45. None
  46. None
  47. Multi-tenant

  48. High likelihood of failure

  49. Faulty instances

  50. Datacenter outage

  51. Network partition

  52. More instances = Higher chance of failure

  53. MTBF

  54. 21/04/2011

  55. None
  56. 7/8/2011

  57. None
  58. None
  59. Failure is a good thing

  60. You can ignore it

  61. Learn from it

  62. Design for it

  63. Don’t fear failure

  64. Plan for failure

  65. Design for resilience

  66. Plan for recovery

  67. MTTR

  68. Disaster recovery plan

  69. Multi-datacenter deployments

  70. Replication

  71. None
  72. Multi-region deployments

  73. $$$

  74. Relax consistency requirements

  75. Latency

  76. Keep data local

  77. None
  78. Keep data in memory

  79. Cache is king

  80. Use RAIDs for EBS

  81. Use local storage

  82. Use bigger instances

  83. What would I do differently?

  84. Small services

  85. Frontend vs. Small APIs

  86. Fail fast

  87. Retry

  88. Don’t just assume failure

  89. Test failure

  90. None
  91. “Think about your software running.” Theo Schlossnagle, OmniTI

  92. Understand your code’s breaking points

  93. Isn’t all that what you do at large scale?

  94. Cloud == Large scale

  95. You’re a part of it

  96. Scalarium today

  97. Scalarium runs on Scalarium

  98. None
  99. None
  100. None
  101. Lack of visibility

  102. Don’t fall for SLAs

  103. Amazon only handles infrastructure

  104. How you build on it is up to you

  105. Fun fact

  106. amazon.com is served off EC2

  107. It’s not the cloud that matters, it’s how you use

    it.
  108. Thank you!