cloud computing series - part ii: picnik case study
DESCRIPTION
WTIA Cloud Computing Series - Part II: Picnik Case Study. Presented by: Mike Harrington, Co-Founder, Picnik.TRANSCRIPT
Picnik and AWSPhoto-editing Awesomeness
March 3rd, 2009
• Founded in late 2005• Based in Seattle• 16 Employees • No VC• Built-in Photo Editor for Flickr, Smugmug• Many API Partners• Flash Based Client • LAMPython Backend• XEN Virtualization• Picnik was already under development
when AWS launched
About Us
• Over 1M daily visits on the weekends, 850k on week days.• 9M monthly uniques• 30M monthly visits• Daily peak traffic 7x daily low• Consistent growth, 1400% increase in YTY visits• Limited Hardware Budget• Limited Rack Space• Small Ops Team
Traffic, a good problem to have
• Picnik stores a lot of temporary files– Flash Security model used to require our Client SWF to proxy through our
servers– Store images in case user accidently closes browser– Store images and changes for rendering saved images
• Picnik has Perfect Memory™!– For Registered and Premium users, Picnik maintains a history of all edits
• Thumbnails• Data Center backups• Started with our own storage, quickly outgrew our capacity• S3 to the rescue
– Local Storage for short lived objects– S3 for long term storage and emergencies
S3? Picnik stores files?
• Picnik’s architecture allowed easy expansion into EC2– Our DC was already virtualized with XEN– Image rendering could easily be moved to EC2
• With EC2 we could easily shift the mix of servers in our DC– 0-100% of our Rendering can be sent to EC2
• Daily peeks are handled transparently– Auto-scaling ramps up our EC2 use when needed
EC2 == Flexibility
• Our Local storage went down for 12 hours, almost no down time as we shifted to S3
• Dev time constraints limited some optimization work with our storage, S3 gave us time (months!) to solve the problem
• EC2 Capacity provided relief for unexpected events (our own bugs, partner hiccups)
AWS – Our Picnik Blankie
