Chicago's Museum of Broadcast Communications (MBC) collects, preserves, and presents historic and contemporary radio and television content with the purpose of educating, informing, and entertaining the public through its archives, public programs, screenings, exhibits, publications and online access to its resources.
MBC also runs Museum.tv--which stores and delivers terabytes of digitized radio and television content. Currently, they are featuring a 1984 senatorial debate including Roland Burris--whom you may recognize as the senator just appointed to fill Barack Obama's vacancy (check out the protests at the start of the debate and how the moderator handles it).
Through the years, the primary challenge the not-for-profit MBC faced was the lack of resources to put together a large enough storage infrastructure to handle the massive amount of digital data they had and needed to present. At one point, when their single-server storage setup didn't foot the bill, they had to suspend their online services.
All told, MBC has more than 100,000 hours of content that it needs to store and distribute. Due to its size and lack of structured data, video remains inherently difficult and expensive to store. And let's not get started on reliability and security issues--achieving data reliability and security at the terabyte level using traditional storage methods based on replication requires significant hardware capacity at multiple sites.
When Cleversafe CEO and MBC-member Chris Gladwin heard about this, he contacted MBC to introduce Cleversafe's Dispersed Storage technology that could potentially solve their problems.
Here's how Dispersed Storage works: instead of copying data, Cleversafe divides it into "slices" and disperses it across a secure network to different geographic locations. Each slice contains too little information to be useful, but any threshold of the slices can be used to perfectly re-create the original data. Manageability? Yup. The sum of all the slices is still less than maintaining multiple copies of the original data.
One interesting sidebar to this--in addition to data storage, MBC also relies on Cleversafe for distribution instead of a separate content delivery network (CDN). When users view content on MBC's site, the data is pulled directly from Cleversafe and displayed via a media server in front of the Cleversafe hardware, saving MBC money and physical space without sacrificing performance or scalability for their end users.
I've been experimenting with Amazon's new CloudFront CDN service since the launch and thus far it's proven to be a good option provided you don't need to update content in anywhere near real-time (you are pretty much looking at 24 hours before content updates hit the full network.)
And while the functionality doesn't match something like Akamai, my best math effort suggests that the service will cost you 10% (or less) than Akamai does for static image serving, which makes the service very compelling.
Paul Stamatiou wrote up a great how-to guide for CloudFront and it shows how setting up the new service is still not for the faint of heart. You still need to be a developer/admin type in order to get everything up and running.
The net result:
I'm pretty happy with Amazon's first CDN offering, CloudFront. It's extremely easy to setup and affordable to boot. I was able to get it running from scratch in under 5 minutes, including CNAME DNS propagation. While it might not be mature enough yet with advanced usage reporting for companies to use in place of Akamai, Limelight or CacheFly, it certainly has potential.
Where CloudFront will start to get really interesting is when it can do real-time video at this low cost. Until then it's a nice option to speed delivery but still not a full-blown commercial CDN.
Link: How To: Getting Started with Amazon CloudFront
Link: Amazon Cloudfront vs Cachefly - Performance Benchmark
- prev
- 1
- next





