Comments on: Ruby on Rails vs. Java Enterprise

By: Lars Strojny

Lars Strojny — Mon, 12 May 2008 12:49:33 +0000

As mentioned before, scalability does not come from the framework. You only have to make sure, that the framework isn’t a burden preventing you from scaling the application tier. Much more important are the HA topics: How to keep the stateful systems up 24/7 etc. pp. But back to the application server: what I don’t really understand is, why you did not even consider PHP + Apache/Lighttpd. I mean there is a reason Facebook, Yahoo and Flickr use it. And no, it is not that they love inconsistent function signatures. You really want to have a stateless application server, as stateless as HTTP is. It is really easy to scale, most of the time you just drop a new web servers in and you are done for the next nK PIs. You can even choose from a large variety of frameworks or component libraries: Zend, Symfony, Code Igniter, etc. pp. with different pros and cons. The funny thing is, that you choose Rails and Java: both platforms are known not to be so fast. And performance is the base number upon you calculate your scaling efforts.

By: friarminor

friarminor — Mon, 12 May 2008 01:33:09 +0000

Mor.ph just kept this more interesting. It now offers the Morph Application Platform, initially for Rails apps deployment only, for Java, too.

Best.
alain

By: www.tagsto.com/trackback/

www.tagsto.com/trackback/ — Sun, 11 May 2008 19:05:20 +0000

Hubs of Ruby on Rails vs. Java Enterprise…

hubs about Documentation Solaris to In a completely clichéd world view, Ruby on Rails hackers wear Jeans and T-Shirt, have a MacBook and a Linux server, and have a lot of fun; while Java Enterprise software engineers wear suits, have a Windows laptop …

By: Kent

Kent — Sun, 11 May 2008 16:25:41 +0000

For larger 100,000,000+ page view a month type sites the problems they are running into have little to do with the framework chosen in my opinion. They have everything to do with how the underlying systems architecture, software architecture, database design, visual design, messaging, and caching mechanisms are implemented. You also have to consider capacity planning, deployment efforts, horizontal vs. vertical scalability models, associate data center costs, troubleshooting, code profiling, clustering methods, database use patterns, and a lot more. You can be sloppy on small sites with all these issues. But, you have to take them seriously with the big ones. Also, lots of sites now are seeing much larger traffic that 100,000,000/month as the usage of the web keeps growing. Not very many systems and development people have the kind of experience necessary to do these things right now. So, it can be difficult to find the right people for the team. Also, it’s the database layer that I see killing people again and again and again. So, you’ll have to pay a lot of attention there to what your developers are doing and how your systems are put together. RDBMS systems are the hardest layer to scale effective for reads and writes. If you are lucky you’ll probably end up focused on building a loosely coupled distributed asynchronous capable system that will be able to scale and partition at all tiers independently. You might want to use Rails on the front end and Java in the back. Or, you might want to run Rails on JRuby so you still get access to your established body of work in Java. Many, many choices. Keep it simple rules all in my opinion.

It’s still challenging to build really big web applications no matter what framework you use. But, it’s fun!