I’ve been using Ylastic for quite some time – it’s a great web-based management tool for the Amazon Web Services.  But, just saw an email this morning from Amazon announcing the beta of their very own web-based management console!

First impressions are that it looks and feels very similar to Ylastic, but straight from the horses mouth (is tha a saying?  i think it is).  Even though I have some level of attachment and commitment to Ylastic, practicality says that I should be using Amazon’s console – especially since it’s free.  The only saving grace right now is that the AWS console supports EC2 – but Amazon promises support for it’s other services coming very soon.

Ouch!  I really hope Ylastic can come up with a way to differentiate itself from Amazon’s offering.  I hate to see when innovative and useful startups get obscured by one of the big boys without an M&A deal going down.

If you have an AWS account, you should be able to access your management console from here: https://console.aws.amazon.com/

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….