¿Ruby on Rails como problema?

Recientemente el equipo de ingenieros de Twitter publicó en su blog el desplazamiento de Ruby On Rails(RoR) en su arquitectura por la tecnología Java, haciendo uso de Blender a través de Netty [1]. Ya en 2009, en una entrevista realizada a tres de sus más importantes desarrolladores se anunciaba el plan de reingeniería y reemplazo de RoR por nuevas tecnologías[2], tal como hicieron con MySQL y su cambio a Apache Lucene.¿Cómo se le pudiese dar lectura a éste hecho? ¿Es una mala noticia para la comunidad de Ruby On Rails? ¿És una buena noticia para la comunidad de Java?

Realizando un recuento de lo que ha sido el crecimiento de Twitter a través del tiempo, cabe recordar que ésta idea comenzó como un Hack¹ en una compañía llamada ODEO que se centró el podcasting y que estaba presentando problemas administrativos como empresa. Estos problemas, otorgaron libertades a los desarrolladores para que experimentaran con el proyecto, que tiempo más tarde resultó ser Twitter escrito en la plataforma Ruby On Rails. Como es conocido, con el tiempo Twitter comenzó a ganar popularidad y esto se tradujo en mayor número de usuarios y mayores problemas.

Tráfico creciente en Twitter

Esta curva exponencial, que se puede apreciar en el gráfico comenzó a generar dudas de rendimiento y disponibilidad al equipo técnico. Steve Jenson en [2], comenta que: «Con el tiempo descubrimos que a pesar de que Rails funciona muy bien para hacer el desarrollo web front-end , para hacer el procesamiento pesado del back-end, Rails tiene algunas limitaciones de rendimiento en tiempo de ejecución. Y creo que en mi opinión personal el lenguaje Ruby carece de algunas cosas que contribuyen al código confiable y de alto rendimiento, que es algo que estamos muy interesados en conseguir, dado el crecimiento del negocio(…)». Robey Pointer, complementa esta opinión en [2], argumentando que «Ruby no tiene por los momentos buen soporte para los hilos de procesamiento» y añade además que: «Ruby no tiene un buen recolector de basura tal como el que se maneja en la tecnología Java(…)».

Finalmente a principios de este mes, el equipo Twitter anuncia el cambio de MySQL a Lucene y de Ruby On Rails a Java con Netty, argumentando mejoras de escalabilidad y rendimiento a largo y corto plazo [1].

Realizando un análisis objetivo para dar lectura a esta situación se deben tener en cuanta dos factores importantes: complejidad e incertidumbre. Ambos factores son claramente influyentes al momento de determinar la tecnología a trabajar para hacer realidad un proyecto. Pareciera que: cuanto mayor es la complejidad técnica y no-funcional² con respecto a la funcional de una aplicación, más sentido tiene hacer uso de lenguajes de menor nivel³, con mayor trayectoria y por ende mayor experiencia en uso de recursos(JAVA, C, etc). Por el contrario, cuanto mayor sean los requerimientos funcionales y menos complejos los no-funcionales pareciera tener mas sentido usar lenguajes y marcos de trabajo de más alto nivel(RoR, Zend Framework, etc).

Niveles de complejidad funcional y no funcional y su impacto en las Tecnologías

Tal como se puede apreciar en el gráfico, para proyectos que presenten alguno de estos puntos de la curva – no siempre los tipos de requisitos presentan relación inversa– la solución parece ser adoptar tecnologías de bajo nivel para proyectos que tiendan a altas características no funcionales, y tecnologías de alto nivel para proyectos tiendan a  altas características funcionales.

Para el caso de Twitter ,que empezó ubicado en algún punto de abajo de la curva, al principio todo marchó bien con Ruby On Rails. A medida que pasó el tiempo y se fueron acercando más al centro de la curva –Se puede corroborar en [2]– surgieron las necesidades de buscar un híbrido entre RoR (lenguaje de alto nivel) y Scala (Lenguaje de medio nivel a través de Java). Por último, el equipo de desarrollo de Twitter se ha enfrentado últimamente más a retos No-Funcionales (Escalabilidad, Disponibilidad, Fiabilidad, entre otros) acercándose más a la parte de arriba de la curva y ocasionando la inevitable elaboración de un plan a futuro para eliminar definitivamente RoR de su sistema de búsqueda –tal como se puede corroborar en [1] – y dando la bienvenida a un lenguaje de nivel medio como lo es Java y Netty.

En cuanto a la incertidumbre, es bien sabido que los lenguajes de alto nivel como RoR contribuyen a un desarrollo más rápido y flexible de aplicaciones de negocio, frente a lenguajes de bajo nivel o nivel medio tales como Java, en donde es necesario escribir más código para lograr funcionalidades de negocio. Pareciera entonces, que adoptar tecnologías de bajo nivel supone un conocimiento ya maduro de negocio y un direccionamiento estratégico claro de los objetivos que se quieren lograr. Así, la aproximación que se puede encontrar es que: a medida que la incertidumbre del negocio aumenta, resulta razonable usar lenguajes de alto nivel y viceversa.

Incertidumbre de negocio y su impacto en las Tecnologías

Volviendo al caso de Twitter, cuando nació el proyecto como Hack, la incertidumbre era tan alta y los objetivos a largo plazo estaban tan poco esclarecidos, que se requirió de lenguajes de alto nivel tal como RoR para emprender vuelo y lograr así la idea para la creación del «Telégrafo de la Web 2.0». Con el paso del tiempo, y tras recibir una fuerte inversión de capital, los objetivos estratégicos se fueron tornando claros, la experiencia comenzó a aumentar y la incertidumbre disminuyó, ocasionando la bienvenida a lenguajes de nivel medio. En palabras de Alex Payne, según [2] : «(…)Ruby carece de algunas cosas que contribuyen al código confiable y de alto rendimiento, que es nuestro objetivo como crecimiento del negocio. Queremos que el código se escriba específico y fácil de mantener. Por eso empezamos a buscar en Scala.»

Por ende, no resulta correcto asegurar que este hecho ha sido un fracaso para la comunidad de Rails ni una victoria para la comunidad de Java. RoR cumplió su ciclo en Twitter hasta donde alcanzó y lo hizo bastante bien.Lo que si resulta cierto, es la importancia de que la solución de Tecnología que se quiera aplicar debe ser apropiada para el contexto y  las necesidades del proyecto. Y esto puede ir cambiando con el tiempo. Por tanto la victoria ha sido para la Ingeniería del Software.

¹ La palabra es utilizada en determinados sectores de las tecnologías para denominar a las pequeñas modificaciones, reconfiguraciones o reprogramaciones que se le pueden hacer a un programa o sistema en formas no facilitadas por el propietario, administrador o diseñador de este.

² Se refieren a todos los requisitos que ni describen información a guardar, ni funciones a realizar.

³ Cuando en este artículo, se hace referencia a lenguajes y tecnologías en general de alto, medio o bajo nivel, significa la cantidad de tareas repetitivas no pertenecientes al negocio que deben realizarse para lograr una funcionalidad.

Referencias

[1] http://engineering.twitter.com/2011/04/twitter-search-is-now-3x-faster_1656.html

[2] http://www.artima.com/scalazine/articles/twitter_on_scala.html

Enlaces de interés

Sitio Web de Netty

Sitio Web Ruby On Rails