Three-tier


#1

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’ :wink: 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

#2

On 2/16/06, Kevin E. removed_email_address@domain.invalid 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.


#3

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


#4

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’ :wink: by setting up two Rails

Nicholas Van W.


Rails mailing list
removed_email_address@domain.invalid
http://lists.rubyonrails.org/mailman/listinfo/rails

-Ezra Z.
WebMaster
Yakima Herald-Republic Newspaper
removed_email_address@domain.invalid
509-577-7732


#5

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.