rolling your own is surprisingly easy if you start with a base image. we started out with a vanilla centos image from rightscale, and have built it up into what we needed from there. you can then create an ebs-backed ami in a couple of clicks.
re pricing, it all depends on what you need. our financial models tell us for our deployment is excellent value for money, and we can scale well beyond our current needs and it remains as such. use the cost aws calculator to figure out your own costs, and remember to factor in staff costs in your decision making process. those DBA's are darn expensive compared to RDS :-) http://calculator.s3.amazonaws.com/calc5.html the only performance issue we found is that it is basically impossible to host your DB outside of amazon due to latency. but you don't have to use RDS - if you like sticking needles in your eyes you can just run and look after your own mysql / postgre / mssql / whatever on an ec2 instance. the general performance of our apps has also vastly improved. a mixture of using more computing power and amazon having much faster internet transit than we were paying for in our previous co-lo. alongside production we also run our staging servers and our hudson build server on ec2. in productivity terms running hudson there was a huge leap forward: previously a new build would take around 30 minutes to upload to staging / production. now it takes 19 seconds flat :-) we're shortly going to move our subversion repository to ec2 as well. Simon On 27 July 2010 15:13, James Cicenia <ja...@jimijon.com> wrote: > This is very cool. > > I need to move one of my servers, or, use the cloud approach for its > WOApps. I see you rolled your own but wolastic seems like it is for a mere > mortal. > > Anyone use wolastic? What is the pricing your are seeing? Issues? > Performances? Etc. > > Thanks. > James Cicenia > > > > On Jul 26, 2010, at 3:55 PM, Simon wrote: > > we don't use the wolastic images (we have our own) but we do deploy > entirely on the amazon ec2 cloud now. ec2 instances running standard > javamonitor / wotaskd, amazon RDS for database server, s3 for file storage > etc. scalability on demand, load balancing, redundancy across multiple > availability zones. it's the best thing since sliced bread... > > our staging servers (also on ec2) run wonders javamonitor / wotasd and > hence we'll probably upgrade our production servers to those soon. > > simon > > On 26 July 2010 21:36, Ramsey Gurley <ram...@xeotech.com> wrote: > >> I haven't tried it yet, but WOlastic looks like a *really* cool deployment >> solution for WO. >> >> http://wolastic.com/ >> >> Ramsey >> >> >> On Jul 26, 2010, at 4:27 PM, Ken Anderson wrote: >> >> Thanks for the thoughts guys! >>> >>> Ken >>> >>> On Jul 26, 2010, at 1:42 PM, Pascal Robert wrote: >>> >>> >>>> Le 2010-07-26 à 12:55, Chuck Hill a écrit : >>>> >>>> On Jul 26, 2010, at 9:44 AM, Ken Anderson wrote: >>>>> >>>>> I've been asked to comment on the best way to deploy WebObjects today >>>>>> without any "imposed" restrictions. I haven't done any new deployments >>>>>> in a >>>>>> long while, so I'm likely not up to date on the last. What are people >>>>>> using >>>>>> today, and why do they think it's the best? >>>>>> >>>>>> Thanks much! >>>>>> Ken >>>>>> >>>>> >>>>> Lacking imposed restrictions (e.g. must run in J2EE container), >>>>> traditional WO deployment through Apache with mod_webobjects is probably >>>>> the >>>>> way to go. Anjo was working on mod_proxy deployment, but I don't recall >>>>> how >>>>> far he got or if he has this in production. It looked promising. There >>>>> is >>>>> also a Fast CGI adaptor and Ravi is working on something for WOWODC. >>>>> >>>> >>>> I'm adding some mods in JavaMonitor too (for WOWODC) and Andrew Lindesay >>>> also have stuff in LEWOStuff to use mod_proxy_ajp. >>>> >>>> >>>> >>>> ---- >>>> Pascal Robert >>>> prob...@macti.ca >>>> >>>> AIM: MacTICanada >>>> Twitter : MacTICanada >>>> LinkedIn : http://www.linkedin.com/in/macti >>>> WO Community profile : http://wocommunity.org/page/member?name=probert >>>> >>>> >>> _______________________________________________ >>> Do not post admin requests to the list. They will be ignored. >>> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >>> Help/Unsubscribe/Update your Subscription: >>> >>> http://lists.apple.com/mailman/options/webobjects-dev/ramsey%40xeotech.com >>> >>> This email sent to ram...@xeotech.com >>> >>> >> _______________________________________________ >> Do not post admin requests to the list. They will be ignored. >> Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) >> Help/Unsubscribe/Update your Subscription: >> >> http://lists.apple.com/mailman/options/webobjects-dev/simon%40potwells.co.uk >> >> This email sent to si...@potwells.co.uk >> > > _______________________________________________ > Do not post admin requests to the list. They will be ignored. > Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) > Help/Unsubscribe/Update your Subscription: > http://lists.apple.com/mailman/options/webobjects-dev/james%40jimijon.com > > This email sent to ja...@jimijon.com > > >
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list (Webobjects-dev@lists.apple.com) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
