Simon, this is very interesting. How does session management work with the elastic load balancer? For example if you have 3 independent EC2 instances all running the same app?
Also, do you completely trust RDS to make sure your data is never lost? Is there any need for you to have a physical server replicating from RDS? Is there any risk that one day, amazon loses your database and says "Sorry, but we assume you have your own backup"? -Kieran On Jul 27, 2010, at 1:16 PM, Simon wrote: > doing what you've done means you're managing mysql, looking after it, making > sure it doesn't fall over, doing backups, managing replication etc. rds does > all of that for you. it also makes changing the config of your database > server a breeze: need more disk space ? couple of clicks. need more ram ? > couple of clicks. need more compute power behind it ? couple of clicks. need > automatic fail-over to a different availability zone ? couple of clicks. > > re web server resources, remember it's just a normal wo deployment running in > the cloud, so you can do whatever you do now. > > we don't separate the web and app tier - all our ec2 instances run monitor, > wotaskd and apache, and are effectively independent of each other, and we use > an elastic load balancer up front. > > simon > > > On 27 July 2010 17:40, James Cicenia <ja...@jimijon.com> wrote: > So the base image is the actual OS? So you are managing it as the admin? > > I decided to try WOlastic. I configured the instances, setup up mysql with my > users and sync'd the database from existing production to amazon. > So you are suggesting RDS vs. what I just did? What are the benefits of RDS? > Amazon backs up the mysql I created. > > Now I am a bit stumped on WebServerResources. How are you handling that? > > Well, if this works well, I can my webobject apps over and then just sell my > server and drop the colo. > > - James > > On Jul 27, 2010, at 11:28 AM, Simon wrote: > >> 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/kieran_lists%40mac.com > > This email sent to kieran_li...@mac.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
