AWS	
  201	
  
Designing	
  Scalable,	
  Available	
  &	
  
Resilient	
  Cloud	
  Applica<ons	
  
Markku	
  Lepistö	
  -­‐...
Housekeeping
•  Presentation ~45mins
•  Q&A using the questions panel during the
presentation
•  Reminder – Fill in the su...
AWS	
  Global	
  Presence	
  
10 Regions
26 Availability Zones
52 Edge Locations
SCALABLE,	
  AVAILABLE,	
  RESILIENT	
  
CLOUD	
  APPLICATIONS	
  
What	
  your	
  users	
  want…	
  
What	
  your	
  users	
  want…	
  
Fast,	
  performant	
  
experience	
  
What	
  your	
  users	
  want…	
  
Fast,	
  performant	
  
experience	
  
Always	
  on,	
  
accessible	
  
anywhere	
  
What	
  your	
  users	
  want…	
  
Fast,	
  performant	
  
experience	
  
Always	
  on,	
  
accessible	
  
anywhere	
  
Pe...
What	
  your	
  users	
  want…	
  
Fast,	
  performant	
  
experience	
  
Always	
  on,	
  
accessible	
  
anywhere	
  
Pe...
Fast,	
  performant	
  
experience	
  
Lots	
  of	
  new	
  
features	
  all	
  of	
  the	
  
<me	
  
Always	
  on,	
  
ac...
How?	
  
Building	
  powerful	
  cloud	
  applica<ons	
  
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
Rule	
 ...
DNS	
   Applica<on	
   Data	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
a)	
  Make	
  sure	
  requests	
  get	
  to	
...
DNS	
   Applica<on	
   Data	
  Request	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
a)	
  Make	
  sure	
  requests	
  ...
DNS	
   Applica<on	
   Data	
  Request	
  
a)	
  Make	
  sure	
  requests	
  get	
  to	
  your	
  ‘front	
  door’	
  	
  
...
DNS	
   Applica<on	
   Data	
  Request	
  
…then	
  this	
  is	
  
irrelevant	
  
Clients	
  can’t	
  resolve	
  
you?	
  ...
DNS	
   Applica<on	
   Data	
  Request	
  
“100%	
  
Available”	
  
SLA	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
R...
DNS	
   Applica<on	
   Data	
  Request	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
a)  Make	
  sure	
  requests	
  ge...
Region	
  
DNS	
   Applica<on	
   Data	
  Request	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
Elas<c	
  
Load	
  
Bal...
Region	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
DNS	
   Applica<on	
   Data	
  Request	
  
a)  Make	
  sure	
  req...
Region	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
DNS	
   Applica<on	
   Data	
  Request	
  
Elas<c	
  
Load	
  
Bal...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
Rule	
 ...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
Region	
  ...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
Region	
  ...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
Region	
  ...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Region	
  A	
  
Route53	
  
Region	
  B	
  
16ms	
  ...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
b)  Offload	...
Without	
  CloudFront	
  
EC2	
  webservers/app	
  servers	
  loaded	
  by	
  user	
  
requests	
  	
  
Rule	
  2:	
  Serv...
With	
  CloudFront	
  
Load	
  of	
  user	
  requests	
  pushed	
  into	
  
CloudFront,	
  EC2	
  cluster	
  can	
  scale	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Response	
  Time	
  
Server	
  Load	
  
Response	
  ...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
b)  Offload	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
b)  Offload	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
b)  Offload	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
b)  Offload	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
b)  Offload	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
a)  Choose	
  the	
  fastest	
  route	
  
b)  Offload	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
Rule	
 ...
Rule	
  3:	
  Handle	
  requests	
  at	
  any	
  scale	
  
a)  Scale	
  up	
  
Ver<cal	
  Scaling	
  
From	
  $0.013/hr	
 ...
Rule	
  3:	
  Handle	
  requests	
  at	
  any	
  scale	
  
a)  Scale	
  up	
  
measure	
  instance	
  resource	
  
u<liza<...
Rule	
  3:	
  Handle	
  requests	
  at	
  any	
  scale	
  
a)  Scale	
  up	
  
b)  Scale	
  out	
  
