Amazon EC2

>
> On Sep 6, 2006, at 10:51 AM, Bob Houston wrote:
>
> > Hello,
> >
> > I noticed, this morning, that Amazon reopened their "limited beta"
> > of the Amazon Elastic Compute Cloud service.
> > Has anyone looked into using this services to host seaside
> > applications?
>
> Yes, I think it would be a great platform for that.  That would be an
> interesting iteration on seasidehosting.st: a pre-built linux image
> for EC2 configured to pull a Squeak image and a directory of static
> content out of S3, then start up apache, mod_proxy, and the Squeak VM...
>
> Unfortunately it still seems to be hard to get into the beta.  I
> tried signing up first thing this morning but no luck.
>
> Cheers,
> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

>
> On Sep 6, 2006, at 10:51 AM, Bob Houston wrote:
>
>> Hello,
>>
>> I noticed, this morning, that Amazon reopened their "limited beta"  
>> of the Amazon Elastic Compute Cloud service.
>> Has anyone looked into using this services to host seaside  
>> applications?
>
> Yes, I think it would be a great platform for that.  That would be  
> an interesting iteration on seasidehosting.st: a pre-built linux  
> image for EC2 configured to pull a Squeak image and a directory of  
> static content out of S3, then start up apache, mod_proxy, and the  
> Squeak VM...
>
> Unfortunately it still seems to be hard to get into the beta.  I  
> tried signing up first thing this morning but no luck.
>
> Cheers,
> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside

> Indeed, see the FAQ entry over at http://tinyurl.com/k8knk
>
> "Q: What happens to my data when a system terminates?
>
> The data stored on a specific instance persists only as long as that
> instance is alive. You have several options to persist your data:
>
>    1. Prior to terminating an instance, backup the data to persistent
> storage, either over the Internet, or to Amazon S3.
>    2. Run a redundant set of systems with replication of the data
> between them.
>
> We recommend you should not rely on a single instance to provide
> reliability for your data."

>
> On Sep 6, 2006, at 2:03 PM, Boris Popov wrote:
>
>> Indeed, see the FAQ entry over at http://tinyurl.com/k8knk
>>
>> "Q: What happens to my data when a system terminates?
>>
>> The data stored on a specific instance persists only as long as that
>> instance is alive. You have several options to persist your data:
>>
>>    1. Prior to terminating an instance, backup the data to persistent
>> storage, either over the Internet, or to Amazon S3.
>>    2. Run a redundant set of systems with replication of the data
>> between them.
>>
>> We recommend you should not rely on a single instance to provide
>> reliability for your data."
>
> Sure, so you need to be connecting to some database system hosted  
> elsewhere, or someone needs to build a database which can use S3 as  
> a backend...
>
> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>

> Yes, I agree.   A database hosted elsewhere might be the simplest  
> solution.   Of course, an open-source object DB would be nice to  
> use.  I'm curious if this might be an acceptable use for a GOODS  
> database?  Is the GOODS "replication support" applicable here?  My  
> thought is that we could use GOODS to run a primary server in our  
> EC2 instance, with a replicated server on a real host somewhere.  
> Or perhaps the other way around, with a real host running the  
> primary server?   This way a real host machine will have a current  
> copy of the data, and can be used to "seed" the EC2 instance at  
> startup.  Comments?

>
> 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?
>
> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> --No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.1/440 - Release Date: 9/6/2006
>
>

> On 9/7/06, Jason Johnson <[hidden email]> wrote:
>> My only nit-pick would be that you're being a bit optimistic about the
>> DNS.  Afaik most or all of the ISP's hard code the TTL's to at least 48
>> hours, so whatever you set isn't going to even be looked at.
>
> How do the various dynamic name services work if that's the case?
> These are the services that give you a domain name and you run a
> client program on your machine that notifies their servers that your
> ip has changed. That seems to happen pretty much instantly.
>
> I've just got on the EC2 beta - it's a very interesting service and
> it'll be interesting to see what can be made of it.
>
> Chris.

>
> On Sep 7, 2006, at 5:41 AM, Jason Johnson wrote:
>>
>> Well, to be honest I'm not sure.  But the last time I had to change
>> where my DNS names point
>> to it was 48 hours before I could get to my site by name.  My company
>> always just kept serving the old names until our
>> statistics showed that no one was still using the old name.  I will
>> look into it when I get time, I have wondered what they were
>> doing for a while now. :)
>
> If you run your own DNS server (which was part of the setup I
> described), you can set the expiry to whatever you want... certainly
> setting it to 5 minutes wouldn't be unreasonable (you don't want it
> *too* short or everyone ends up doing way too many DNS lookups).
>
> Avi
> _______________________________________________
> Seaside mailing list
> [hidden email]
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>
>
> --No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.405 / Virus Database: 268.12.1/440 - Release Date: 9/6/2006
>
>