Brit Gardner’s Site

all the code that’s fit to printf()

Just received this email from Amazon Web Services announcing that they are working on building a true Content Delivery Network!  It’s light on details, but I can see this having a huge effect on services that are using AWS and S3 for video delivery.

Many of you have asked us to let you know ahead of time about features and services that are currently under development so that you can better plan for how that functionality might integrate with your applications. To that end, we are excited to share some early details with you about a new offering we have under development here at AWS — a content delivery service.

This new service will provide you a high performance method of distributing content to end users, giving your customers low latency and high data transfer rates when they access your objects. The initial release will help developers and businesses who need to deliver popular, publicly readable content over HTTP connections. Our goal is to create a content delivery service that:

 

• Lets developers and businesses get started easily - there are no minimum fees and no commitments. You will only pay for what you actually use.
• Is simple and easy to use - a single, simple API call is all that is needed to get started delivering your content.
• Works seamlessly with Amazon S3 - this gives you durable storage for the original, definitive versions of your files while making the content delivery service easier to use.
• Has a global presence - we use a global network of edge locations on three continents to deliver your content from the most appropriate location.

 

You’ll start by storing the original version of your objects in Amazon S3, making sure they are publicly readable. Then, you’ll make a simple API call to register your bucket with the new content delivery service. This API call will return a new domain name for you to include in your web pages or application. When clients request an object using this domain name, they will be automatically routed to the nearest edge location for high performance delivery of your content. It’s that simple.

We’re currently working with a small group of private beta customers, and expect to have this service widely available before the end of the year. If you’d like to be notified when we launch, please let us know by clicking here.

Sincerely,

The Amazon Web Services Team

I call this my erlang playground instance.  Here’s what’s installed:

1. Ubuntu Server Hardy 8.0.4
2. Apache 2 listening to port 80
3. Erlang R12B-3
4. CouchDB 0.8 listening to port 5984
5. Yaws v1.76 listening to port 8080
6. MochiWeb Library

The instance ID is ami-12ae4a7b and I’ve made it public so feel free to use it to your hearts content!

I plan to add to this instance whenever I find time.  I definitely want to get SSL socket communication going using this tutorial.  I’m also interested in Kevin’s virtuerl project over a hypotheticalabs for quick and easy VM management because the whole reason I’m going through the trouble of doing this on EC2 is I think development on any erlang system should start and end with multiple physical machines.

Don MacAskill gives a really interesting bird’s eye view into how their service at Smug Mug is set up.  If you’re not familiar with SmugMug, it’s a for-pay image hosting site that’s profitable in a Flickr world so they must be doing something right, right?

I find his post especially interesting because I think the multiplayer gaming infrastructure of the future is going to be on these Cloud-type services.  Not just static data like Valve’s new Steam Cloud, but dynamic real-time multiplayer services that you can “just throw another box to” to handle load peaks, etc.

Their approach to “worker” instances I like a lot - they are completely stupid when they are born, but once started they execute a small script that fetches their intelligence.  Brilliant!  Updating your core software is dead simple - update it once on your mother ship, and all your worker instances will be up to date automatically when they are born.

This is in contrast to packaging your machine instance with all the necessary software to start work immediately, which limits you to the role that you’ve packaged it for.  Also, you don’t have to create and test new AMIs every time you want to update… have you ever made one of these things? - it’s hard! On a scale of one to ten I would rather take a fork in the eye than create, upload them and test a new instance.

The workers in the system Don outlines are isolated and receive their intelligence and work from a central server, but what if you were to take the advantages of an Erlang based system - immediate awareness, concurrancy - and throw it into the equation?  Veeeery Interesting….