Is anyone using Ruby for 24/7 financial applications?

Ruby
1

I know a lot of people are using ruby on rails for web apps, usually
with
Apache as the underlying app, but I don’t know of anyone using ruby
itself
for a 24/7 application. Yes, some people are using webrick as their web
server but they don’t necessarily lose $$$ if their personal web site
goes
down.

I’m trying to talk my company into using ruby in a remote environment (a
merchant’s store) where it has to be solidly up 24/7 or the merchant
will
stop using our product. We should be able to SSH to the box if we need
to
but we’d rather not need to. While I have confidence that ruby can run
in
that environment, management would like to hear that someone else is
already
using it for a similar purpose. Are they?

thanks,
JB

BTW: if this is the wrong mailing list to send this to, please let me
know -
my first post and all that…

2

John B. wrote:

stop using our product. We should be able to SSH to the box if we
need to
but we’d rather not need to. While I have confidence that ruby can
run in
that environment, management would like to hear that someone else is
already
using it for a similar purpose. Are they?
What part of Ruby needs to be up 24/7? Webrick? Or is it just a ruby
script that needs to run correctly all the time?

I don’t work in Finance, but I have dozens of Ruby scripts, and apps
that run at my company throughout the day.

Speaking of webrick, I have a small client/server Windows-gui database
app written completely in ruby and ruby-gtk (everything is written in
ruby: gui-frontend, backend logic, even the dbms) and, except for about
5 minutes of scheduled downtime every morning to compress the database,
it runs 24/7 and has been for several months. It uses webrick for it’s
client-server communications.

HTH,

Jamey C.

3

On 10/18/06, John B. [email protected] wrote:

I’m trying to talk my company into using ruby in a remote environment (a
merchant’s store) where it has to be solidly up 24/7 or the merchant will
stop using our product. We should be able to SSH to the box if we need to
but we’d rather not need to. While I have confidence that ruby can run in
that environment, management would like to hear that someone else is already
using it for a similar purpose. Are they?

We run a number of scheduled scripts and usually only fail due to
external problems. But any sort of mission critical software needs
some serious analysis of the particular situation. It’s not something
that is simply a ‘yes it is suitable’ or ‘no it is not’ question.

I think that people will be able to certainly share some useful info
if you give a bit of background on what specific tasks you’ll be
dealing with.

4

Jamey C. wrote:

morning to compress the database, it runs 24/7 and has been for
several months. It uses webrick for it’s client-server communications.
Oops, meant to say it uses Drb for it’s client-server communications.

5

On 10/19/06, John B. [email protected] wrote:

I’m trying to talk my company into using ruby in a remote environment (a
merchant’s store) where it has to be solidly up 24/7 or the merchant will
stop using our product. We should be able to SSH to the box if we need to
but we’d rather not need to. While I have confidence that ruby can run in
that environment, management would like to hear that someone else is already
using it for a similar purpose. Are they?

Well, we are using Ruby itself at the core of several
mission-critical applications that must be up 24x7x365 and so far it
hasn’t really failed us. The only problems we have encountered are
scalability concerns with particular applications that are
CPU-intensive (some careful coding of C extensions helped with that),
but then if your application is of that sort then you wouldn’t use
Ruby for that (yet).

6

On Thu, 19 Oct 2006, John B. wrote:

that environment, management would like to hear that someone else is already
using it for a similar purpose. Are they?

I am.

The other day I restarted the IOWA process for a web site that had been
running 270 days without a problem. I only had to restart it because of
something dumb that I did.

On various servers I have a bunch of mutual fund sites, many of whom are
very tense about even miniscule downtimes. I have processes that act as
middlemen, transfering information between a fund distributor and a
fund.
I have systems involved in business communications, data tracking and
reporting, and a custom data storage and mining app that combines a
destop
utility, a daemon to receive data from the desktop utility, an engine to
facilitate automatic OCR scanning of uploaded images, and a web
interface
(none of which relies on Apache for anything more than a proxy that does
a
decent job of serving static content, too).

I don’t have downtime that is Ruby related. I just don’t. I’ve been
using Ruby for sites, apps, and software processes in production
environments, for businesses, since spring of 2002.

Kirk H.

7

[email protected] wrote:

I am.

The other day I restarted the IOWA process for a web site that had been
running 270 days without a problem. I only had to restart it because of
something dumb that I did.

I can’t remember the last time I went 270 days without doing something
dumb. :slight_smile:

