[Seaside] Amazon EC2

Avi Bryant avi.bryant at gmail.com
Wed Sep 6 19:09:48 UTC 2006

On Sep 6, 2006, at 11:57 AM, Darius Clarke wrote:

> I really like the idea as well.
> Creating a production application w/o a fixed IP address hosted on
> their service would be the tricky part.

Yes.  So, say you had a server named control.seaside.st, with a fixed  
IP, and DNS and Apache + mod_proxy installed.  Say the domain name of  
your production app was myapp.seaside.st, and control.seaside.st was  
the authority for that domain.  To begin with, the myapp domain would  
be pointed to control.seaside.st itself.  The first time a request  
for myapp came in, control would provision an EC2 instance (from a  
waiting pool) with the myapp image.  It would then modify its DNS to  
point myapp to that new EC2 instance, and proxy the request through.   
While the DNS change propagated out (you could have a short TTL), it  
would have to continue to proxy those requests, but eventually  
everyone would be hitting the EC2 instance directly.

When you want to decommission myapp from that EC2 instance, you do  
the same thing in reverse: you switch the DNS back to control, and  
the EC2 instance has to stay up for a few minutes until the TTL is  
over and everyone's cache is updated.

This is a little complex, but has two advantages over the current  
seasidehosting.st setup:

1. There are no capacity problems - if it becomes wildly popular, it  
just means the EC2 bills go up a bit.
2. We get perfect sandboxing, rather than requiring a modified VM:  
each app is running in a separate virtual server so you can let  
people do whatever they want.

Thoughts, refinements?


More information about the Seaside mailing list