Your SlideShare is downloading. ×
Architecting Your Killer App on AWS Sydney Customer Appreciation Day
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Architecting Your Killer App on AWS Sydney Customer Appreciation Day

595

Published on

Hub Works and Joe Ziegler's session for the Australia Customer Appreciation Day, November 13, 2012

Hub Works and Joe Ziegler's session for the Australia Customer Appreciation Day, November 13, 2012

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

No Downloads
Views
Total Views
595
On Slideshare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide
  • Autoscale on Queue Length
  • 00:47:00
  • Transcript

    • 1. Architecting your Killer App on AWSJoe Zieglerzieglerj@amazon.com@jiyosub
    • 2. Standing on the Shoulders of Giants
    • 3. Building  a  killer  app  is  not  just  about  logic,  it  is  also  about  the  inven7on.  The  story.      Story  provides  purpose.        
    • 4. The ProblemI  was  looking  for  answers  on  a  federal  government  website  and  there  was  a  diagram  showing  the  same  problem  at  a  na7onal  level.  
    • 5. The SolutionCri7cal  transparency    can  alert  families  and  child  care  providers  immediate  informa7on  which  could    save  a  child’s  life.
    • 6. A child’s life cycle is provided ina protected, focused andexclusive facility.
    • 7. The  core  innova7on  is  HubCares  ability    to  ‘facilitate’  interac7on  between  Care  Providers,  Government  and  Families.      We  link  all  par7es  in  the  care  of  a  child.    This  serves  the  welfare  of  high  risk  children,  and  provides  social  and  development  benefits  for  low  risk  children.        
    • 8. What  does  this  mean  to  early  childhood       A  posi7ve  disrup7on  for  the  early  childhood  ecosystem  in  the  way  it  handles  informa7on.      Disruption     Care  Providers    -­‐  Provide  high  quality  care              Children    -­‐  The  right  to  own  their  informa7on                -­‐  Government  Compliance                                                -­‐  Informa7on  travels  with  the  child           Government          -­‐  Filling  the  void  ‘the  problem              Families    -­‐  Sense  of  security                                                          -­‐  Fraud  reduc7on                                                                                              -­‐  Transparency                                                            -­‐  COAG  Mandates                                                  -­‐  Owning  decisions                  -­‐  Automa7on  of  compliance                        -­‐  Reputa7on  ‘Educa7on  Revolu7on                                                          -­‐  Economy  –    GeRng  parents  back  to  work  
    • 9. So  what  makes  a  good  story?      At  HubCare  80%  of  what  we  do  is  purpose,  20%  is  logic.
    • 10. ElasticityLoose CouplingHigh Availability Agility
    • 11. ElasticityLoose CouplingHigh Availability Agility
    • 12. ElasticityOn and Off Fast GrowthVariable peaks Predictable peaks
    • 13. ElasticityOn and Off WASTE Fast Growth Poor ServiceVariable peaks Predictable peaks
    • 14. ElasticityOn and Off Fast GrowthVariable peaks Predictable peaks
    • 15. HubWorks! Elasticity- On and Off Pattern / Predictable Peaks- Lots of users during daytime, limited users nights and weekends- 10 x growth over the course of the day (30rpm - 300rpm)- Auto scaling group increases from 2 - 16 instances each day during peaks
    • 16. HubWorks! daily rpm
    • 17. HubWorks! weekly rpm
    • 18. I’m sold, how do I get it?You have to be ableto scale horizontally!
    • 19. Scale Horizontally Stateless ComputeMore Servers = More PowerBootstrapping is your Friend
    • 20. Design TechniquesDevelop with Load BalancerState into NoSQL or cache Automate Bootstrap from S3
    • 21. HubWorks! Stateless- Each EC2 instance behind the Load Balancer does not really perform any compute by itself- State is accessed through layers of memcached and Postgres- Each instance requests data from cache or database and renders that data- Instances can be brought up or down at any time and handle next requests without knowledge of prior or next requests - thanks to this Stateless property
    • 22. ElasticityLoose CouplingHigh Availability Agility
    • 23. Loose CouplingThe looser they are coupled, the bigger they scale.
    • 24. I’ll take some Loose Coupling too Focus on Services Simple Queuing ServiceScale Services Horizontally Autoscale on Queue Size
    • 25. HubWorks! Loose Coupling- Web layer is decoupled from more heavy components e.g. reporting service and CCMS communication service (deliver_agent)- Allows us to scale each component/service independently.- Reporting service- CCMS communicating service (deliver_agent)- Grow or shrink each service depending on its own peaks
    • 26. ElasticityLoose CouplingHigh Availability Agility
    • 27. High Availability Avoid single points of failure.Assume everything fails, and design backwards.
    • 28. AWS BUILDING BLOCKS Inherently Fault-Tolerant Fault-Tolerant with Services the right architecture  Amazon S3   Amazon Route53   Amazon EC2  Amazon SimpleDB   Elastic Load Balancing   Amazon EBS  Amazon DynamoDB   AWS IAM   Amazon RDS  Amazon CloudFront   AWS Elastic   Amazon VPC  Amazon SWF Beanstalk  Amazon SQS   Amazon  Amazon SNS ElastiCache  Amazon SES   Amazon EMR   Amazon CloudSearch
    • 29. Highly Available StateConsider S3 for Read Access Partition DataReduce Reliance on Relational Database Systems
    • 30. Highly Available Deployment Route 53 Build and Destroy Hot Standby
    • 31. Design for Failure
    • 32. HubWorks! Design for Failure- Multiple availability zones (us-west-1a and us-west-1b)- Autoscaling and Load balancers to manage and direct load- Plan to use Cloud Watch for self healing’- High availability for the DB layer by implementing a stand-by server
    • 33. ElasticityLoose CouplingHigh Availability Agility
    • 34. Focus on Core Competencies Database Scaling Search Scalable Web Properties Email Services
    • 35. Infrastructure as Code “Programmatic provisioning by API”Everything in AWS is an API
    • 36. Tool Box Libraries and SDKs AMICloudFormation
    • 37. Agile Architecture #2 promote to staging Pypoll demo app #3 install #1 publish artifact EC2 Instance Contents EC2 Instance Contents artifact Internet #5 promote to prod #4 publish Bucket artifact with Objects Instances #6 install EC2 Instance Contents Bucket artifact with Objects AWS Cloud
    • 38. HubWorks! Agile- Almost to the point of being too agile!- Deploy new features into production fortnightly- Open online forum with users where we gauge their voice- Iterative Development methodology- Use TDD/BDD
    • 39. Change the Paradigm “You are no longer writing anapplication. You are creating an entire architecture”
    • 40. ElasticityLoose CouplingHigh Availability Agility
    • 41. AWS Customer Appreciation Day

    ×