Right now, neither of them are. With that much runway, the goal is likely to drive traffic, get a large user base, then find a path to monetization. Maybe Pinterest will succeed, maybe it won't. It's growing and a rapid growth, and they may become a very successful company. or not. That's why they call it "Venture Capital".
The Swamweir site is mildly shameful, but at the same time, all they've done is copy the functionaly and look and feel. If they're always imitating, Pinterest should be able to out-maneuver them, grow faster, and learn how to monetize quickly.
This was a really quick build using Rails and jquery. We're using Foursquare & Google places APIs, as well as our own set of "cool attractions". We use the Google directions API for routes & mapping.
We wanted to be able to serve arbitrary sizes so we can handle different demands for thumbnails and new use cases. Having to resize all of your images because you've re-designed your homepage sucks, and is no fun (especially if you have a large set of images).
Cloudfront is really enticing, though. For a cheap CDN, if we really had the need, we'd probably migrate to cloudfront, then come up with a task to batch resize our S3 images, then stick them back into S3. This could probably be done on a one-off task on ec2 by spinning up a few instances, or even with Hadoop.
If anyone's taken this approach, I'd love to see it!
I could see where that would be useful. Image uploads in our case are actually handled by our existing web app, so our image servers can be ignorant of user authentication/etc. We end up using swfupload, which is a nice client experience, and then in the callback we call directly into our image servers. Since it's an ajax experience, it's pretty nice, but if we had very large images, or if we had to pre-process out a number of different sizes/etc I could see where kicking off an async job would be useful.
It would be really cool to have an EC2 instance handle these
resizes and put the images in new buckets for you - Might be a really neat implementation.
1. Good point - I didn't bring this up in the article. When we store the images locally, we create divide end of the unique ID of the image into two levels of subdirectories. This gives us "random enough" distribution in subdirectories, and an easy way to look up the files on disk. This logic exists in our rails app, but we didn't want to expose this pathing out to end users. This allows us to change it later if we need to create further subdirectories.
2. Good tip - we try to use our judgement here balancing good design/good performance. We tend to opt for a pretty website first, then go back and make it faster with optimization.
http://aws.amazon.com/s3/#protecting
I am totally okay with 99.999999999% durability. This is way better than I'll be able to build/afford on my own.
In case of an epic S3 disaster, we could backup our S3 buckets to another offsite storage, but we're not going to improve much further than what their giving us.
Dragonfly looks pretty cool. I like the approach of using rack (our app was written pre-rack, but it's been upgraded to newer versions of rails, so we could make it rack-enabled).
Have people written different datastores (like S3?). I love the idea of a modular, pluggable image server that can choose different backends based on business need/scaling.
Luckily, we deal with pretty small pictures since they are just pictures of our users & their classes. We don't really have any need for handling larger sizes, and our biggest use cases surround generating thumbnails (similar to many social networking web apps).
True, there is guarantee. But it's a pretty good track record - and the underline technology holds up pretty well. It's more reliable than what we'd be able to build with a small startup budget (or pay for offsite backups/storage).
