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

1. Architecting your Killer App on AWS
Joe Ziegler
zieglerj@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 Problem
I
was
looking
for
answers
on
a
federal
government
website
and
there
was
a
diagram
showing
the
same
problem
at
a
na7onal
level.

5. The Solution
Cri7cal
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 in
a protected, focused and
exclusive facility.

7. The
core
innova7on
is
HubCare's
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. Elasticity
Loose Coupling
High Availability
Agility

11. Elasticity
Loose Coupling
High Availability
Agility

12. Elasticity
On and Off Fast Growth
Variable peaks Predictable peaks

13. Elasticity
On and Off WASTE Fast Growth
Poor
Service
Variable peaks Predictable peaks

14. Elasticity
On and Off Fast Growth
Variable 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 able
to scale horizontally!

19. Scale Horizontally
Stateless Compute
More Servers = More Power
Bootstrapping is your Friend

22. Design Techniques
Develop with Load Balancer
State into NoSQL or cache
Automate
Bootstrap from S3

23. 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

24. Elasticity
Loose Coupling
High Availability
Agility

25. Loose Coupling
The looser they are coupled,
the bigger they scale.

26. I’ll take some Loose Coupling too
Focus on Services
Simple Queuing Service
Scale Services Horizontally
Autoscale on Queue Size

27. 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

28. Elasticity
Loose Coupling
High Availability
Agility

29. High Availability
Avoid single points of failure.
Assume everything fails, and design
backwards.

30. 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

31. Highly Available State
Consider S3 for Read Access
Partition Data
Reduce Reliance on Relational
Database Systems

32. Highly Available Deployment
Route 53
Build and Destroy
Hot Standby

33. Design for Failure

34. 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

35. Elasticity
Loose Coupling
High Availability
Agility

36. Focus on Core Competencies
Database Scaling
Search
Scalable Web Properties
Email Services

37. Infrastructure as Code
“Programmatic
provisioning by API”
Everything in AWS is an API

38. Tool Box
Libraries and SDKs
AMI
CloudFormation

39. 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

40. 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

41. Change the Paradigm
“You are no longer writing an
application. You are creating an entire
architecture”

42. Elasticity
Loose Coupling
High Availability
Agility

43. AWS Customer Appreciation
Day