Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Cloud Computing Series - Part II: Picnik Case Study


Published on

WTIA Cloud Computing Series - Part II: Picnik Case Study. Presented by: Mike Harrington, Co-Founder, Picnik.

Published in: Technology, Education
  • Be the first to comment

  • Be the first to like this

Cloud Computing Series - Part II: Picnik Case Study

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