Rails and Enterprise Applications

Hi Everyone:

My company is looking to migrate one of their enterprise-class
products to Ruby on Rails, and there are some questions from the
highest levels of management about what we're doing.

So, my question to the group is, has anyone migrated existing
enterprise-class applications to Ruby on Rails? If so, what was their
experience like? What questions did C-level management have? How
were they answered? What compromises had to be made?

Thanks in advance for your thoughts.

- Jeff Sutherland

Generally you'll find that once you migrate to Rails, your code will
be a lot simpler, easier to maintain, and allow for more rapid
changes. However it's trivial to put the enterpriseyness back into
your app with http://agilewebdevelopment.com/plugins/acts_as_enterprisey

Pat

Can you provide a specific example of an enterprise application where
Rails improved your life? What did Rails improve? What did Rails
struggle with?

- Jeff

Rails works for nearly anything I've come up against, but there are
three areas where you will struggle:

1) Legacy database schemas will threaten your sanity if you let them.
2) Its web service interfaces outside of REST are lacking (enterprise
to many is a mess of SOAP and WSDL trash). If you can get over that,
then it's a great way to expose services.
3) Deployment in a high scalability setup will require some expertise.

If you can overcome those hurdles, then, in my experience, Rails works.

--Jeremy

Hi Jeff

I've done a few C level posting.
(CTO and Founder), including Nasdaq listing)

So it depends on the questions:

1. Is it going to be around a long time - Yes - Ruby itself has, and
Rails has hit 2. Plus recognition from
major software firms. (Oracle offered class on it on the Shanghai
Training Session,), oracle has support.
Major media companies are using it. Other MNC are using. Trading(As in
stock, on wallstreet) are using it.
Look at the "books" available. Need one every week. Look at the number
of web articles. By every metric its
everywhere.

2. Is training available? Yes, on multiple fronts. Also fresh java
grads tend to pick it up easier.

3. Does it marry with my "enterprise" systems. Now this one is
interesting. Ruby can marry to just
about anything, so thus "rails" can. I am just finishing a "marriage"
between Unify and Rails. The original
applicaiton is over 15 years old, and the data is still worth
millions. Of course I "moved" the data over to
oracle. (With ruby). I've also did "bridges" between applications.

3. Is it secure? If its running on "Linux" would be my answer. Look at
the security guide. Put a https proxy(Nginx)
in fromt. 100x more secure than windows.

4. Is it scalable. Big question. But in a short answer, yes yes yes.
For our users, 3000-4000 is max user count.
I even was helping a friend with handling million plus user bases.
Hardware is cheap, with nginx, mongrel clusters, and
good hardware its falling off a log. (If your public hosting, even a
single server can handle your average load").

5. Can I get consultants? Yes. Look at the tavnav guys for one. There
great.

You name the rest, and I'll answer.

mentalpagingspace.blogspot.com is my blog.

My complete "answer"

http://mentalpagingspace.blogspot.com/2008/01/when-c-levelctoceocfo-ask-so-why-should.html

I'm totally agree with Jeremy.

I joined in March 2007 an enterprise where it had been decided :
- Build a Portal with RoR with Web 2 Features
- Build functional screens over a legacy database , in order to webify
their Client/Server applications.

The main problem i would say is how you sell RoR to your management.
In my enterprise, the architect, at the beginning of this project, did
only demos to the management based on :
- Generation of model, migration (whereas half of the project woould
based on a Legacy database), and scaffold.
Main people of the team (manager included), who were used to build C/S
applications with Oracle Forms (a quite productive tool in the C/S
domain), where quite enjoyed after seeing that in three command lines
you could have a running (but not definitive) application.
Finally they didn't understand the there would code to write (even if
it is well more concise than Java)
So be very careful when you sell RoR : do that after having well
considered all the functional needs and the environment constraints
(especially when using legacy datamodel).

We exactly had problems on the three main points from Jeremy:

1) Legacy database schemas will threaten your sanity if you let them:
Hacks have been done to create Oracle Views over the "old"
denormalized tables. Right for consultation, but not easy for Edit/
Create. And productivity, as shown in the demo, decreased a lot.
The management was always saying the development was not productive
enough

2) Its web service interfaces outside of REST are lacking (enterprise
to many is a mess of SOAP and WSDL trash). If you can get over that,
then it's a great way to expose services.

We Should integrate our application with Third Party (Oracle)
Products, especially one, for the CMS, accepting POST/GET of document
using SOAP Web Services.
The architect should port to Ruby Oracle Java classes from the CMS
Library, and to send SOAP requests, should write from scratch inside
is Ruby code all the SOAP structure (Header, Body)

3) Deployment in a high scalability setup will require some expertise.
Many setups had been chosen before the current one :
Apache/Mongrel, then the choice has been made on LiteSpeed.
Today we've got performances issues - but more on the ActiveRecord
side...the application is connected to an Oracle database: We remark
after an idle time of 1 minute, about ten opened ruby-oracle
connections are dropped. Then, after an activity (click a link then
call an action, executing an operation in database), 10 connexions are
created (so quite long)...

So the project finally has 50% failed, especially for the functional
screens, that should be plugged on the Legacy Data,
A Tool from Oracle has replaced RoR for that : Oracle Application
Express (database centric, PL/SQL powered).
We kept RoR for the portal for two reasons :
- We did many Ajax tricks so RoR saves the day for this
- Portal has its proper datamodel, created from scratch and accepting
RoR conventions.

It was my point of view, after a first RoR experience in the
enterprise.