Rails - Aug 2006 - Case studies for high-availability Rails deployments?

Hello everyone,

We are developing a new version of a satellite telemetry distribution
system currently in use in the European space industry, and are trying
to convince the client to permit us to use Rails as the platform for
the higher-level layers of the system.

The system as a whole has strict high-availability requirements (our
current track record is over six nines yearly), and in order to push
for Rails adoption we need to demonstrate that Rails, and the
technology stack it runs on, would be capable of meeting these
requirements.

So, I''m in the process of putting together a comprehensive argument for
Rails, and am wondering whether anyone on the list would know of case
studies or references of Rails being successfully deployed in strict
high-availability situations? (Googling didn''t turn up any, and
skimming through the real-world usage references on the Wiki did not
immediately provide useful leads.)

Also, I would appreciate hearing any thoughts and experience on how the
various Rails stacks (FastCGI, SCGI, Mongrel, etc) measure up both
reliability-wise and in situations where there would be a high number
of concurrent, long-lived server push ("Comet") connections open. Are
there any known memory leaks, for instance, that should be taken into
consideration (I seem to recall that at least the FCGI gem has
previously suffered from leaks)?

I will, naturally, summarize my findings in the form of a blog post or
two, for the benefit of the community-at-large.

--
Arto Bendiken | http://www.makalumedia.com/ | http://bendiken.net/


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On Sun, 2006-08-27 at 17:35 +0000, Arto Bendiken wrote:
> Hello everyone,
> 
> We are developing a new version of a satellite telemetry distribution
> system currently in use in the European space industry, and are trying
> to convince the client to permit us to use Rails as the platform for
> the higher-level layers of the system.
> 
> The system as a whole has strict high-availability requirements (our
> current track record is over six nines yearly), and in order to push
> for Rails adoption we need to demonstrate that Rails, and the
> technology stack it runs on, would be capable of meeting these
> requirements.
Hi Arto,

Not to burst your bubble, but very seriously consider and test
alternative platforms.  When I hear "high-available telemetry system for
space industry" I do *not* think of Mongrel or Rails.  I don''t
think of
anything web actually.


-- 
Zed A. Shaw
http://www.zedshaw.com/
http://mongrel.rubyforge.org/
http://www.lingr.com/room/3yXhqKbfPy8 -- Come get help.


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---

On 8/28/06, Zed Shaw <zedshaw-dd7LMGGEL7NBDgjK7y7TUQ@public.gmane.org>
wrote:
>
> Not to burst your bubble, but very seriously consider and test
> alternative platforms.  When I hear "high-available telemetry system
for
> space industry" I do *not* think of Mongrel or Rails.  I
don''t think of
> anything web actually.
Hey Zed,

Not to worry -- despite what it may sound like, we are not talking any
deep voodoo here. This is a high-level, web-based user interface that
controls the lower-level layers of the system (which are based on
entirely different technologies). The legacy version of this web UI is
currently successfully deployed, as it is.

To be more specific, what I''m looking for are simply good arguments
that using Rails instead of, say, Apache + mod_php5 (which would
already be an "approved" technology stack for this project) would not
be unduly detrimental to the uptime expectations of the system as a
whole, and wouldn''t cause any other new headaches.

On one level, this just means that the Rails stack should not crash or
leak memory more than, for instance, Apache with PHP5 does, nor place
undue additional load on the system. Surely we can manage PHP5''s level
of reliability? ;-)

Also, a number of secondary concerns exist that I''ll need to address,
such as the policy for security updates, the expected availability and
support for Ruby & Rails packages on the platform this will run on,
the general availability of developers and sysadmins familiar with
Rails versus more "mainstream" technologies, and so on. Those I have
somewhat mapped out, already.

(There are, of course, provisions for instant hardware failover and
such, but these are outside the current circle of concern.)

In the end, we need to provide justifications for using Rails in the
first place (this, in itself, is not very difficult) and at the same
time try and make an argument that the maturity level of a Rails
stack, a technology not previously used in this industry (AFAIK), is
sufficient to warrant operational deployment.

So, it''s not rocket science, really ;-)

--
Arto Bendiken | http://www.makalumedia.com/ | http://bendiken.net/

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk-unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk
-~----------~----~----~----~------~----~------~--~---