I don’t have downtime that is Ruby related. I just don’t. I’ve been
using Ruby for sites, apps, and software processes in production
environments, for businesses, since spring of 2002.

That is wonderful to hear! Just out of curiosity, how did you discover
Ruby and what led you to become an “early adopter?”

8

On 10/18/06, John B. [email protected] wrote:

I know a lot of people are using ruby on rails for web apps, usually with
Apache as the underlying app, but I don’t know of anyone using ruby itself
for a 24/7 application. Yes, some people are using webrick as their web
server but they don’t necessarily lose $$$ if their personal web site goes
down.

The first Ruby program I ever wrote was a pure-Ruby RADIUS
authentication
server. I wrote it the same day I learned Ruby.This was over three years
ago. It’s still in production now, on multiple sites. It’s been
rock-solid
and stable from Day 1. The code has not changed in all that time except
to
add new features.

9

On Fri, 20 Oct 2006, Francis C. wrote:

ago. It’s still in production now, on multiple sites. It’s been rock-solid
and stable from Day 1. The code has not changed in all that time except to
add new features.

here you confirm something i’ve long asserted, but few people seem to
beleive:
‘old’ peices of code still sitting at version 0.0.0 are likely to be
quite
stable. they are like sharks: evolution got it right the first time.

cheers.

-a

10

On Thu, 19 Oct 2006, M. Edward (Ed) Borasky wrote:

[email protected] wrote:

I am.

The other day I restarted the IOWA process for a web site that had been
running 270 days without a problem. I only had to restart it because of
something dumb that I did.

I can’t remember the last time I went 270 days without doing something
dumb. :slight_smile:

Fortunately, most of the time I can completely ignore the app server
processes. I have some just-in-case monitoring of them, and I spot
check
some of them every day, but they only get restarted, generally, because
I’ve changed something that won’t get autoreloaded or I just feel that
hard to shake paranoia about processes that have been running for months
on end.

That is wonderful to hear! Just out of curiosity, how did you discover
Ruby and what led you to become an “early adopter?”

Well, I was sitting in the resturant of a hotel in Golden, Colorado,
reading a magazine. I can’t recall if it was a Linux magazing with an
article in it by one of the big Perl guys of the time, or whether it was
in fact a Perl magazine, but either way, there was an article in it, by
a
Perl guy, about Ruby. I loved what I saw. So, in my free time I
started
playing with it, recoding pieces of my Perl code (I’d been a hardcore
Perl
user for a long time) into Ruby and comparing.

I loved it. Almost everything that I wrote ended up being both shorter
and easier to read, and I was a Perl guy who tried really hard for easy
to
read code (I even went so far as to implement an exception handling lib
in
Perl that wrapped almost all of the Perl builtins), so that made an
impression. Around this same time I stumbled across the nascent IOWA
implementation, by Avi Bryant. I had, in the past, implemented more
than
one MVC framework for Perl in an attempt to improve on what was
available
in that world, and I loved the concepts that I was seeing with IOWA. It
was completely a proof of concept, though, that was impossible to use
for
an production usage.

Then, a couple things happened. I got laid off from my job, and through
a
friend, I picked up a contract to implement a resume posting, job
hunting
web site for the Milwaukee Chamber of Commerce, for college students to
hunt for internships, and companies to hunt for interns. The wrinkle
was
that I only had about two weeks to implement the whole thing. What to
do?

The safe route would have been to do it in Perl. I’d been doing Perl
forever, and knew well the world of web devel with Perl. After playing
with Ruby so much, though, the thought made me cringe. So I hunted for
Ruby options. About the only things for web development at the time
were
the CGI library or the Cerise framework. Or IOWA, if it could be made
into something a person could practically use.

I did the stupid thing. I picked Ruby and IOWA. I hacked IOWA until I
had a workable solution, and built the site. It was done with all of
the
features they requested, on time. It ran without a problem for two
years
until they discontinued their program. And I was hooked. Ruby was
great.
IOWA was great. Web devel was never so fast or easy, and the code was
easy to read and maintain. I’ve used Ruby for everything I could since.

Kirk H.

11

On 10/18/06, John B. [email protected] wrote:

that environment, management would like to hear that someone else is already
using it for a similar purpose. Are they?

