1. Building cloud-enabled apps
How to take advantage of the AWS scalability & elasticity
Andreas Chatzakis – Solutions Architect
@achatzakis
AWS for Startups
London, 12th September 2013

2. Agenda
• Intro: AWS foundation
• Scalability: from a single server to multiple instances
• Autoscaling: pay only for what you use
• Database: scaling relational or NoSQL DBs
• Agility: not servers => software components

3. Intro

4. Utility computing
On demand Pay as you go
Uniform Available

5. On demand Pay as you go
Uniform Available
Utility computing

6. Utility computing

7. Compute
Storage
Security
Scaling
Database
Networking
Monitoring
Messaging
Workflow
DNS
Load Balancing
BackupCDN
On demand Pay as you go
Uniform Available
Utility computing

8. US-WEST (Oregon)
EU-WEST (Ireland)
ASIA PAC (Tokyo)
US-WEST (N. California)
SOUTH AMERICA (Sao Paulo)
US-EAST (Virginia)
AWS GovCloud (US)
ASIA PAC
(Sydney)
Regions
ASIA PAC
(Singapore)

9. US-WEST (Oregon)
EU-WEST (Ireland)
ASIA PAC (Tokyo)
US-WEST (N. California)
SOUTH AMERICA (Sao Paulo)
US-EAST (Virginia)
AWS GovCloud (US)
ASIA PAC
(Sydney)
Availability Zones
ASIA PAC
(Singapore)

10. Compute Storage
AWS Global Infrastructure
Database
App Services
Deployment & Administration
Networking
Amazon
CloudWatch AWS IAM AWS
CloudFormation
Amazon Elastic
Beanstalk
AWS
Data
Pipeline
AWS
OpsWorks
Amazon
CloudSearch
Amazon SQSAmazon
SNS
Amazon
Elastic
Transcoder
Amazon SWF
Amazon SES
Amazon
DynamoDB
Amazon RDS
Amazon
ElastiCache
Amazon
RedShift
AWS Storage
Gateway
Amazon S3
Amazon
Glacier
Amazon
CloudFrontAmazon
EC2
Amazon
EMR
Amazon
VPC
Amazon
Route 53
AWS
Direct
Connect

11. Scaling up as you grow

12. Day One, User One:
• A single EC2 Instance
– With full stack on this host
• Web App
• Database
• Management
• etc
• A single Elastic IP
• Route53 for DNS
EC2
Instance
Elastic IP
Amazon
Route 53
User

13. Scaling Vertically
• Simplest approach
• Can now leverage PIOPs
• High I/O instances
• High Memory instances
• High CPU instances
• High storage instances
• Easy to change instance sizes
• Will hit an endpoint eventually
hi1.4xlarge
m2.4xlarge
m1.small

14. Day One, User One:
• We could potentially get
to a few hundred to a few
thousand depending on
application complexity
and traffic
• Manual failover
• No redundancy
• Too many eggs in one
basket
EC2
Instance
Elastic IP
Amazon
Route 53
User

15. Day One, User One:
• We could potentially get
to a few hundred to a few
thousand depending on
application complexity
and traffic
• Manual failover
• No redundancy
• Too many eggs in one
basket
EC2
Instance
Elastic IP
Amazon
Route 53
User

16. Day Two, User >1:
First lets separate out
our single host into
more than one.
• Web
• Database
– Make use of a database
service?
Web
Instance
Database
Instance
Elastic IP
Amazon
Route 53
User

17. User >100:
First lets separate out
our single host into
more than one.
• Web
• Database
– Use RDS to make your life
easier
Web
Instance
Elastic IP
RDS DB
Instance
Amazon
Route 53
User

18. User > 1000:
Next let’s address our
lack of failover and
redundancy issues:
• Elastic Load Balancer
• Another Web instance
– In another Availability Zone
• Enable RDS Multi-AZ
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
Web
Instance
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancer
Amazon
Route 53
User

