Deployment server

Hi all,

On theserverside.com there is an article describing an interview with
Bruce
Tate, where he calls Java dead like Cobol.
See: TheServerSide | Your Java Community discussing server side development

However in the comments, some guy comes up with a good point:

He states the following:

I couldn't come up with a viable enterprise quality/grade deployment platform for RoR. Even in the RoR book, they describe multiple deployment scenerios, lighttpd with FastCGI, apache with mod_ruby or fastCGI where the only two recommended for production. The first is said to be unstable sometimes (these words are directly from the book), and the second is no longer actively supported/developed. So how comfortable would a company feel in deploying their app in an unstable and/or unsupported environment. So until Ruby has a viable platform, commercial and/or open source, which has a lot of traction, money behind it, etc..., it's a huge risk for any corporation to take on.

How do you feel about the RoR deployment platform. Is lighttpd with
fastcgi
realy this unstable?
Will there be commercial vendors for RoR deployment environments. And
how
can we help to get things more stable?

Regards,

Harm de Laat

On 2/17/06, Harm de Laat [email protected] wrote:

How do you feel about the RoR deployment platform. Is lighttpd with fastcgi
realy this unstable?
Will there be commercial vendors for RoR deployment environments. And how
can we help to get things more stable?

Commercial or not, it’s pretty cool to be able to drop a .war file
into the webapps directory in Tomcat (or JBoss for that matter) and
just have it work. Drop in foo.war? Now you can access it at
http://host.domain/foo/*. No configuration required.

I’m looking for every excuse possible to dump Java in favor of Ruby,
but good production app servers is still a big reason to stay with
Java.

– James

On Feb 17, 2006, at 7:42 AM, Harm de Laat wrote:

which has a lot of traction, money behind it, etc…, it’s a huge
Harm de Laat
Lighttpd has come a long way since the book was released. I have
been using it to power a fairly large production site for the
newspaper I work at. It has been pumping out 50-80,000+ page views/
day since last august. It runs on lighttpd/fcgi and has been rock
stable for me.

I am still working on my Rails Deployment book for the pragprogs.

Look for a beta pdf announcement sometime late march early april :wink:

Cheers-
-Ezra Z.
WebMaster
Yakima Herald-Republic Newspaper
[email protected]
509-577-7732

James L. wrote:

just have it work. Drop in foo.war? Now you can access it at
http://host.domain/foo/*. No configuration required.

I’m looking for every excuse possible to dump Java in favor of Ruby,
but good production app servers is still a big reason to stay with
Java.

YES YES YES YES! Rails needs a container! Rails needs a container! Go
Zed, go! We’re
counting on you Zed!! :smiley:

b

Harm de Laat wrote:

How do you feel about the RoR deployment platform. Is lighttpd with fastcgi
realy this unstable?

Not at all. In fact, I’d say it’s very stable in my experience. I’ve got
a
single G5 Xserve currently running 5 lighttpd instances, each listening
on
separate ports, controlling their own set of FastCGI listeners (2-4 for
each
instance) for a production Rails app. Apache, running on ports 80 and
443, acts
as the front-end for all the lighttpd instances. All of the apps run
quite well
and now that I’m getting Switchtower set up, continued deployment is
getting
even easier.

Will there be commercial vendors for RoR deployment environments. And how
can we help to get things more stable?

What things need to be made more stable? Obviously, there’s room to make
things
easier, but I’m not sure just anyone should be deploying
production-level web
applications without some level of Webmaster experience. Just because
you know
how to build a great web application doesn’t mean you know anything
about
hosting that application in a production environment.

Oh… I suppose that means there’s room for a paid service to deploy and
manage
production Rails apps, so it wouldn’t surprise me to see service
providers start
to emerge.

-Brian H., Webmaster
Dartmouth College

On 2/17/06, Kent S. [email protected] wrote:

No configuration is needed only in very simple cases. As soon as you
war application needs access to connection pools, jms queues/topic,
etc, there is as much configuration headaches as anywhere else.

Yes and no. You define things like datasources once for the entire
app server. Then you can use them from each application with a simple
configuration. I’m not trying to ignite a war here, but Java really
does get some things right.

