The document discusses PeoplePerHour's migration to AWS and use of various AWS services. It summarizes that PeoplePerHour started with shared hosting in 2007 and gradually scaled up to using AWS services like S3, RDS, and EC2 by 2012 when they fully migrated to AWS. The document highlights how AWS services like RDS, S3, and auto-scaling have provided flexibility, ease of management, and cost savings as PeoplePerHour has grown and experienced traffic spikes. It provides examples of how they have leveraged AWS's flexibility in launching new sites, handling unexpected traffic from media coverage, and scaling up for organic growth.

1. AWS @ PeoplePerHour – Feb 2013
0

2. A short intro…
Simos Kitiris
Co-Founder & CTO
PeoplePerHour
Tom Fotherby
Tech Lead / Dev Ops
PeoplePerHour
1

3. About PeoplePerHour
A bit about PeoplePerHour…
• Site Demo >>
• PPH History >>
2

4. Tech Overview
Team
• Currently 13 Devs
• 3 locations: Greece, UK, Poland
• Multiple staging environments
Tech
• Site built in PHP/MySQL
• iPhone & Android apps
3

5. Infrastructure Evolution
• 2007: Started with shared server
• 2008: Got our 1st dedicated server (yay!)
• 2009–2011: Scaled up to 4-5 servers in Managed Hosting
• Started using a couple of AWS services to solve some growing pains (e.g. S3)
• 2012: Moved fully to AWS (yay!!!)
4

6. Why AWS?
Stellar Pace of Innovation!
• New services/features every week (literally)
• Caters for most infrastructure needs
Flexibility
• Scale up/down on demand
• Pay for what you use – Per Hour ;-)
• Try new approaches!
Reduce time spent on scaling & management
• Allowing us to focus on building our product
5

7. AWS Services we’re currently using
6

8. AWS Services we’re currently using
• DNS: Route53
• Load Balancers: ELB
• App/SOLR Servers: EC2
• Database: Multi-AZ RDS + Slaves
• Cache: ElastiCache
• Assets/Storage: S3
• CDN: CloudFront
• Email sending: SES
• NoSQL: DynamoDB
• Queuing: SQS
• Backups: RDS + S3 + Glacier
• Monitoring: CloudWatch
7

9. AWS Highlights - RDS
RDS (MySQL)
• Main issues with our own (pre-RDS) installation:
• replication was becoming a pain to manage
• we never got a proper Master db failover solution to work properly
• Easy, low maintenance replication: 1-click. Time saver!
• Fault-tolerance: Multi-AZ Standby replica with automatic failover
• Automated Backups: point-in-time restore!
• Scaling: up/down sizing without downtime
• Monitoring: (CloudWatch) e.g. Slave Lag
8

10. RDS – Dump Processing Example
Easy, automated DB dump processing
1. Create live db snapshot
2. Create new RDS instance from snapshot
3. Process/modify data on new RDS instance
4. ‘mysqldump’ from new DB and upload tarball to S3
5. Tidy up – shut down instances and clean old snapshots
9

11. AWS Highlights – S3
S3 – What problems did it solve?
• User uploads (profile images, attachments etc) in the millions started
becoming difficult/time consuming to handle
• Did not want to invest time to figure out the best strategy for scaling
• Wanted to offload our servers from serving/hosting site assets
• Backups were kept in an expensive ‘managed’ solution that was very hard to
access
Why do we like it?
• Cost-effective
• Limitless Space with Zero maintenance!
• Lifecycle policies to move older backups to Glacier
• Seemless integration with Cloudfront (tip: get your cache headers right!)
• What’s not to like??? 
10

12. Recent examples: Flexibility
New site launch – July 2012
• Total site overhaul
• Load/Performance testing stack
• Migration/Launch Rehearsals on parallel stack
• Bigger Instances during launch for quicker migrations
• Increased capacity for PR spikes following the launch
11

13. Recent examples: Flexibility
BBC coverage – Feb 2013
• PPH Featured on BBC BreakFast & BBC News on the same day
• Did not know what traffic levels to anticipate
• Launched extra app servers, db slaves, SOLR slaves + cache
• Launched more servers during broadcast, scaled down a few hours after
• Site held fine with lots of spare capacity! (we got a bit carried away) 
12

14. Recent examples: Flexibility
Organic Growth + Seasonal Variations
• Scaled down to save cost towards the end of 2012
• Much faster growth than anticipated in January (beyond seasonal)
• Ended January 2013 with x2 the traffic of December 2012
• Continuing to grow – nice to know we can easily scale up!
13

15. A few useful tips & best practices
Redundancy
• Use AWS to eliminate single points of failure
• Go multi-AZ on all tiers (if possible)
Automation/orchestration
• Automate with puppet or similar
• Put in place flexible code deployment solution (+ GitHub)
Cost
• Experiment to find the right instance sizes for your needs
• Use reserved instances to save cost
• Implement auto-scaling (if it makes sense)
14

16. Thank you - do ask questions!
Fire away - there are no stupid questions! 
15