Designing Cloud-Aware Applications

We can’t keep building applications the same way we’ve always done and expect them to work well on cloud platforms. We’ve got to let go of WORA (write once, run anywhere). Clouds offer different features and fail in different ways. Systems need to be engineered to be aware of these peculiarities.

In this presentation, Richard urges developers to think about abandoning existing and comfortable patterns and guides them towards new ones that will allow their applications to be more awesome on their chosen cloud.

Transcript

1. Designing  Cloud-­‐Aware   Applica4ons   Richard  Watson   @richwatson  
4. Why  Build  Cloud-­‐ Aware  Applica4ons?  
6. Reason  1.  Because   clouds  fail  –  all  of   them  
11. 11 Must not say ‘silver lining’ in cloud talk
12. “We’d  point  fingers,     but  we  wouldn’t  be     where  we  are  today     without  EC2”  
15. 15 Reason  2.  Because   architecture   decisions  translate   directly  to  cost  in   the  cloud  
16. $ Processing   data   $ Sending   emails   $ Moving   data   $ Storing   data     $ Load   balancing   $ Managing  IP     addresses   $ Monitoring   WTF?  
17. Reason  3.  Because   you  may  not  get  the   pony  you  wanted  
21. We've  got   room!  
23. Remind  me:  Why  Cloud  anyway?     Uses  shared   and  dynamic   infrastructure   On-­‐demand   as  a  service   Elas4c  and   scalable   Meters   consump4on   Available  across  common  networks  
25. 25 “The future is already here — it's just not very evenly distributed.”! - William Gibson, 1993. "
26. 26 The area under curve is number of adopters
27. Reason  4:   Technology  will  not   save  us  this  4me  
28. 28 Don’t  call  security.     I’m  an   “enterprisey”  guy.  
29. 29 I’ve  been  building   distributed  systems     for  20  years  
32. 32 Photo by DAVID ILIFF. License: CC-BY-SA 3.0
37. How Do I Design a Cloud-Aware Application?
39. Characteristics Principles and Constraints Patterns Goals Anti- patterns App Structure and organization Cost-effective Peak-load- capacity Scales Elastically and Uses Shared Infrastructure Parallelizable and Resource Consumption Aware Stateless; Data Partitioning ACID Transactions, Hardware Affinity
40. Latency   Tolerant   Instrumented   Failure   Aware   Parallelizable   Automated   Resource   Consump4on   Aware  
45. • Hardware  will  fail   • So^ware  will  have  bugs   • Operators  will  make   mistakes   Mo4va4on   • Stateless  services   • Redundancy   • Idempotent  opera4ons   Pa_erns   • Stateful  services   • Single  point  of  failure   An4-­‐ pa_erns   Failure  Aware  
46. Failure  Aware  
49. PRODUCTION Meta US-WEST-2 US-EAST-1
50. 50 Automated  
51. • Easily  re-­‐created   and  installed,   expendable   Mo4va4on   • Restartable   • Recipe  driven   Pa_erns   • Complex   dependencies   • Hardware  affinity   • Eager  loading   An4-­‐ pa_erns   Automated  
52. 52 640K  ought  to  be   enough  for  everybody    -­‐  Bill  Gates,  1981  
53. • Efficient  resource   usage  (aka  Pay  less!)   Mo4va4on   • Fine-­‐grained  modular   services   • Mul4tenancy   Pa_erns   • Monolithic  design  and   deployment   • Single  tenancy   An4-­‐ pa_erns   Resource  Consump4on   Aware  
55. •  Can't  debug   •  Understand   design  impact   Mo4va4on   •  APIs   •  Media4on   points   Pa_erns   •  Direct  code-­‐ to-­‐container   •  Monolithic   code  design   An4-­‐ pa_erns   Instrumented  
57. Scaling  –  you  can  get  bigger  or  get  more   57
59. 59 Of  course  it  scales     –  it’s  in  the  cloud.  
61. • Horizontal   scalability   Mo4va4on   • Stateless   • RESTful   • Workload   decomposi4on   Pa_erns   • Single  Point  of   Bo_leneck   • Synchronous   An4-­‐ pa_erns   Parallelizable  
62. 62 Latency  Tolerant  
63. 63 Latency numbers everyone should know 
 (by Jeff Dean / Peter Norvig) " https://gist.github.com/jboner/2841832
64. • Shared  and  virtual   infrastructure   • Accessed  across   Internet   Mo4va4on   • Asynchronous,  Event-­‐ driven   • In-­‐memory   processing,  CDN   Pa_erns   • Synchronous,  cha_y   interac4ons   • Latency  guarantees   An4-­‐ pa_erns   Latency  Tolerant  
65. Great,  who   implements  these   pa_erns?  
66. DIY   automagic  
67. IaaS   Developer   PaaS   Asynchronous   Data  caching   Fine  grained  &     modular  services   Redundancy   Workload   decomposi>on   Pa?erns   Who     Implements?   =  Implements   =  Par>ally  implements  
69. 69 @richwatson     rwatson@                .com