Engine Yard scripts JRuby brain trust support plan

Java-world bargain

By Gavin Clarke in San Francisco, 2nd April 2010

Rudderless on JRuby? The experts will come to your assistance - for a price.

Engine Yard, the company that became a magnet for JRuby brains as Sun Microsystems expired, claims it has become the first company to provide JRuby developers with support.

The company is offering technical advice on building with JRuby and how to "best take advantage" of JRuby in your environment, along with bug fixes in a program that starts at $2,000 a month per company for a minimum of 12 months.

Developers are a notoriously price-averse constituency with limited purchasing power. Signing off on more than $20,000-worth of support is going to require a departmental- or corporate-level commitment ushering Engine Yard's support service out of the tactical and into the realm of strategic commitment.

To give you an idea of how that stacks up: In the world of Linux, a Red Hat subscription that features updates and fixes starts at $349 and runs to $1,299 for a year. A subscription for NorthScale's Memcachd Server starts at $799 for basic support with week-day phone and email support and tops out at $1,299 for 24x7 phone and email support and one- to four-hour response times.

It remains to be seen whether companies using Java, C#, and now scripting languages with (at best) PHP and (possibly) Ruby will want to commit to the newcomer. The pricing and wording also suggests Engine Yard is going for the consultant angel.

Anders Tjernlund, vice president of services and support, called the $2,000 start price a bargain in the world of Java languages and tools. He could be right. Tjernlund was a director of services operations at BEA Systems that charged $10,000 per CPU for its Java application server WebLogic and priced itself out of the market against open-source rival JBoss.

Tjernlund also said the price targets teams of developers, instead of individuals, and noted it does include what boarders on consulting. The 12-month life of the contract has been structured, he said, so Engine Yard can get to know customers' IT environments.

JRuby was created Thomas Enebo, Nick Sieger, Charles Nutter, and Ola Bini, the former three being hired by Sun to build and further refine the language using its blessed Java and Java Virtual Machine (JVM). They left Sun en mass in 2009 with the Oracle acquisition looming to join Engine Yard.

JRuby is an implementation of Ruby in Java designed to take advantage of the performance, scalability, and security provided by the Java Virtual Machine. Engine Yard is targeting those extending Java enterprise and building web-based scripting applications.

Engine Yard will support JRuby, Ruby code running on a JVM, Java code, or other JVM code that uses published JRuby API and trouble shoot instances where Ruby code makes use of third-party APIs through JRuby Java integration.

As for platforms, support has a slight Sun flavor: Engine Yard will cover versions of JVMs from Sun, IBM, and Oracle plus the OpenJDK initiated by Sun in 2006 and editions of the Tomcat, Jetty and - yes - Sun GlassFish application servers. All of that on Windows, OS X, and Linux x86. ®

Regcast training : Hyper-V 3.0, VM high availability and disaster recovery

COMMENTS

House Rules Send Corrections

All Reader Comments (7)

Latest Comments

Posted Tuesday 13th April 2010 22:22 GMT

headius

On JRuby

I am one of the core folks at Engine Yard working on JRuby, so I thought I'd answer a few questions:

* JRuby makes sense for a lot of folks that depend on or like the JVM but that want to use Ruby or Rails. No other web framework has had as much work done on supporting modern web development, and having it for the JVM makes a lot of sense.

* JRuby is at least as fast and often much faster than the standard C implementations of Ruby. We do compile Ruby to JVM bytecode as needed, and have done a lot of work to make sure things perform well.

Don't think about JRuby or Java as being "interpreted/compiled/emulated". The JVM is fast for running JVM bytecode, which Java and Ruby (in JRuby) both compile to. No modern JVM only interprets anymore; they all JIT that bytecode into native code, and in many cases produce code that's as fast as writing in C or C++. JRuby gains the benefit of that, performing at least as well as a Ruby implemented in C and often better because we can leverage the JVM's best features like garbage collection.

Posted Tuesday 6th April 2010 19:35 GMT

John Smith 19

@MacroRodent

"It is nowadays standard issue, at least in all JVMs anyone wants to use in a production environment. "

Now *that* might change things quite a lot. Presumably this is early days for the Ruby interpreter and they will fine tune it as they gather more experience. It still sounds like a bold move to deliver core apps through this model.

Posted Tuesday 6th April 2010 10:01 GMT

MacroRodent