Hi Everyone, I'm working at getting Rails introduced in my company. We're a J2EE shop. Our deployments make use of thee-tiered architecture, just to be clear, that means that there are essentially three machines involved in dealing out an app: a webserver, an application server, and a database server. As I see it (unless I've missed something) Ruby is essentially two-tier: The web/application tier live together on the webserver and then they talk to the database which could conceivably be on another box. One of the primary reasons we use three-tier is for security compliance for some of our customers (well known financial folks). So one thing I need to do is convince my boss that Rails can play nicely in this environment. My thinking is that Rails could live on the application tier and we simply use a first tier webserver to proxy to it. Alternatively, you could simulate the 'J2EE experience' ;-) by setting up two Rails apps. The first-tier app simply makes calls to the middle tier which does all the hard work. Am I thinking through this right? Thoughts? Alternatives? Cheers! Kevin
on 2006-02-17 06:04
on 2006-02-17 06:13
On 2/16/06, Kevin E. <email@example.com> wrote: > The web/application tier live together on the webserver and then they > The first-tier app simply makes calls to the middle tier which does all > the hard work. > Right now you could do this with Apache mod_proxy or Pound: http://www.apsis.ch/pound/ ..but it's going to get much easier and more modular when Mongrel is ready for production use: http://mongrel.rubyforge.org/ In my opinion, though, the difference between two and three-tier systems is minor. Before the enterprise spirits strike me down, what I mean is that routinely things like security proxies (Tivoli Access Manager, eTrust SSO, or home-brew) or load-balancers get bolted to the front of the app, at which point deciding where to put the HTTP server is really just a performance decision.
on 2006-02-17 06:19
I think you could run your webserver on the first tier (web server) and run your fastcgi processes on another box. Otherwise, just use a proxy server there. Nick
on 2006-02-17 07:32
Yeah, switchtower is based on a three tier style. web, app and db. You can run your static file webserver front like lighttpd on one box, remote fcgi's on the app box running your dynamic rails code and the db box with just the db on it. Rails lends itself well to this style. -Ezra On Feb 16, 2006, at 8:16 PM, Nicholas Van W. wrote: > shop. > talk to the database which could conceivably be on another box. > could simulate the 'J2EE experience' ;-) by setting up two Rails > > Nicholas Van W. > _______________________________________________ > Rails mailing list > firstname.lastname@example.org > http://lists.rubyonrails.org/mailman/listinfo/rails -Ezra Z. WebMaster Yakima Herald-Republic Newspaper email@example.com 509-577-7732
on 2006-02-17 12:53
On 17 Feb 2006, at 05:27, Ezra Z. wrote: > Yeah, switchtower is based on a three tier style. web, app and db. > You can run your static file webserver front like lighttpd on one > box, remote fcgi's on the app box running your dynamic rails code > and the db box with just the db on it. Rails lends itself well to > this style. Indeed, in the Agile Rails development book DHH points to a Mortgage processing engine running on rails (www.rapidreporting.com) "The application uses PostgreSQL for the database, lighttpd on the web server and around 10 FastCGIs per application server sitting behind a virtual server with IP tunneling" (in a 10 machine cluster). ---------------------- David S.