¿Ruby on Rails como problema?

 Ing. Gerardo Barcia Palacios White Papers www.gerardobarcia.com ¿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? ¿Es 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
1 Ing. Gerardo Barcia Palacios White Papers www.gerardobarcia.com 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
2 Ing. Gerardo Barcia Palacios White Papers www.gerardobarcia.com 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.
3 Ing. Gerardo Barcia Palacios White Papers www.gerardobarcia.com 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]
4 Ing. Gerardo Barcia Palacios White Papers www.gerardobarcia.com : “(…)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-3xfaster_1656.html
[2] http://www.artima.com/scalazine/articles/twitter_on_scala.html
5