The Ruby itself is very stable. I have several web applications that
run for months without restarting. But also I’d like to note that no
programming language can guarantee 24/7 uptime for your application.
You still have to implement the high-availability solution which would
require the hardware and network redundancy. I have a very positive
experience with projects such as Linux HA and Wakamole that greatly
simplify the implementation of high-availability solution.

12

On Fri, 20 Oct 2006, Kent S. wrote:

The Ruby itself is very stable. I have several web applications that
run for months without restarting. But also I’d like to note that no
programming language can guarantee 24/7 uptime for your application.
You still have to implement the high-availability solution which would
require the hardware and network redundancy. I have a very positive
experience with projects such as Linux HA and Wakamole that greatly
simplify the implementation of high-availability solution.

linux-ha is amazing isn’t it? have you made use of the drb sub project
too?
(that’s distributed block - not ruby’s drb).

-a

13

On 10/19/06, [email protected] [email protected] wrote:

here you confirm something i’ve long asserted, but few people seem to
beleive:
‘old’ peices of code still sitting at version 0.0.0 are likely to be quite
stable. they are like sharks: evolution got it right the first time.

The stream runs clearest near the source (if you’ll pardon the pun). I
believe that the vast majority of errors in well-designed and
well-written
programs are regressions.

Going back to the OP: the only downtime-causing Ruby error I ever saw in
a
critical production system was caused by a memory-eating bug in REXML
that
got fixed somewhere in the neighborhood of version 1.8.4.

14

management would like to hear that someone else is already
using it for a similar purpose.

Greetings.

If I was a manager trying who would consider your suggestion I too would
be concerned with stability, as your managers obviously are.

But also I would be concerned with correctness. “Is this unknown ruby
thing crunching the numbers correctly?”. I’ll try to answer that
question
through my experience in financial apps.

Background

Although not a 24/7 service, at Mercer I build and maintain multiple
mission-critical financial applications in Ruby. We roll about 10e6 USD
through this suite on a yearly basis, which is quite a lot considering
in
our market.

Clearly, the financials must be computed correctly.

Among the reasons Ruby was accepted were:

  • development speed. Solve this problem sooner rather than later. The
    c#-alternative would easily have doubled development time.

  • less code => fewer bugs. I showed how to write something i C#, then
    showed the same in Ruby. I can’t give you the example, but it
    concerned text-munging and enumerables among others. Both examples
    were readable, no golfing, but the difference was substantial.

  • unit testing. My managers were not up to speed on unit-testing. I
    showed them how in both ruby and c#, and they loved it. This gave
    them
    the assurance that the program would calculate correctly also when
    implemented in Ruby. It’s strange, you never really have to prove
    this
    when using C#/Java/…, correctness is somehow assumed to be an
    implicit feature of compilation. Any developer knows this is not
    true,
    but it’s not the developer we are convincing, it’s the manager. And
    the manager, understandably, want’s to cover the uncertainties.

To sum up, dev-speed and program quality were the winners. Hopefully
they
can persuade also your managers.

Good luck.

15

On Fri, 20 Oct 2006 00:13:49 +0900, khaines wrote:

I did the stupid thing. I picked Ruby and IOWA. I hacked IOWA until I
had a workable solution, and built the site.

… and Kirk does an awesome job of improving IOWA ever since.

I have several (quite simple, non-critical, low-volume) IOWA web-apps
running without problems as long as the underlying hardware holds out.

And if speed is your concern, go ahead and compare whatever you want
to IOWA/mongrel or IOWA/EventMachine … blazingly fast.

s.

16

[email protected] writes:

The first Ruby program I ever wrote was a pure-Ruby RADIUS authentication
server. I wrote it the same day I learned Ruby.This was over three years
ago. It’s still in production now, on multiple sites. It’s been rock-solid
and stable from Day 1. The code has not changed in all that time except to
add new features.

here you confirm something i’ve long asserted, but few people seem to beleive:
‘old’ peices of code still sitting at version 0.0.0 are likely to be quite
stable. they are like sharks: evolution got it right the first time.

And the old code looks so dangerous you don’t dare to touch it,
because it will bite you… :wink:

17

[email protected] schrieb:

On Thu, 19 Oct 2006, M. Edward (Ed) Borasky wrote:

…

easy to read and maintain. I’ve used Ruby for everything I could since.

Kirk H.

very interesting post, and thanks for the endorsement. :wink:

-klaus

18