Trigger
auto-scaling
p...
Manually	
  
	
  
Send	
  an	
  API	
  call	
  or	
  use	
  CLI	
  to	
  launch/
terminate	
  instances	
  –	
  Only	
  ne...
Manually	
  
	
  
Send	
  an	
  API	
  call	
  or	
  use	
  CLI	
  to	
  launch/
terminate	
  instances	
  –	
  Only	
  ne...
Rule	
  3:	
  Handle	
  requests	
  at	
  any	
  scale	
  
a)  Scale	
  up	
  
b)  Scale	
  out	
  
c)  Dial	
  it	
  up	
...
Rule	
  3:	
  Handle	
  requests	
  at	
  any	
  scale	
  
a)  Scale	
  up	
  
b)  Scale	
  out	
  
c)  Dial	
  it	
  up	
...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
Rule	
 ...
Your	
  
Business	
  
70%	
  
On-­‐Premise	
  
Infrastructure	
  
30%	
  
Managing	
  All	
  of	
  the	
  	
  
“Undifferen<...
AWS	
  
Cloud-­‐Based	
  
Infrastructure	
  
Your	
  
Business	
  
More	
  Time	
  to	
  Focus	
  on	
  
Your	
  Business	...
Enterprise
Applications
Virtual Desktops Collaboration and Sharing
Platform
Services
Databases
Caching
Relational
No SQL
A...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
Rule	
 ...
Compute	
  
Storage	
  
Security	
   Scaling	
  
Database	
  
Networking	
  
Monitoring	
  
Messaging	
  
Workflow	
  
DNS	...
Rule	
  5:	
  Automate	
  opera<onal	
  management	
  
a)  Everything	
  is	
  programmable	
  
b)  Think	
  disposable,	
...
Rule	
  5:	
  Automate	
  opera<onal	
  management	
  
a)  Everything	
  is	
  programmable	
  
b)  Think	
  disposable,	
...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  1:	
  Service	
  all	
  web	
  requests	
  
...
Rule	
  5:	
  Automate	
  opera<onal	
  management	
  
a)  Everything	
  is	
  programmable	
  
b)  Think	
  disposable,	
...
YOUR GOAL
Applications should continue to function even if
the underlying HW or SW unit fails or is removed
or replaced
Avoid single points of failure.
Assume everything fails, and design
backwards.
Avoid single points of failure.
Assume everything fails, and design
backwards.
MULTI-AZ
DEPLOYMENT
AWS BUILDING BLOCKS
Inherently Fault-Tolerant Services Fault-Tolerant with
the right architecture
!  Amazon S3
!  Amazon D...
BUILD LOOSELY
COUPLED SYSTEMS
The looser the are coupled,
the bigger they scale
Create independent Components
Create independent Components
Design everything as a Black Box
Create independent Components
Design everything as a Black Box
Think in terms of (Micro) Services
Services are Black Boxes Exposed via APIs
My Cool Feature
Iterate, even re-
write internal
implementation
API is stable, w...
Loose Coupling Enables Scale-out and Resiliency
Use Message Queues
Simple Queue
Service (SQS)
Loose Coupling Enables Scale-out and Resiliency
Use Idempotent Interfaces
Loose Coupling Enables Scale-out and Resiliency
Use Circuit Breakers
Loose Coupling Enables Scale-out and Resiliency
Use Circuit Breakers
Temporarily bypass
unresponsive
service. Switch to
de...
Auto Scale, Load Balance, Monitor, HA Assure
Each Service Separately
Statelessness Enables Scale-out
Separate State and Data from Compute Instances
Load Balanced, Auto Scaling
pool of EC2 Wor...
TEST IT
Verify your design by generating
failure modes
Rule 5: Automate operational management
a)  Everything	
  is	
  programmable	
  
b)  Think	
  disposable,	
  one	
  click	...
Rule 5: Automate operational management
a)  Everything	
  is	
  programmable	
  
b)  Think	
  disposable,	
  one	
  click	...
Rule 5: Automate operational management
a)  Everything	
  is	
  programmable	
  
b)  Think	
  disposable,	
  one	
  click	...
