El modelo basado en programar rápido, crecer aún más rapidamente en usuarios y vender antes de generar un modelo de negocio, parece estar en crisis. Los actuales problemas de escalabilidad de Ruby, la herramienta por excelencia de la programación rápida y bonita, hacen que el modelo sea viable sólo para aquellos… que se supone han de comprar
Gestionar aplicaciones web fuertes con Ruby on Rails tiene sus problemas. Mucho están sonando estos días los que sufre twitter y parece que hay un cierto consenso sobre los límites de la escalabilidad que bajo ciertos supuestos tienen este tipo de aplicaciones.
En las Indias, merced a feevy, las conocemos bien y por desgracia, en más de una ocasión, no hemos podido evitar que nuestros usuarios también las descubran.
Ciertamente resulta frustrante encontrarte con problemas de escala con tan poquitos usuarios como hoy tienen feevy (1643 que hacen sus feevies con unas 7500 fuentes distintas) o el mucho más ligero twitter (unos 100.000). Pero existe una solución bien conocida: distribuir el peso del proceso entre distintas máquinas. Eso hicimos con el parseo de las feeds que estamos procesando en este momento y éso hemos empezado a hacer con las bases de datos.
Si quieres programar en Ruby un servicio web 2.1 ágil y robusto no tienes más remedio que montarte una red. Sólo así, escalando la red, podrás ofrecerlo con una cierta estabilidad a una comunidad creciente.
Es verdad que para parte de lo que distribuyas no te harán falta servidores dedicados. En feevy, el parseo -que no requiere ningún tipo de info personal- recae sobre los ordenadores de trabajo y las laptops de los indianos, al mejor estilo seti@home. Pero las bases de datos de los feevies, dónde está la info de las preferencias de tus usuarios no puede salir de servidores seguros. Y éso implica más máquinas y más gasto para tener una estructura distribuida interna y segura.
Es decir, hacer de mumi, si tienes éxito, no sale barato… y con Ruby menos. Y éso quiere decir que a más de uno le tocará replantear sus planes de negocio. O el lenguaje de programación.
El modelo del “programo rápido y bonito”, “crezco rápido en usuarios” y “vendo caro antes de tener que plantearme si mi comunidad de usuarios es rentable”, parece estar en crisis. Los actuales problemas de escalabilidad de Ruby, la herramienta por excelencia del “programo rápido y bonito” hacen que el modelo sea viable sólo para aquellos… que, se supone, han de comprar (Google, Yahoo!, etc.).
Actualización: Fajro me manda un post de Ricardo Galli que apunta en el mismo sentido. Me llama la atención por cuanto tengo entendido que Menéame, al igual que feevy, no fue pensada como start up sino como ciberactivismo en forma de software o como dice en nuestra web, como un “regalo a la comunidad“. Algo me dice que final del día, seguramente los que no fueron creados como negocio serán los que sobrevivan.
En otros blogs este post recibió las siguientes referencias (URI de Trackback)
-
[...] parecer están experimentando muchos problemas a la hora de escalar Twitter (la aplicacion de moda) y feevy (una gran idea) a miles de usuarios porque están hechos en Ruby y [...]
-
[...] Feevy experimental problemas de escalabilidad al estar hecho en RoR [...]
-
[...] de los problemas que de vez en cuando han afectado a Twitter pueden estar relacionados con problemas de escalabilidad de Ruby on Rails. Al menos este es un tópico que circula libremente en la Red casi desde la presentación de [...]
Creandote un usuario en un 
Puedes ver los 23 posts más actualizados de mi 
Puedes ver las estadísticas de este blog -entre otros- en el 
Tal vez deberían reescribir todo el código de Feevy en PHP.
Y cual sería en tu opinión David el lenguaje ideal para programar aplicaciones escalables? (es por satifacer mi curiosidad ignorante)
David,
Si quieres una aplicación realmente escalable tienes que usar J2EE, que separa la arquitectura en tres capas, la capa de los datos, la de lógica del negocio y la de presentación. Las cuales tienen distintos tipos carga, algunas aplicaciones son intensivas en consulta a Bases de Datos, otras intensivas en cálculos y otras intensivas en grafica. Al estar separadas, puedes detectar donde está la sobrecarga y dimensionar acorde a la carga, así se optimizan los recursos, ya que ahí detectas si necesitas más procesador, más ram, más disco duro o más ancho de banda. No es fácil de encontrar buenos desarrolladores J2EE, pero es como un camión, parte muy lento, pero cuando vas a 120K/H no te para nadie…
PHP fusiona la capa de lógica de negocios con la de presentación, separándose de la de los datos, quizás este tiene la mejor relación TiempoDesarrolo-Complejidad-Escalabilidad, pero tener en un mismo archivo .php el layout de la interfase de un sitio y la lógica de cálculos no es conveniente, es un tremendo enredo y es ineficiente, por ejemplo, php no es muy bueno para cálculos numéricos y muchas iteraciones, en eso generalmente lo mejor es C++.
Cuando ejecutas un .PHP todo el código se carga en memoria, la lógica de negocio generalmente incluye muchos IF, Entonces cada vez que ejecutas un archivo .php, cargas en memoria la rama que si entra en el IF y la que no entra en el IF, lo cual es ineficiente, hay casos en que el IF se ejecuta muy pocas veces, entonces cargarlo en memoria cada vez que despliegas la interfase en totalmente ineficiente.
No conozco en profundidad Ruby, pero lo que he visto me parece que es muy bueno para prototipar, pero no me extrañan los problemas de crecimiento, ya que están las capas mezcladas, entonces cuando quieres crecer te obliga a la duplicación exacta, en cambio J2EE o PHP no es necesario duplicar el hardware para duplicar la capacidad.
a mi parecer, Feevy tiene una altísima carga en la capa de lógica, ya que debe hacer “cálculos” para cada uno de los sitios con feevy, de tal manera de decidir que post se publica y cual primero o segundo, me imagino que si está completamente hecho en Ruby, ese algoritmo debe ser muy ineficiente, a veces basta con sacarlo y hacer que otra aplicación con otro lenguaje lo ejecute. Otra manera mas fácil es no hacer esos cálculos on the fly, si no que hacerlos una vez cada cierto tiempo y guardar el resultado en la base de datos, entonces cada vez que se consulta un feevy, no se hacen cálculos, sino que solo se despliega lo guardado en la Base de datos.
Bueno, ojala no esté muy equivocado, Saludos desde Chile.
David, la gente de La Coctelera, a quienes conozco bien y quienes más saben de Ruby en España, han dado respuesta a todas esas incertidumbres sobre RoR en un interesante artículo:
http://www.lacoctelera.com/porras/post/2007/04/17/la-polemica-sobre-escalabilidad-rails
Ellos, que ya han pasado por ahí exitosamente y que tienen un servicio bajo rails con millones de visitas y cerca de 100.000 blogs, son autoridad indiscutible cuando dicen que el problema no es tal.
Yo lo que no entiendo es cómo después de haber solucionado/parcheado (deprisa, corriendo y málamente) los errores de twitter, una vez la cosa volvía a ser estable, no han pensado en reprogramar desde cero la aplicación utilizando por ejemplo PHP. Realmente twitter no parece una aplicación compleja.
J2EE no tiene la exclusiva de las arquitecturas en tres capas. Uno de los principios de RoR es precisamente ese, la separación de los datos, la la presentación y la lógica (Modelo, Vista, Controlador).
He podido participar recientemente en varios proyectos en los que se utiliza Rails y no era raro ver como era imprescindible utilizar otros lenguajes para integrarlo con componentes antiguos o para desplegar otras aplicaciones web. En ningún caso esto ha supuesto un problema. Existen numerosas posibilidades para trabajar con múltiples lenguajes y más en una arquitectura en la que se separa la lógica del resto de la aplicación.
La abstracción del modelo de datos permite que las bases de datos subyacientes nos ofrezcan todas sus posibilidades en cuanto a balanceo de carga.
A todo esto hay que unirle que es una plataforma muy bien documentada, que resulta muy fácil de aprender y en la que es agradable programar.
La principal diferencia la veo en que entornos complejos, como J2EE, están pensados para aplicaciones grandes desde el principio, entonces todos los problemas de escalabilidad ya se plantean en las primeras fases. El que en otras plataformas se tenga que plantear más adelante no lo veo un inconveniente, de hecho puede ser un beneficio si te ahorras enormes gastos iniciales de una aplicación que quizá luego no tenga el éxito esperado.
Gracias a todos por los comentarios.
Javier: Conocía el post de los de La Coctelera y como tú, pienso que son los mejores en estas cosas, con una experiencia estupenda y muchísima cabeza. De todas formas, su solución no es necesariamente universal… Vamos, que no es el único problema de escalabilidad que te encuentras con Ruby.
Por otro lado no digo que una aplicación hecha con Ruby no sea escalable, sólo que es escalable a mayor coste que otras aplicaciones hechas con otros lenguajes.
El regalo que supone la existencia y mantenimiento de la coctelera por ej debería compararse, por ejemplo, con Bligoo.
Y estoy de acuerdo con Jaime en que el secreto está no sólo en la distribución sino en la combinación de lenguajes y capas. Por ahí vamos! (Y creo que con eso respondo a Luis y a Fajro