Where I work I have about a dozen Ruby scripts running as scheduled
jobs that interface with the accounting/finance environment. The only
reason I’ve ever had to restart the jobs is due to a server
configuration spec I needed to update in the scripts. Other than that,
rock solid. The only thing I’ve noticed (likely due to coding
incompetence on my part) is I have some syslog monitoring scripts that
over time consume lots of RAM. After a couple of weeks I see that they
are getting a bit out of hand. But nothing leading to downtime, host
resource issues, etc.

So far I have been able to leverage Ruby to offer a GUI employee survey
app, a Rails order management app, a mobile CRM app, and tons of admin
scripts that make my job so much easier. Since that’s the primary
language here there is some consistency and standardization.

19

RapidReporting.com is a servise used by 80% of the top 1000 morgage
underwriters it is a rails app

20

On 10/19/06, John B. [email protected] wrote:

I know a lot of people are using ruby on rails for web apps, usually with
Apache as the underlying app, but I don’t know of anyone using ruby itself
for a 24/7 application. Yes, some people are using webrick as their web
server but they don’t necessarily lose $$$ if their personal web site goes
down.

I wrote several applications using Rails that are not web apps per se.
Rails is mostly used as a back end permitting rapid prototyping /
development and very quick domain modeling leveraging ActiveRecord
especially.

a) Check bank balance via SMS

User sends an SMS to a number attached to a GSM modem. Uses smstools
to retrieve the message, and execute a Ruby shell script that parses
the message and builds an HTTP GET request to transmit that
information to the Rails application. The application then does a
telnet into a legacy banking application (Temenos Globus, running on a
variant of the Pick database system called UniVerse) and does screen
scraping and such to login, query the balance and parse the results.
Once the information is retrieved, it uses a web based sms service to
transmit the results back to the user. Functionality to request new
cheque books, to retrieve the last N transactions on the account etc
also included. Also uses drb to move some of the lengthy operations
offline (such as transmitting the sms back).

b) Check bank balance via touch tone telephone

User dials a number which is handled by the Asterisk PBX software.
Uses voice synthesis software (Loquendo TTS engine, high quality
voices) to issue the voice prompts and to deliver the results in voice
format. Uses RAGI (ruby asterisk gateway interface) to handle the
incoming calls and to orchestrate the transaction. Uses
Rails/ActiveRecord as above, same infrastructure, different interface.

c) User verification via telephone call back

User initiates a transaction via web or via SMS and the system calls
the user back and asks him/her to authenticate using a PIN. Works only
from a mobile phone registered to the system and associated with that
user to achieve two factor authentication (what you have + what you
know). Built with RAGI + Rails + Asterisk.

d) Back end for point of sale handheld device applications

Merchant uses a GSM handheld point of sale device to perform various
transactions such as selling mobile topups, internet access (prepaid),
school fee payment etc. UI is on the point of sale device, fulfillment
/ business logic is handled remotely with a rails application. HTTP
GET is used to transmit parameters to the back end and the document
returned is a parseable response (JSON encoded). Secured by using
HTTPS, possible to use HTTPS certificates to ensure that each device
is uniquely identifiable and that a particular device can be disabled
remotely in case of fraud etc. POS application written in Lua / C.
GPRS / SMS message used as the network (data transmission) layer.

I’m trying to talk my company into using ruby in a remote environment (a
merchant’s store) where it has to be solidly up 24/7 or the merchant will
stop using our product. We should be able to SSH to the box if we need to
but we’d rather not need to. While I have confidence that ruby can run in
that environment, management would like to hear that someone else is already
using it for a similar purpose. Are they?

Rails has been very, very stable for this purpose. Ran into a few
problems only using native extension written in C such as Ferret which
caused some crashes. Other problems came not from Ruby but from
interfacing with the external systems, such as having a server running
the banking software restarting, or hanging, and having to recover
from that situation. The best solution was to queue up messages in a
database table, and flag / purge them depending on whether they failed
or succeeded. A background or intermittent task then processes failed
attempts and informs the user if necessary.

I recommend sticking to pure Ruby if you want to have stability. Some
problems are with the Ruby application server going down (such as
Mongrel) but can be solved with some effort / luck / catching
exceptions properly, or using lighttpd and scripts to monitor or
restart the application when necessary.

Combined with capistrano for management of the remote applications,
SSH works very well for deploying / management and very much automated
with capistrano. With stability, you’ll need to go through a test
period where you can shake out the little bugs that are inevitable.

– G.