Rule	
  2:	
  Service	
  requests	
  as	
  fast	
  as	
  possible	
  
Rule	
  1:	
  Service	
  all	
  requests	
  
Rule	
 ...
What	
  your	
  users	
  want…	
  
Fast,	
  performant	
  
experience	
  
Lots	
  of	
  new	
  
features	
  all	
  of	
  t...
With	
  AWS	
  
Elas<c	
  u<lity	
  
capacity	
  
✔	
  
Lots	
  of	
  new	
  
features	
  all	
  of	
  the	
  
<me	
  
Alw...
With	
  AWS	
  
Elas<c	
  u<lity	
  
capacity	
  
✔	
   Highly	
  available	
  
global	
  coverage	
  
✔	
  
Lots	
  of	
 ...
With	
  AWS	
  
Elas<c	
  u<lity	
  
capacity	
  
✔	
   Highly	
  available	
  
global	
  coverage	
  
✔	
  
Personalized	...
With	
  AWS	
  
Elas<c	
  u<lity	
  
capacity	
  
✔	
   Highly	
  available	
  
global	
  coverage	
  
✔	
  
Agility	
  &	...
aws.amazon.com	
  
	
  
get	
  started	
  with	
  the	
  free	
  <er	
  
Thank	
  you	
  
Markku	
  Lepistö	
  -­‐	
  Technology	
  Evangelist	
  
@markkulepisto	
  
Your	
  feedback	
  is	
  important	
  
Let’s	
  have	
  a	
  Poll!	
  
Let	
  us	
  know	
  what	
  you	
  want	
  to	
  ...
Your	
  feedback	
  is	
  important	
  
Please	
  complete	
  the	
  
Survey!	
  
What’s	
  good,	
  what’s	
  not	
  
Wha...
AWS Webinar 201: Designing scalable, available & resilient cloud applications
AWS Webinar 201: Designing scalable, available & resilient cloud applications
AWS Webinar 201: Designing scalable, available & resilient cloud applications
AWS Webinar 201: Designing scalable, available & resilient cloud applications
AWS Webinar 201: Designing scalable, available & resilient cloud applications
AWS Webinar 201: Designing scalable, available & resilient cloud applications
Upcoming SlideShare
Loading in...5
×

AWS Webinar 201: Designing scalable, available & resilient cloud applications

1,400

Published on

Applications have become a vital aspect of everyday life in nearly every part of the world. No matter where we are, we interact with applications–whether that is by using our mobile phone, withdrawing money from an automated bank machine, or even by just shopping online. Because applications have become such an integral part of our daily lives, a great deal of work has to be done to ensure that these applications remain scalable, operational and available. Cloud-native applications are designed for failure, automation, horizontal scalability, anti-fragility, security, cost-optimization and resilience. Join this session to learn best practices on how to design and implement cloud-ready, or cloud-native applications and workloads.

Reasons to attend:
• Learn practical design patterns and anti-patterns, do's and don'ts.
• Techniques to improve your operational efficiency, cost-control, security posture, availability and scalability.

Who should attend
• Architects
• Developers
• System administrators
• DevOps practitioners
• CTOs

Published in: Internet
1 Comment
10 Likes
Statistics
Notes
  • One of the very best presentations I have come across - very comprehensive, very clear, and above all very nicely thought out. Can you please send me the slides.for my reference and study-notes
       Reply 
    Are you sure you want to  Yes  No
    Your message goes here
No Downloads
Views
Total Views
1,400
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
28
Comments
1
Likes
10
Embeds 0
No embeds

No notes for slide