What I meant is that if you start from scratch building a new j2ee
deployment, it will take as much of your time as deployment of a
similar rails solution, if not more. When the installation procedure
is complete and all configuration is in place, yes, you can just drop
your war or ear file and you’re done. On the other hand, if you use
switchtower (which I highly recommend), deployment of new version of
rails application is even easier and more flexible since you can
augment your deployment procedure with your custom logic.

I don’t want a flame war either. With a nice process in place, rails
deployment can be as easy.

Kent

I would “love” a one drop solution to deployment… as at the current
moment, I have gems all over the place, and have no straight-forward way
of
keeping my dependencies in track.
Since not all gems are created equal, even using Geoff’s
freeze_other_gems
rake task doesn’t always work, and I have to do a lot of hand pushing of
files over to /vendor.

No configuration is needed only in very simple cases. As soon as you
war application needs access to connection pools, jms queues/topic,
etc, there is as much configuration headaches as anywhere else.

Kent

I just keep all dependent libraries in my vender directory and they
are all in my repository. So I don’t have to think about it every time
I deploy a new version.

Kent

It’s simply not the same. Why does every conversation about deployment
options for rails
get derailed (har har) into talk of this is more complicated or that is
more complicated?

There is simply nothing in the rails world that works like a servlet
container, much less
an application server.

This is a fatal, deal-breaking, they’re-never-gonna-take-you-seriously
problem.

I’m happy to hear about the deployment successes of Ezra, DHH, and
others. But patching
together a bunch of FastCGI processes is not the same as having a highly
flexible,
long-running container process.

I’m hoping Mongrel will change that. But if you really love rails and
want to champion
it’s cause in the enterprise world, I can’t possibly overstate the
importance of a
web/application container.

b

On 2/17/06, Ben M. [email protected] wrote:

I’m happy to hear about the deployment successes of Ezra, DHH, and others. But patching
together a bunch of FastCGI processes is not the same as having a highly flexible,
long-running container process.

I’m hoping Mongrel will change that. But if you really love rails and want to champion
it’s cause in the enterprise world, I can’t possibly overstate the importance of a
web/application container.

b

Well, I guess I have a different background. I much better prefer to
use fine-grained tools which I can understand in isolation and combine
(or patch as you will) them the way I want it than try to manage or
even comprehend one huge process behemoth.

Kent

There is simply nothing in the rails world that works like a servlet
container, much less an application server.

This is a fatal, deal-breaking, they’re-never-gonna-take-you-seriously
problem.

I know I’m dense (I wake up with it every morning and have grown
accustomed to it after all these years), but I’m not sure I understand
why a servlet container or an application server is necessary to build
a large-scale production (/“enterprise”?) system.

Perhaps the misunderstandings on this topic are a product of saying
“Rails doesn’t have the solution we use in Java therefore it can’t be
solving the problem(s)” without actually going back to “the problem(s)”
to see if there are other ways to solve them and perhaps Rails might be
using other techniques. Just a thought.

It occurs to me because over the years I have seen lots of heavy-load
production systems with strong availability guarantees which aren’t
written in Java. Outside of the Java world I have seen very few
architectures that map onto the servlet model, and not so much the
normal Java “application server” model (though there’s a lot of room for
hair splitting).

It could be that Share Nothing, which wasn’t invented with Rails, is
(done properly) a suitable replacement for whatever name one would apply
to the application server paradigm that people “take […] seriously”.

Rick

http://www.rickbradley.com MUPRN: 336
| States. In a
random email haiku | 46-page decision that became
| public Friday, U.S.

Ben M. wrote:

It’s simply not the same. Why does every conversation about deployment
options for rails get derailed (har har) into talk of this is more
complicated or that is more complicated?

Because deployment of a system like rails can be difficult for people to
get
their heads around. Just because it’s somewhat complex, doesn’t mean
it’s hard.
See my previous message about deployment sometimes requiring Webmaster
experience, not app developer experience.

There is simply nothing in the rails world that works like a servlet
container, much less an application server.

Why would Rails want to work like a servlet container? And as for an
“application server”, that’s a really loaded term. FastCGI is how you
persist
your application code in memory, so that it can quickly respond to HTTP
requests
that are handled by the web tier. The rest of the stuff that would
normally go
in the “application server” is handled by the Rails environment, so why
does
Rails need an “application server”?

