Our team was initially very attracted to the deployment simplification promises of Torquebox and the enterprise integration capabilities of being on JRuby. However, after struggling to create performant and understandable production and staging environments, our team has regretfully decided to back away for now--we’re not Java dudes, and there is too much complexity that we don’t know how to deal with efficiently as Rails developers with no Java background.
For our product launch, we’re going back to Apache/MRI/Passenger--thats the only way we’ll feel comfortable maintaining and troubleshooting the system when it inevitably goes bump in response to new user interactions and under load. We wish it weren’t the case, but without significant investment in learning how JBoss, JRuby, JDBC, and Torquebox really work under the hood, we simply can’t justify the risk of running a Rails infrastructure we don’t understand.We still think that Torquebox and JRuby is one of the most compelling Rails deployment options out there, but right now, in our opinion, its not ready unless you’ve got the stomach to get down with Java. In light of this, we’re going to maintain MRI and JRuby compatibility for at least the next year to be prepared to switch to Torquebox/JRuby when the time is right, when either we have cultivated the needed Java knowledge on our team or Torquebox is a little easier to use for non-Java people. We’d love to use Torquebox/JRuby and are thoroughly bummed that its not feasible to do so now for us. Talk to us in year.
Joe Goggins, Chris Dinger: Academic Support Resources Web-Team, University of Minnesota
I can understand. I just worked with Torquebox and JRuby recently and without a background in Java it does take a while to learn. The architecture of JBoss is great, but it fires up a lot of modules by default and requires a basic understanding of their microkernel to diagnose deployment issues.
ReplyDeleteOn the upside, once you learn how to deal with the JVM, you get some great tools for monitoring and optimizing memory and GC settings. However, it takes a lot to get started.
While I have a Java and JBoss background, Torquebox is really designed to help Java-only shops deploy Ruby. For Rubyists looking for some performance, I would still recommend looking at deploying with JRuby to get the JVM threading and JDBC performance improvements. In that case, you are simply using JRuby in place of MRI, but otherwise your deployment model stays relatively close. I wrote more about my JRuby findings here:
http://launchany.com/mysql-bulk-insert-performance-with-jruby-and-jdbc/
You are right in your assessment that supporting a TorqueBox application in production will require one or more people on the team with a healthy knowledge of the JVM and that's willing to learn about JBoss AS7 and some of the underlying technologies (HornetQ, Infinispan, JBossWeb) so they can be tuned appropriately for production workloads. The more strict your uptime and throughput requirements, the more essential it is for someone to really understand how all the components work together. I'd make the same argument for an Apache / MRI / Passenger stack or any other stack - someone needs to be familiar with and able to tune every component in the stack.
ReplyDeleteWe're always trying to do what we can to make the learning curve easier with TorqueBox and any suggestions from your experiences would be appreciated. I also wanted to make sure you're aware that Red Hat does offer paid consulting and support for TorqueBox and the underlying JBoss components if you decide to try TorqueBox in production again and want experts in the various components to validate and support your production stack.
Did you try Trinidad? If you don't need all the extras JBoss provides, Trinidad is a bit easier to get started with.
ReplyDeleteIt's now 2013 and I wonder is this any easier? I am contemplating a Torquebox deploy to play with, but it just looks so complicated.
ReplyDeleteDid you ever change your minds? Is Torquebox still the preserve of old Java dudes?
Hey Kevin + Other Commenters.
ReplyDeleteThanks for the great feedback to this post, I wish I'd had notifications turned on, so I could have replied more promptly (it's ridiculous to reply to something over a year later, sorry!).
Since there is so many good points here, rather than replying to each individually, I'll
reiterate a point of view I have about technological adoption that this post alludes to:
Pick the tool that gets you into the ecosystem you want to play in.
When I wrote this post, as a web dev doing enterprise app development at the University of Minnesota, TorqueBox was very attractive for this reason. Our team saw it as a way to reorient our capacity toward the Java ecosystem because we saw it as a way to bridge the gap between the departmental units like us doing Rails with the central IT units doing things with Java.
Though the idea of picking a tool to get you into the ecosystem you want to play in is important--the other relevant question, is At what cost? How much of a stretch is it?. So then, restated:
Pick the tool that gets you into the ecosystem you want to play in at the right cost.
For us, it was way too much of a stretch. We knew nothing about the JVM and felt much more comfortable playing in the natively compiled ecosystem including Apache, passenger, etc.
For me now, Torquebox is still definitely not a good fit--but that is reflection of the technical ecosystems I want to play in and the technologies I'm comfortable with, rather than a statement about the technology itself. Torquebox is amazing tech, and if it fits with your team, rock it!