19. • Create highly scalable applications
• Distribute load across EC2 instances
in multiple availability zones
Feature Details
Available Load balance across instances in multiple
Availability Zones
Health checks Automatically checks health of instances and
takes them in or out of service
Session stickiness Route requests to the same instance
Secure sockets layer Supports SSL offload from web and application
servers with flexible cipher support
Monitoring Publishes metrics to CloudWatch
Elastic Load
Balancer
Elastic Load Balancing

20. Scaling this horizontally
and vertically here will
get us pretty far
( 10s-100s of thousands )

21. User >10ks-100ks:
RDS DB Instance
Active (Multi-AZ)
Availability Zone Availability Zone
RDS DB Instance
Standby (Multi-AZ)
Elastic Load
Balancer
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User

22. This will take us pretty far
honestly, but we care about
performance and efficiency,
so lets clean this up a bit

23. Shift some load around:
Let’s lighten the load on
our web and database
instances:
• Move static content from web
servers to S3 and CloudFront
• Move session/state and DB
caching to ElastiCache or
DynamoDB
Web
Instance
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Elastic Load
Balancer
Amazon S3
Amazon
Cloudfront
Amazon
Route 53
User
ElastiCache
DynamoDB

24. Working with S3 - Amazon Simple Storage Service
• Object based storage for the web
• 11 9s of durability
• Good for things like:
– Static assets ( css, js, images,
videos )
– Backups
– Logs
– Ingest of files for processing
• “Infinitely scalable”
• Serves static content
• Supports fine grained permissions
• Ties in well with CloudFront & EMR
• Logging for S3/CloudFront/Billing
• Supports Encryption (transit/rest)
• Reduced Redundancy 1/3 cheaper
• Glacier for long term storage
• Objects lifecycle configuration
• Automatic partitioning (prefix
choice can maximize throughput)

25. ElastiCache
• Hosted Memcached
– Speaks same protocol as open source memcached
• Scale from one to many nodes
• Self healing ( replaces dead instance )
• Very fast ( single digit ms speeds usually)
• Local to a single AZ
– So need to run different clusters across different Azs
• Data is only in memory, so not persistent
• Use AWS’s Auto Discovery client to simplify clusters
growing and shrinking without affecting your application

26. Auto-Scaling!

27. Sunday Monday Tuesday Wednesday Thursday Friday Saturday
Typical weekly traffic to Amazon.com

28. Sunday Monday Tuesday Wednesday Thursday Friday Saturday
Typical weekly traffic to Amazon.com
Provisioned capacity

29. November traffic to Amazon.com
November

30. November traffic to Amazon.com
Provisioned capacity
November

31. November traffic to Amazon.com
76% waste
24%
Provisioned capacity
November

32. November traffic to Amazon.com
November

33. Decompose into small,
loosely coupled, stateless
building blocks
Prerequisite

34. Having decomposed into
small, loosely coupled,
stateless building blocks
You can now Scale out with ease
Having done that…

35. Having decomposed into
small, loosely coupled,
stateless building blocks
We can also Scale back with ease
Having done that…

36. Trigger auto-scaling
policy
Automatic resizing of compute
clusters based on demand
Feature Details
Control Define minimum and maximum instance pool
sizes and when scaling and cool down occurs.
Integrated to Amazon
CloudWatch
Use metrics gathered by CloudWatch to drive
scaling.
Instance types Run Auto Scaling for On-Demand and Spot
Instances. Compatible with VPC.
as-create-auto-scaling-group MyGroup
--launch-configuration MyConfig
--availability-zones us-east-1a
--min-size 4
--max-size 200
Auto-Scaling
Amazon
CloudWatch

37. Scaling the Database

38. Self-Managed Fully-Managed
Database Server
on Amazon EC2
Your choice of
database running on
Amazon EC2
BringYour Own
License (BYOL)
Amazon
DynamoDB
Managed NoSQL
database service
using SSD storage
Seamless
scalability Zero
administration
Amazon RDS
Microsoft SQL,
Oracle or MySQL as
a managed service
Flexible licensing
BYOL or License
Included
Amazon
Redshift
Massively parallel,
petabyte-scale,
data warehouse
service
Fast, powerful and
easy to scale
Database Options

39. But how do I choose
what DB technology I
need? SQL? NoSQL?