AWS Webinar 201: Designing scalable, available & resilient cloud applications

  1. 1. AWS  201   Designing  Scalable,  Available  &   Resilient  Cloud  Applica<ons   Markku  Lepistö  -­‐  Technology  Evangelist   @markkulepisto  
  2. 2. Housekeeping •  Presentation ~45mins •  Q&A using the questions panel during the presentation •  Reminder – Fill in the survey!
  3. 3. AWS  Global  Presence   10 Regions 26 Availability Zones 52 Edge Locations
  4. 4. SCALABLE,  AVAILABLE,  RESILIENT   CLOUD  APPLICATIONS  
  5. 5. What  your  users  want…  
  6. 6. What  your  users  want…   Fast,  performant   experience  
  7. 7. What  your  users  want…   Fast,  performant   experience   Always  on,   accessible   anywhere  
  8. 8. What  your  users  want…   Fast,  performant   experience   Always  on,   accessible   anywhere   Personalized  and   rich  applica<on  
  9. 9. What  your  users  want…   Fast,  performant   experience   Always  on,   accessible   anywhere   Personalized  and   rich  applica<on   Lots  of  new   features  all  of  the   <me  
  10. 10. Fast,  performant   experience   Lots  of  new   features  all  of  the   <me   Always  on,   accessible   anywhere   Personalized  and   rich  applica<on   Powerful  cloud  applica<ons  
  11. 11. How?  
  12. 12. Building  powerful  cloud  applica<ons  
  13. 13. Rule  2:  Service  requests  as  fast  as  possible   Rule  1:  Service  all  requests   Rule  3:  Handle  requests  at  any  scale   Rule  4:  Simplify  architecture  with  services   Rule  5:  Automate  opera<onal  management   Rule  6:  Design  for  failure  
  14. 14. DNS   Applica<on   Data   Rule  1:  Service  all  requests   a)  Make  sure  requests  get  to  your  ‘front  door’    
  15. 15. DNS   Applica<on   Data  Request   Rule  1:  Service  all  requests   a)  Make  sure  requests  get  to  your  ‘front  door’    
  16. 16. DNS   Applica<on   Data  Request   a)  Make  sure  requests  get  to  your  ‘front  door’     Rule  1:  Service  all  requests  
  17. 17. DNS   Applica<on   Data  Request   …then  this  is   irrelevant   Clients  can’t  resolve   you?   Rule  1:  Service  all  requests   a)  Make  sure  requests  get  to  your  ‘front  door’    
  18. 18. DNS   Applica<on   Data  Request   “100%   Available”   SLA   Rule  1:  Service  all  requests   Route53   Feature   Details   Global   Supported  from  AWS  global  edge  loca<ons  for  fast  and  reliable  domain   name  resolu<on   Scalable   Automa<cally  scales  based  upon  query  volumes   Latency  based  rouCng   Supports  resolu<on  of  endpoints  based  upon  latency,  enabling  mul<-­‐ region  applica<on  delivery   Integrated   Integrates  with  other  AWS  services  allowing  Route  53  to  front  load   balancers,  S3  and  EC2   Secure   Integrates  with  IAM  giving  fine  grained  control  over  DNS  record  access   hbp://aws.amazon.com/route53/sla   a)  Make  sure  requests  get  to  your  ‘front  door’    
  19. 19. DNS   Applica<on   Data  Request   Rule  1:  Service  all  requests   a)  Make  sure  requests  get  to  your  ‘front  door’   b)  Make  sure  you  open  the  door  when  they  arrive   Route53  
  20. 20. Region   DNS   Applica<on   Data  Request   Rule  1:  Service  all  requests   Elas<c   Load   Balancer   Region   Availability  Zone   Availability  Zone   Availability  Zone   Availability  Zone   Route53   a)  Make  sure  requests  get  to  your  ‘front  door’   b)  Make  sure  you  open  the  door  when  they  arrive   Elas<c  load  balancing   Mul<-­‐availability  zone   Mul<-­‐region  
  21. 21. Region   Rule  1:  Service  all  requests   DNS   Applica<on   Data  Request   a)  Make  sure  requests  get  to  your  ‘front  door’   b)  Make  sure  you  open  the  door  when  they  arrive   c)  Have  the  data  to  form  a  response   Elas<c   Load   Balancer   Region   Availability  Zone   Availability  Zone   Availability  Zone   Availability  Zone   Route53  
  22. 22. Region   Rule  1:  Service  all  requests   DNS   Applica<on   Data  Request   Elas<c   Load   Balancer   Route53   Region   Availability  Zone   Availability  Zone   Availability  Zone   Availability  Zone   a)  Make  sure  requests  get  to  your  ‘front  door’   b)  Make  sure  you  open  the  door  when  they  arrive   c)  Have  the  data  to  form  a  response   Mul<-­‐AZ  RDS   Synchronous   Intra-­‐region   Master/Slave   Asynchronous   Cross-­‐region   Read  Replicas  
  23. 23. Rule  2:  Service  requests  as  fast  as  possible   Rule  1:  Service  all  requests   Rule  3:  Handle  requests  at  any  scale   Rule  4:  Simplify  architecture  with  services   Rule  5:  Automate  opera<onal  management   Rule  6:  Design  for  failure  
  24. 24. Rule  2:  Service  requests  as  fast  as  possible  
  25. 25. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   Region  A   Route53   Region  B   Request  
  26. 26. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   Region  A   Route53   Region  B   16ms   92ms   Request  
  27. 27. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   Region  A   Route53   Region  B   16ms   92ms   Request  
  28. 28. Rule  2:  Service  requests  as  fast  as  possible   Region  A   Route53   Region  B   16ms   Request   Region  A  DNS  entry   a)  Choose  the  fastest  route  
  29. 29. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers   Singapore Tokyo Sydney Served from S3 /images/* 3 Served from EC2 *.php 2 Single CNAME www.mysite.com 1 CloudFront   World-­‐wide  content  distribu1on  network   Easily  distribute  content  to  end  users  with  low   latency,  high  data  transfer  speeds,  and  no   commitments.    
  30. 30. Without  CloudFront   EC2  webservers/app  servers  loaded  by  user   requests     Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers  
  31. 31. With  CloudFront   Load  of  user  requests  pushed  into   CloudFront,  EC2  cluster  can  scale   down   Offload   Scale     Down   Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers  
  32. 32. Rule  2:  Service  requests  as  fast  as  possible   Response  Time   Server  Load   Response  Time   Server   Load   Response  Time   Server   Load   No  CDN   CDN  for   Sta<c   Content   CDN  for   Sta<c  &   Dynamic   Content   Offload   Scale     Down   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers  
  33. 33. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers   c)  Cache  it  if  you  can   Elas<Cache   Memcached  and  Redis  compa1ble   caching  layer   Serve  frequently  requested  &  slow   changing  data  from  scalable  cache   clusters   Reduce  load  on  database  and  other   servers    
  34. 34. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers   c)  Cache  it  if  you  can   d)  Single  digit  latencies  where  it  mabers   Scale   Database  Query  Performance   Desired  consistency,  predictability  
  35. 35. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers   c)  Cache  it  if  you  can   d)  Single  digit  latencies  where  it  mabers   Scale   Database  Query  Performance   Desired  consistency,  predictability   Actual   degraded   performance   with  scale  
  36. 36. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers   c)  Cache  it  if  you  can   d)  Single  digit  latencies  where  it  mabers   Scale   Database  Query  Performance   Desired  consistency,  predictability   Actual   degraded   performance   with  scale   Management problems   Data  sharding   Data  caching   Provisioning   Cluster  management   Fault  management  
  37. 37. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers   c)  Cache  it  if  you  can   d)  Single  digit  latencies  where  it  mabers   Scale   Database  Query  Performance   Dynamo  DB  Query  Performance   Rela<onal   Database   Query   Performance   DynamoDB   Low  latency   Large  scale   Zero  admin   Predictable  performance  
  38. 38. Rule  2:  Service  requests  as  fast  as  possible   a)  Choose  the  fastest  route   b)  Offload  your  applica<on  servers   c)  Cache  it  if  you  can   d)  Single  digit  latencies  where  it  mabers   Scale   Database  Query  Performance   Dynamo  DB  Query  Performance   DynamoDB   Low  latency   Large  scale   Zero  admin   Predictable  performance   Average  single-­‐digit  milliseconds  server  side   latencies     Runs  on  solid  state  drives,  and  is  built  to   maintain  consistent,  fast  latencies  at  any  scale  
  39. 39. Rule  2:  Service  requests  as  fast  as  possible   Rule  1:  Service  all  requests   Rule  3:  Handle  requests  at  any  scale   Rule  4:  Simplify  architecture  with  services   Rule  5:  Automate  opera<onal  management   Rule  6:  Design  for  failure  
  40. 40. Rule  3:  Handle  requests  at  any  scale   a)  Scale  up   Ver<cal  Scaling   From  $0.013/hr   Basic  unit  of  compute  capacity   Several  families  of  instance  types  available,  from  micro  to   compute,  storage,  memory  and  GPU  op1mized   Scale  up  with  Elas<c  Compute  Cloud  (EC2)  
  41. 41. Rule  3:  Handle  requests  at  any  scale   a)  Scale  up   measure  instance  resource   u<liza<on  under  load   &     select  opCmal  instance  size   per  applica<on  <er  /   service    
  42. 42. Rule  3:  Handle  requests  at  any  scale   a)  Scale  up   b)  Scale  out   Trigger auto-scaling policy as-create-auto-scaling-group MyGroup --launch-configuration MyConfig --availability-zones ap-southeast-1a --min-size 4 --max-size 200 Auto-­‐scaling   Automa1c  re-­‐sizing  of  compute  clusters  based  upon  demand    
  43. 43. Manually     Send  an  API  call  or  use  CLI  to  launch/ terminate  instances  –  Only  need  to   specify  capacity  change  (+/-­‐)     By  Schedule     Scale  up/down  based  on  date  and  <me   a)  Scale  up   b)  Scale  out   By  Policy     Scale  in  response  to  changing  condi<ons,   based  on  user  configured  real-­‐<me   monitoring  and  alerts   Auto-­‐Rebalance     Instances  are  automa<cally  launched/ terminated  to  ensure  the  applica<on  is   balanced  across  mul<ple  AZs         Rule  3:  Handle  requests  at  any  scale  
  44. 44. Manually     Send  an  API  call  or  use  CLI  to  launch/ terminate  instances  –  Only  need  to   specify  capacity  change  (+/-­‐)     By  Schedule     Scale  up/down  based  on  date  and  <me  Preemp<ve  manual  scaling  of   capacity     e.g.  before  a  marke1ng  event  add  10  more   instances   Regular  scaling  up  and  down  of   instances     e.g.  scale  from  0  to  2  to  process  SQS   messages  every  night  or  double  capacity   on  a  Friday  night   a)  Scale  up   b)  Scale  out   By  Policy     Scale  in  response  to  changing  condi<ons,   based  on  user  configured  real-­‐<me   monitoring  and  alerts   Auto-­‐Rebalance     Instances  are  automa<cally  launched/ terminated  to  ensure  the  applica<on  is   balanced  across  mul<ple  Azs         Rule  3:  Handle  requests  at  any  scale   Dynamic  scale  based  upon   custom  metrics     e.g.  SQS  queue  depth,  Average  CPU  load,   ELB  latency   Maintain  capacity  across   availability  zones     e.g.  Instance  availability  maintained  in   event  of  AZ  becoming  unavailable  
  45. 45. Rule  3:  Handle  requests  at  any  scale   a)  Scale  up   b)  Scale  out   c)  Dial  it  up   Elas<c  Block  Store   Provisioned  IOPS  up  to  4000  per   volume,  up  to  48  000  per  instance   Predictable  performance  for     demanding  workloads  such  as   databases   DynamoDB   Provisioned  read/write  performance  per  table   Predictable  high  performance  scaled  via   console,  API  or     Dynamic  DynamoDB,  at   hYp://dynamic-­‐dynamodb.readthedocs.org  
  46. 46. Rule  3:  Handle  requests  at  any  scale   a)  Scale  up   b)  Scale  out   c)  Dial  it  up   Dynamic  DynamoDB  
  47. 47. Rule  2:  Service  requests  as  fast  as  possible   Rule  1:  Service  all  requests   Rule  3:  Handle  requests  at  any  scale   Rule  4:  Simplify  architecture  with  services   Rule  5:  Automate  opera<onal  management   Rule  6:  Design  for  failure  
  48. 48. Your   Business   70%   On-­‐Premise   Infrastructure   30%   Managing  All  of  the     “Undifferen<ated  Heavy  Liring”   Rule  4:  Simplify  architecture  with  services  
  49. 49. AWS   Cloud-­‐Based   Infrastructure   Your   Business   More  Time  to  Focus  on   Your  Business   Configuring  Your   Cloud  Assets   70%   30%  70%   On-­‐Premise   Infrastructure   30%   Managing  All  of  the     “Undifferen<ated  Heavy  Liring”   Rule  4:  Simplify  architecture  with  services  
  50. 50. Enterprise Applications Virtual Desktops Collaboration and Sharing Platform Services Databases Caching Relational No SQL Analytics Hadoop Real-time Data Workflows Data Warehouse App Services Queuing Orchestration App Streaming Transcoding Email Search Deployment & Management Containers Dev/ops Tools Resource Templates Usage Tracking Monitoring and Logs Mobile Services Identity Sync Mobile Analytics Notifications Foundation Services Compute (VMs, Auto-scaling and Load Balancing) Storage (Object, Block and Archive) Security & Access Control Networking Infrastructure Regions CDN and Points of PresenceAvailability Zones
  51. 51. Rule  2:  Service  requests  as  fast  as  possible   Rule  1:  Service  all  requests   Rule  3:  Handle  requests  at  any  scale   Rule  4:  Simplify  architecture  with  services   Rule  5:  Automate  opera<onal  management   Rule  6:  Design  for  failure  
  52. 52. Compute   Storage   Security   Scaling   Database   Networking   Monitoring   Messaging   Workflow   DNS   Load  Balancing   Backup  CDN   Rule  5:  Automate  opera<onal  management   a)  Everything  is  programmable   Access  everything   via  CLI,  API  or   Console   Achieve  the  highest  levels   of  automa<on   sophis<ca<on  with  ease  
  53. 53. Rule  5:  Automate  opera<onal  management   a)  Everything  is  programmable   b)  Think  disposable,  one  click  deployments   AWS  OpsWorks   AWS   CloudFormaCon   AWS  ElasCc   Beanstalk   DevOps  framework  for   applicaCon  lifecycle   management  and   automaCon   Templates  to  deploy  &   update  infrastructure   as  code   Automated  resource   management  –  web   apps  made  easy   DIY  /     On  Demand   DIY,  on  demand   resources:  EC2,  S3,   custom  AMI’s,  etc.   ControlConvenience
  54. 54. Rule  5:  Automate  opera<onal  management   a)  Everything  is  programmable   b)  Think  disposable,  one  click  deployments  
  55. 55. Rule  2:  Service  requests  as  fast  as  possible   Rule  1:  Service  all  web  requests   Rule  3:  Handle  requests  at  any  scale   Rule  4:  Simplify  architecture  with  services   Rule  5:  Automate  opera<onal  management   Rule  6:  Design  for  failure  
  56. 56. Rule  5:  Automate  opera<onal  management   a)  Everything  is  programmable   b)  Think  disposable,  one  click  deployments   c)  Design  for  failure,  implement  self  healing   Customize  instance   startup     Get  instances  to  ask  ‘who  am   I?’  ques<on  on  startup  and  be   configured  dynamically  upon   being  answered     Maintain  capacity  of   instances     Using  a  minimum  pool   size  will  maintain   capacity  in  the  event  of   instance  failures   Know  what’s  going  on,   take  automated  ac<ons     Use  CloudWatch  standard  and   custom  metrics  to  create   alarms.       Respond  with  automated   administra<on  ac<ons   Bootstrapping Auto-scaling Cloud Watch
  57. 57. YOUR GOAL Applications should continue to function even if the underlying HW or SW unit fails or is removed or replaced
  58. 58. Avoid single points of failure. Assume everything fails, and design backwards.
  59. 59. Avoid single points of failure. Assume everything fails, and design backwards.
  60. 60. MULTI-AZ DEPLOYMENT
  61. 61. AWS BUILDING BLOCKS Inherently Fault-Tolerant Services Fault-Tolerant with the right architecture !  Amazon S3 !  Amazon DynamoDB !  Amazon CloudFront !  Amazon SWF !  Amazon SQS !  Amazon SNS !  Amazon SES !  Amazon Route53 !  Elastic Load Balancing !  AWS IAM !  AWS Elastic Beanstalk !  Amazon ElastiCache !  Amazon EMR !  Amazon CloudSearch !  Amazon Redshift !  etc "  Amazon EC2 "  Amazon EBS "  Amazon RDS "  Amazon VPC
  62. 62. BUILD LOOSELY COUPLED SYSTEMS The looser the are coupled, the bigger they scale
  63. 63. Create independent Components
  64. 64. Create independent Components Design everything as a Black Box
  65. 65. Create independent Components Design everything as a Black Box Think in terms of (Micro) Services
  66. 66. Services are Black Boxes Exposed via APIs My Cool Feature Iterate, even re- write internal implementation API is stable, with few changes, potentially versioning API
  67. 67. Loose Coupling Enables Scale-out and Resiliency Use Message Queues Simple Queue Service (SQS)
  68. 68. Loose Coupling Enables Scale-out and Resiliency Use Idempotent Interfaces
  69. 69. Loose Coupling Enables Scale-out and Resiliency Use Circuit Breakers
  70. 70. Loose Coupling Enables Scale-out and Resiliency Use Circuit Breakers Temporarily bypass unresponsive service. Switch to degraded mode transactions
  71. 71. Auto Scale, Load Balance, Monitor, HA Assure Each Service Separately
  72. 72. Statelessness Enables Scale-out Separate State and Data from Compute Instances Load Balanced, Auto Scaling pool of EC2 Workers Scalable Services for State and Data ElastiCacheDynamoDBS3
  73. 73. TEST IT Verify your design by generating failure modes
  74. 74. Rule 5: Automate operational management a)  Everything  is  programmable   b)  Think  disposable,  one  click  deployments   c)  Design  for  failure,  implement  self  healing   Chaos Monkey Introduce failures GAME DAY!
  75. 75. Rule 5: Automate operational management a)  Everything  is  programmable   b)  Think  disposable,  one  click  deployments   c)  Design  for  failure,  implement  self  healing   Latency Monkey Slow down dependent service responses
  76. 76. Rule 5: Automate operational management a)  Everything  is  programmable   b)  Think  disposable,  one  click  deployments   c)  Design  for  failure,  implement  self  healing   Conformity Monkey Detect system entropy & drift
  77. 77. Rule  2:  Service  requests  as  fast  as  possible   Rule  1:  Service  all  requests   Rule  3:  Handle  requests  at  any  scale   Rule  4:  Simplify  architecture  with  services   Rule  5:  Automate  opera<onal  management   Rule  6:  Design  for  failure  
  78. 78. What  your  users  want…   Fast,  performant   experience   Lots  of  new   features  all  of  the   <me   Always  on,   accessible   anywhere   Personalized  and   rich  applica<on  
  79. 79. With  AWS   Elas<c  u<lity   capacity   ✔   Lots  of  new   features  all  of  the   <me   Always  on,   accessible   anywhere   Personalized  and   rich  applica<on  
  80. 80. With  AWS   Elas<c  u<lity   capacity   ✔   Highly  available   global  coverage   ✔   Lots  of  new   features  all  of  the   <me   Personalized  and   rich  applica<on  
  81. 81. With  AWS   Elas<c  u<lity   capacity   ✔   Highly  available   global  coverage   ✔   Personalized  and   rich  applica<on   Agility  &   automated   opera<ons   ✔  
  82. 82. With  AWS   Elas<c  u<lity   capacity   ✔   Highly  available   global  coverage   ✔   Agility  &   automated   opera<ons   ✔   Cost  effec<ve   storage,  big  data  &     analy<cs   ✔  
  83. 83. aws.amazon.com     get  started  with  the  free  <er  
  84. 84. Thank  you   Markku  Lepistö  -­‐  Technology  Evangelist   @markkulepisto  
  85. 85. Your  feedback  is  important   Let’s  have  a  Poll!   Let  us  know  what  you  want  to  see  next  
  86. 86. Your  feedback  is  important   Please  complete  the   Survey!   What’s  good,  what’s  not   What  you  want  to  see  at  these  events   What  you  want  AWS  to  deliver  for  you  

×