This is a fatal, deal-breaking, they’re-never-gonna-take-you-seriously
problem.

All I’m going to say here is please try to speak for yourself. If rails
doesn’t
work for you as a deployment platform, then don’t use it.

I’m happy to hear about the deployment successes of Ezra, DHH, and
others. But patching together a bunch of FastCGI processes is not the
same as having a highly flexible, long-running container process.

One, who said we’re “patching together” anything? Second, until you’ve
done it
yourself, you really can’t comment on whether Rails can be
“highly-flexible and
long-running”, container basis or no.

I’m hoping Mongrel will change that. But if you really love rails and
want to champion it’s cause in the enterprise world, I can’t possibly
overstate the importance of a web/application container.

Maybe I’m missing something, but isn’t that last sentence extremely
close-minded? Clearly a web/application container isn’t the only way to
deploy a
production web application…

-Brian

Well, I will admit that maybe I’m so used to the “java way” that maybe
I’m not giving the
lots of little tools approach enough of a chance. I still don’t think
it’s going to sit
well with shops that are heavily invested in Java and .Net.

See my response to Rick for the other half of this.

b

That’s funny Rick, cuz I feel dense at least once a day every day. :slight_smile:

As in my response on this topic to Kent, I have to admit that there is a
possibility that
my Java experience colors my view of this and I’m attaching more
significance to a servlet
container than necessary. But I really don’t think so.

The very first thing I learned about Java for the web and servlets is
that this concept
was a giant leap forward for web development. Rather than having to
create a process,
execute the request, and the kill and clean up the process for every
request, servlets
gave the web programmer a single, multi-threaded, long-running process
into which she
could hook her applications. It wasn’t too long before they added in
other useful features
like connection pools and the other pieces of the j2ee stack.

But really, the best thing about the container concept is that you have
a single global
memory space for your app. The multiple copies created by the
multi-threading is fairly
transparent to you (you just have to be careful of a few things).

Now, FastCGI addresses the process life-cycle problem, but it does not
give one an
application environment. Maybe the rails folks coming from the
sysadmin/PHP/perl world are
comfortable enough with the OS being their environment. Maybe that’s
just as valid an
application environment. I don’t really see how it can be as portable as
a container
process. I can download tomcat, unzip it, drop my .war into the webapp
folder and start
the server and it just works… on all major platforms… no muss no
fuss.

I’ve also gotten the (possibly incorrect) impression that the current
rails environment
doesn’t allow for static application state to be maintained in memory
indefinitely. This
came up on a thread about the inability to store threads or procs in
sessions. I pointed
out that one could keep the non-serializable stuff in an in-memory hash
and store a
(serializable) string key for that non-serializble object in the
session.

But then I realized that I think – and I still haven’t gotten a
straight answer to this
– one can’t really do that with the FastCGI approach: Having a bunch of
processes running
at the end of a pipe so that you don’t suffer the process life-cycle
pain is all well and
good. But each of those processes is separate… you can’t have a global
in-memory storage
of stuff like my thread map or configuration or cached lookup values or
what have you. Or
can you?

I imagine there’s some way of starting another ruby process that has
this common state and
each fcgi process connects to that process… er, in fact I think that
was Ezra’s
solution: stick your stuff you need in a drb process and have your app
get if from there
when you need it.

I still maintain that it’s not the same. I still think that a lot of
folks in the
Java/.Net world ain’t gonna buy that. I’m surprised that more Java folks
aren’t coming to
my aid here… maybe I’m just a crazy guy ranting to the magazine stand.
Or, I’d be happy
enough if a Java convert told me why they think this isn’t an issue.

It’ll be interesting to see where this is in six months; whether mongrel
has made all us
insecure container-heads happy… whether I’ll just learn the tools that
exist and shut
up… whether this issue will grow as an impediment to rails adoption.

In the meantime, I’ll try to shut up and learn the tools. :slight_smile:

b

PS: I think it interesting to note the volume of “help help, my fastcgi
setup isn’t
working” posts on this list. On all the Java lists I’ve ever been on,
there’s very little
“why doesn’t my tomcat work”? That’s cuz it just does.