40. For most use-cases SQL is good fit
• Relational DBs: Established and well worn technology
• Lots of existing code, communities, books,
background, tools, skilled people etc
• Flexible query model, data integrity
• Can actually scale - especially for read heavy apps

41. Scaling Relational DBs
• Read Replicas (Master – Slave)
• Replication lag
• Splitting Reads and Writes
– Writes => master
– Reads with tolerance to stale data => read replica (slave)
– Reads with need for most recent data => master
• Master is a SPOF
– Try to decouple / introduce fault tolerance to your application

42. NoSQL data stores
• Distributed systems, can scale up reads but also writes
– Sharding + Replicas
• Compromises: No JOINs, limited querying flexibility vs
Relational
– Denormalize data, schema dictated by app queries
• Eventual consistency vs strong consistency

43. DynamoDB
• Provisioned throughput NoSQL
database
• Fast, predictable performance
• Fully distributed, fault tolerant
architecture
• Considerations for non-uniform
data
Feature Details
Provisioned
throughput
Dial up or down provisioned
read/write capacity.
Predictable
performance
Average single digit millisecond
latencies from SSD-backed
infrastructure.
Strong
consistency
Be sure you are reading the
most up to date values.
Fault tolerant Data replicated across
Availability Zones.
Monitoring Integrated to CloudWatch.
Secure Integrates with AWS Identity
and Access Management (IAM).
Elastic
MapReduce
Integrates with Elastic
MapReduce for complex
analytics on large datasets.

44. Being Agile with
continuous deployment

45. Idea Product
Least friction
Highest quality

46. Idea Product
Shortest time
Highest accuracy

47. Idea Product
Failing fast
when you need
to

48. Idea Product
Product
ProductFreedom to
pivot if you
have to

49. How?
deploy often
…on a platform built for iteration

50. Everything that was a
constrained resource
is now a programmable resource

51. Auto Scaling
Group
V1
Elastic
Load
Balancer
Amazon
Relational
Database Service
(RDS)

52. Auto Scaling
Group
V1
Auto Scaling
Group
V2
Elastic
Load
Balancer
Amazon
Relational
Database Service
(RDS)

53. Auto Scaling
Group
V1
Auto Scaling
Group
V2
Elastic
Load
Balancer
Amazon
Relational
Database Service
(RDS)

54. Auto Scaling
Group
V1
Auto Scaling
Group
V2
Elastic
Load
Balancer
Amazon
Relational
Database Service
(RDS)

55. Auto Scaling
Group
V2
Elastic
Load
Balancer
Amazon
Relational
Database Service
(RDS)

58. Get smart
Achieve a lot even
if team is small

59. Offload undifferentiated
heavy lifting

60. 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
“Undifferentiated Heavy Lifting”
Focus on your core business

61. Relational
Database
Service
DynamoDB
SimpleDB
Databases Middleware Frameworks Analytics
Simple
Queuing
Service
Simple
Notification
Service
Simple
Workflow
Elastic
MapReduce
Simple
Email
Service
CloudSearchElastiCache
CloudWatch

62. User >1mil+:
RDS DB Instance
Active (Multi-AZ)
Availability Zone
Elastic Load
Balancer
RDS DB Instance
Read Replica
RDS DB Instance
Read Replica
Web
Instance
Web
Instance
Web
Instance
Web
Instance
Amazon
Route 53
User
Amazon S3
Amazon
Cloudfront
DynamoDB
Amazon SQS
ElastiCache
Worker
Instance
Worker
Instance
Amazon
CloudWatch
Internal App
Instance
Internal App
Instance
Amazon SES

63. A Summary

64. • Make your application stateless – local
file system only for temp files
• Use Autoscaling in Multiple AZs
• Make use of self scaling services ( ELB,
S3, DynamoDB, SQS, SWF, SES, etc )
• Select data layer based on real needs
• Leverage managed/low touch services

65. What is Cloud Computing
http://aws.amazon.com/what-is-cloud-computing
Architecture Center
http://aws.amazon.com/architecture
Articles
http://aws.amazon.com/articles
Documentation
http://aws.amazon.com/documentation

66. QUESTIONS?