Justin.TV seems to have a very interesting startup model. An apparently trivial "outer" application which needs a good deal of innovation "under the covers" to pull off, which is where the real competitive edge comes from. Pulls in a different direction from how most people parse "build what users want".
I wonder how they pitched it to YC (and other investors).
>> I wonder how they pitched it to YC (and other investors).
AFAIK, Justin and a friend took part in the first YC session with a web calendar called Kiko, which they sold on eBay for 5 or 6 figures to a media company after Google came out with theirs. They started working on Justin.tv to have a product in a market which didn't exist at the time, mobile streaming video, to have a better chance of survival.
I believe Justin et al have been working on Justin.tv even before Google purchased YouTube, and are funded by investors closely linked to YCombinator who enjoyed his YCombinator calendar startup.
they didn't pitch it to yc. IIRC their initial project was a web calendar that died when google did theirs. I think most of the current stuff they figured out when Justin did his initial stunt and it just picked up from there.
Bandwidth from a company like Alpha Red works out to about 3 cents/gigabyte if you buy it in 50 megabit per second chunks, or 6 cents/gigabyte if you buy it in 4tb per month chunks.
S3 is 18 cents/gigabyte.
Megabit per second is cheaper if you can keep it at 50% utilization, so baseline bandwidth is actually quite cheap. You'd be crazy to be that bandwidth intensive and pay 18 cents/gig for all your traffic. It adds up quickly.
I'm not saying it qualifies as a CDN - I'm pretty sure it wouldn't - just that it's more complex than simply putting stuff up on S3, and based on the info in the article, the above is my guess as to what they're doing. You don't get 1/4 of a penny per hour of flv by building a worldwide network of servers.
Well, perhaps if you were as big as Google you could. I don't know enough about the economics of scale. But you'd have to be doing some serious volume at the local internet exchanges.
By the way, I was kind of thinking out loud because I'm in the same position:
Bandwidth is averaging above 1mb per person (and growing - the new games are bigger than Stunt Pilot and people play more the more we have), which is probably quite a bit less than justin.tv, but still costly. I definitely won't leave the US for bandwidth, but I'll probably end up with a mixture of baseline servers, gigabyte per month servers and a mirror of static content ready on S3 (as well as a static version of the site), just in case too many of my servers go down at once or we get a massive traffic spike.
Maybe then I'll get a story on TC about how I've created a "CDN", and hey, I wouldn't email them saying remove the story, it's innaccurate. :)
You build your own geographically diverse network. Servers in each country/state/area. You put in very high speed links between each node.
When a user comes to get something from you, you redirect them to the node that is closest to them (Either geographically, or in terms of hops/ping time).
You don't need a server in each country, just "close to your users". Like one on the east coast, one on the west coast, one in Europe, and you don't care about the rest of the world. But I am not sure Justin.tv has that.
But "distributed flash video system" is like 20 characters longer and a lot harder to say than CDN.
It runs partly on EC2, partly on our own servers right now, and relies on the properties of neither.
It's much, much cheaper than buying software from Adobe or Wowza or paying a CDN.