Ben… your PS is classic. I remember some unstable versions of Tomcat
that
were deemed “stable”, that involved starting, stopping, then starting
again
to ensure the .war was deployed properly.
We had a group of 20 people, who, each couldn’t get it working correctly
through individual configs.
However, I would still recommend Tomcat over any of the other servers :slight_smile:

Ben M. wrote:

Well, I will admit that maybe I’m so used to the “java way” that maybe
I’m not giving the lots of little tools approach enough of a chance. I
still don’t think it’s going to sit well with shops that are heavily
invested in Java and .Net.

You may be entirely correct about that. But, does it really need to?

If your shop is “heavily invested” in a particular architecture, that’s
probably
where you should stay, unless there is a particular point of pain that’s
started
to prevent work. That’s really a long way of saying “if it ain’t broke,
don’t
fix it.” :slight_smile:

And that’s not, at all, a Rails related thing. There’s plenty of web app
deployment systems that aren’t based around the servlet/container
approach. They
existed before the servlet concept was invented and they continue to
exist after…

-Brian

Brian V. Hughes wrote:

Why would Rails want to work like a servlet container? And as for an
“application server”, that’s a really loaded term. FastCGI is how you
persist your application code in memory, so that it can quickly respond
to HTTP requests that are handled by the web tier. The rest of the stuff
that would normally go in the “application server” is handled by the
Rails environment, so why does Rails need an “application server”?

I don’t want rails to work like a servlet container. I want a servlet
container to run my
rails apps in. Actually, I already have one: webrick. Unfortunately, it
seems the whole
rails world has just shrugged their shoulders at the shortcomings of
webrick and said
“well, it’s good for development”. I’m hoping that my man Zed is gonna
fix that (albeit
with his own separate code-base).

All I’m going to say here is please try to speak for yourself. If rails
doesn’t work for you as a deployment platform, then don’t use it.

Rails isn’t a deployment platform. It’s a “full stack web application
framework”. It’s
great. There are some design choices in Rails that I quibble about, but
they all have
nothing to do with this thread. I’m just pining for a stable, fast,
powerful, flexible
container to run my rails apps in. Once it happens, it will make things
better for
everyone… I’d put money on it.

One, who said we’re “patching together” anything? Second, until you’ve
done it yourself, you really can’t comment on whether Rails can be
“highly-flexible and long-running”, container basis or no.

I keep getting told that we don’t need a container to deploy apps in;
that I can use this
ruby package to do this, or this system tool to do that… that sounds
patched together to
me. I’m also not accusing Rails of not being flexible and long-running,
I’m arguing for
the benefits of having a ruby process in which our rails apps run… the
happy, warm,
comforting environment that has made me the happy Java junkie I am.

And the statement about not having tried something cuts both ways. If
you have done
serious Java development and want to express your opinion as to why the
container concept
simply isn’t needed in the rails world, I’m all ears. I will certainly
be working my way
around to learning all the ins and outs of apache/lighty fcgi
deployment… even if
Mongrel roared into stable full-featured release today. If nothing else,
why would anyone
not welcome more deployment options for our beloved web framework?

I’m hoping Mongrel will change that. But if you really love rails and
want to champion it’s cause in the enterprise world, I can’t possibly
overstate the importance of a web/application container.

Maybe I’m missing something, but isn’t that last sentence extremely
close-minded? Clearly a web/application container isn’t the only way to
deploy a production web application…

Hmm, how is that close-minded? I feel like I’m trying to help the rails
community and I’m
getting tsk-tsked and told “try it… it’s not so bad”. That’s all well
and good, but I’m
stating an opinion that I firmly believe is shared by many in the
Java/.Net world. I might
be wrong, but I’m still going to stand by my opinion until I see
evidence to the contrary.

b

How do you feel about the RoR deployment platform. Is lighttpd with fastcgi
realy this unstable?
Will there be commercial vendors for RoR deployment environments. And how
can we help to get things more stable?

lighttpd has come a long way since the book. We just launched Campfire
on lighttpd and are doing more than 120 requests per second without
lighty breaking a sweat. It’s certainly possible to deploy large-scale
applications on Rails that stay stable. See
http://rubyonrails.org/applications for examples.

David Heinemeier H.
http://www.loudthinking.com – Broadcasting Brain
http://www.basecamphq.com – Online project management
http://www.backpackit.com – Personal information manager
http://www.rubyonrails.com – Web-application framework