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
--
Posted via http://www.ruby-forum.com/.
On 2/16/06, Kevin Elhart <kelhart@mac.com> wrote:> 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. >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.
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 2/16/06, Kevin Elhart <kelhart@mac.com> wrote:> > 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 > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails >-- Nicholas Van Weerdenburg -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060217/06f03061/attachment.html
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 Weerdenburg wrote:> 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 2/16/06, Kevin Elhart <kelhart@mac.com> wrote: > 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 > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails > > > > -- > Nicholas Van Weerdenburg > _______________________________________________ > Rails mailing list > Rails@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-Ezra Zygmuntowicz WebMaster Yakima Herald-Republic Newspaper ezra@yakima-herald.com 509-577-7732 -------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails/attachments/20060217/65365823/attachment.html
On 17 Feb 2006, at 05:27, Ezra Zygmuntowicz 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 Smalley
Seemingly Similar Threads
- Rails on Sun
- On sharded tiered volume, only first shard of new file goes on hot tier.
- Testing sharding on tiered volume
- Tiered volume performance degrades badly after a volume stop/start or system restart.
- Tiered volume performance degrades badly after a volume stop/start or system restart.