Para soportar los volúmenes pico de mensajería en Twitter (5000 por minuto durante la asunción de Obama), Robey Pointer ha migrado la cola de mensajes de Twitter desde Ruby hacia Scala, para mejorar el desempeño de la aplicación, según se explica en Twitter Kestrel Project. Como fuera recientemente revelado por Alex Payne, los ingenieros de Twitter se han decidido por Scala luego de los muchos problemas de escalabilidad de Ruby On Rails que provocaron importantes caídas en sus servidores. Esta es quizá la oportunidad para que Scala deje de ser sólo un lenguaje experimental y pase a formar parte del mainstream de la JVM.
¿Alguno de ustedes ha trabajado con Scala?
¿A qué creen que se deban los problemas de escalabilidad de RoR?
¿Se podría crear un titular más amarillista e incorrecto? Lo dudo. En el post del blog de twitte menciona el sistema de cola de mensaje en Scala (que no llega ni a 2kloc), y un plugin para RoR de cacheo.
Y como digo mil veces por ahí, el problema de escalabilidad de X, para un X cualquiera, no es dependiente de la plataforma sino de la arquitectura (o al menos el % está en <10->90 respectivamente).
Pero bueno, si no tenemos ni la más mínima idea sobre el tema, es muy facil soltar frases a lo X no sirve para Y (siendo X = rails e Y = escalabilidad, en este caso).
Me recuerda a una noticia estilo las de "he oido que han dicho que comentan que dicen que..." :)
Siguiendo la referencias, Kestrel nació como un experimento por que a Robey Pointer le apetecía probar Scala en un proyecto real, y luego descubrió que era más eficiente que la solución en Ruby y de ahí pasaron a usarla. Lo de los 5.000 mensajes por minuto lo mencionan para explicar por que usan colas asincronas para los mensajes SMS y han tenido que ampliarlas con una "cola en disco" para no saturar la memoria del servidor, pero en ningún sitio menciona que ese fuera el motivo para migrar de Ruby a Scala ni que la versión en Ruby se cayera... por ser Ruby. De hecho en esa entrada apenas menciona a Rubymás que para mostrar un trozo de código de un cliente
A lo mejor hay otras refencias que le den más significado a la cosa y expliquen realmente si el caso fue como menciona la noticia, pero así con los enlaces proporcionados...
Y sí, he trabajado un poco con Scala y no es raro que el rendimiento sea bastante bueno en peticiones concurrentes, que es donde se lucía tambien en mis propias pruebas. La pega que le veo yo, méritos técnicos aparte, es que todavía les queda un tiempo, creo yo, a los lenguajes funcionales hasta poder llegar a ser "mainstream", básicamente tambien por los programadores. Si ya la mitad no se aclara con Java, que es explicito y verborreico como el solo, no te digo con un lenguaje funcional donde hay que poner más materia gris.
De todas formas, en este caso la diferencia de "arquitectura" entre ambas soluciones es mínima, puesto que el código es "simple" y la mayoría del trabajo lo hace el sistema memcache. Tampoco veo yo que haya que escandalizarse por que una solución sea más eficiente que otra.
En la noticia puse un hipervínculo hacia una presentación de Alex Payne en la que se explica que tuvieron muchos problemas de performance con la VM de Ruby, no necesariamente por culpa de la arquitectura que adoptaron. No veo cuál es el problema de mencionar que se está migrando de Ruby a Scala, si es precisamente eso lo que están haciendo.
El "problema" es que de un comentario de una transparencia que no menciona nada explicito sobre el sistema de mensajería de twitter y de otro mensaje donde se habla de soluciones para escalar ese sistema de mensajeria que no menciona nada a Ruby, se acaba en una noticia donde se migra el sistema de mensajería por culpa del rendimiento de Ruby.
Si la idea era enfatizar la posible/futura migración de Twitter a Scala, con la presentación de Alex Payne "basta". Pero si hasta en el mensaje donde habla de "Building on Open Source" dice que usan un sistema de cache sobre Ruby.
No es que los de Twitter no vayan a migrar, pero es que el resto de enlaces no se que tienen que ver con el tema, si no lo contradicen, y lo de que la causa son los picos de mensajes es, a la vista de los datos, especulación.
Lo que si me parece "curioso" es que una de las cosas que se lee cuando hablan de usar Scala es, por un lado, que no es Java y, por el otro, que lo bueno que tiene son sus librerías... en Java. Otra de las cosas es que parece que el estado de algunos módulos de Ruby no les acaba de convencer... pero si pasan a Scala que se anden con ojo, que la definición del lenguaje todavía no esta "congelada".
Aquí dejo otra nota que comenta que Twitter está abandonando Rails por problemas de escalabilidad. No es mi culpa que hayan tomado esa decisión, yo sólo reproduje una noticia que encontré en la página oficial de Scala.
Saludos ;)
@greeneyed: El "problema" es que de un comentario de una transparencia que no menciona nada explicito sobre el sistema de mensajería de twitter y de otro mensaje donde se habla de soluciones para escalar ese sistema de mensajeria que no menciona nada a Ruby, se acaba en una noticia donde se migra el sistema de mensajería por culpa del rendimiento de Ruby.
Esta nota es una adaptación de una entrada en la página oficial de Scala. Yo lo único que hice fue agregar un vínculo a la presentación de Alex Payne para mostrar que se está migrando y poner un título más explícito. El resto es una traducción casi literal.
@greeneyed: Lo que si me parece "curioso" es que una de las cosas que se lee cuando hablan de usar Scala es, por un lado, que no es Java y, por el otro, que lo bueno que tiene son sus librerías... en Java.
Yo creo que se hace énfasis en las librerías en Java para mostrar que es posible introducir Scala de manera gradual en aplicaciones java existentes, o bien, simplemente reemplazar el lenguaje pero utilizar los frameworks java ya provados.
@greeneyed: pero si pasan a Scala que se anden con ojo, que la definición del lenguaje todavía no esta "congelada"
Eso es muy cierto, por ahora debe utilizarse con cierto cuidado, porque hay cuestiones que aún no son del todo claras. Pero lo bueno de que lo utilice una aplicación importante como Twitter, es que seguramente se revelarán muchas ventajas, desventajas y patrones de diseño que servirán de feedback para una release futura y quizás más estable.
Saludos y gracias por comentar.
Aquí dejo otra nota que comenta que Twitter está abandonando Rails por problemas de escalabilidad. No es mi culpa que hayan tomado esa decisión, yo sólo reproduje una noticia que encontré en la página oficial de Scala.
Saludos ;)
Abandonando Rails, que no Ruby. En esa misma nota dicen que quizá seguirían con Ruby pero sin Rails. Igualmente, tampoco dice nada de la cola de mensajes etc. etc. Entiendo que la fuente en la que te basas es esa nota oficial, así que será en la fuente donde han hecho esos "saltos lógicos".
Yo creo que se hace énfasis en las librerías en Java para mostrar que es posible introducir Scala de manera gradual en aplicaciones java existentes, o bien, simplemente reemplazar el lenguaje pero utilizar los frameworks java ya provados.
Lo que me resulta curioso no es desde el punto de vista de usar Scala, donde ese tema está claro. Si no en el "énfasis" que le ponen algunos a "no usamos, Java, no, no, eso no"... pero usar Scala, o Groovy, está bien por que, entre otras cosas, permiten acceder directamente a cantidad de librerías en Java.
Eso es muy cierto, por ahora debe utilizarse con cierto cuidado, porque hay cuestiones que aún no son del todo claras. Pero lo bueno de que lo utilice una aplicación importante como Twitter, es que seguramente se revelarán muchas ventajas, desventajas y patrones de diseño que servirán de feedback para una release futura y quizás más estable.
Bueno para Scala, seguramente pero... ¿bueno para Twitter? ;) Por un lado está claro que con el uso avanzará mucho, por otro lado si empieza a usarse de forma masiva antes de estabilizarse, quizá el uso masivo les fuerce a congelar cosas que no esten del todo finas, para no mosquear al monton de usuarios importantes que ya tendrán. Ser el pez pequeño da mucha libertad para hacer las cosas como quieres.
Totalmente de acuerdo al primer comentario...
Migrar la cola de mensajes de Ruby a Scala es igual a migrar enteramente la aplicación? mmm...
Y sobre la nota del 2008/05/01, de casi un año, hablando de los problemas de escalabilidad, no sé, como que se quedaron dormidos hasta que solucionaron sus problemas en Twitter, no?
Mantengamos la educación, por favor. (lo digo por el mensaje borrado, no por los anteriores)
Lo que no entiendo es que si lo que realmente requieren es eficiencia, ¿para qué optan por Scala? A menos que me equivoque, ¿Scala debe de ser más lento que Java puro no?
¿Scala debe de ser más lento que Java puro no?
¿Y en que basas tu suposición? Teniendo en cuenta que Scala es un lenguaje compilado a bytecode, igual que Java, no veo una razón para pensar eso así sin más.
Si migran aunque sea un aparte del sistema a SCALA es porque algun problema tienen.
Los que aman a RUBY deben reconocer sus falencias, de otro modo son solo fanaticos.
Sobre que twitter iba a dejar de usar rails, tampoco es correcto, recuerdo que se aclaró el tema vía twitter y algún post(no recuerdo la referencia). Simplemente hay que ver el plugin de rails que se nombra en el mismo post en el blog de twitter, para darse cuenta que no han dejado rails...
El tema de "dejar rails" iba encaminado a que ciertos componentes de su arquitectura los estaban/iban a migrar(ej: cola de mensajes :P), otra cosa es que en TC entendieran lo que quisieran ;)
¿Y en que basas tu suposición? Teniendo en cuenta que Scala es un lenguaje compilado a bytecode, igual que Java, no veo una razón para pensar eso así sin más.
Pues Groovy también puede ser compilado a bytecode y es más lento. Esto porque usa introspección, genera métodos dinamicamente, etc... Así que por analogía se puede suponer que pasa lo mismo para Scala.
Pues en vez de por suposiciones, por pruebas: http://www.jroller.com/greeneyed/, para algunas cosas bien habituales Groovy y/o Scala pueden ser igual o más rápidos que Java. Y por supuesto que Java será más rapido para muchas otras.
Y aún así, a no ser que en algún sitio este puesto que Groovy y Scala hacen lo mismo, no le veo mucha base a la suposición.
@yannart: Pues Groovy también puede ser compilado a bytecode y es más lento. Esto porque usa introspección, genera métodos dinamicamente, etc... Así que por analogía se puede suponer que pasa lo mismo para Scala.
Bueno, creo que eso en parte podría deberse al uso de tipado dinámico en Groovy. En Scala la situación es diferente, porque es un lenguaje de tipado estático, incluso más estricto que java. Por otra parte, la utilización de reflection está desalentada gracias a ciertas construcciones del lenguaje que satisfacen de manera estática lo que muchas veces en Java debe encararse por medio de metaprogramación, así que en esos casos supongo que el desempeño de Scala será mejor. Si Java es más veloz que Scala en algunas cuestiones, es más probable que se deba al estado de madurez de los compiladores que a la naturaleza del lenguaje.
Para agregar otra chispa al flamewar aquí iniciado, les dejo una entrevista a Alex Payne, el hombre de la polémica, en la que explica por qué considera que los problemas de escalabilidad de Twitter radican en Rails.
Una noticia que aparentemente inicia con el título de que Twitter comienza un cambio de
plataforma, pasa a transformarse en que en realidad el cambio es en una parte de la
aplicación, para finalizar mostrando la verdadera intención del "artículo" desde un comienzo,
que es armar la típica polémica con falta de contenidos y argumentos reales de Java o JVM
vs. el resto del mundo, para tener a tipos como uno perdiendo su tiempo, escribiendo estas
líneas y ayudando a que el post tenga más comentarios de los que realmente se merece...
Patético...
Es muy triste echarle la culpa al currito programador cuando el rendimiento de una VM es MALO, lo haga Ola o un anonimo ...
..les dejo una entrevista a Alex Payne, el hombre de la polémica, en la que explica por qué considera que los problemas de escalabilidad de Twitter radican en Rails.
En Rails, que no Ruby, y por que Rails esta basado en el supuesto de una BDD única, lo cual puede provocar obviamente problemas de escalabilidad en algunos tipos de aplicaciones. Y es el problema de basarte en "convención sobre configuración" si tu problema no es "convencional" como lo entiende tu framework. Así que según las mismas palabras del "hombre de la polémica", es una cuestión de arquitectura de RoR y no de Ruby, y para la parte de colas de mensajes.
Y además los de Twitter siguen usando RoR...
pfffffffffffffffffff pero que noticia mas AMARILLA, he quedado perplejo al leer el titulo.
simplemente estan migrando el backend a una "herramienta" (lenguaje) mejor disenado para ese trabajo, lo cual es perfecto, no hay necesidad de hacer tanto escandolo por esto. Casi todos usan un backend escrito en C, Erlang o Scala.
por ahi tambien leo que "Rails esta basado en el supuesto de una BDD única" lo cual es totalmente falso, como se le demostro a Alex Payne, usar varias bases de datos en rails es increiblemente facil
atesti evidentemente no tienes idea de lo que escribes, y ademas pones un monton de enlaces con informacion incorrecta. Un concejo: no le creas a techcrunch.
Como el mismo Payne dice aqui http://unlimitednovelty.com/2009/04/twitter-blaming-ruby-for-their-mistakes.html (uno de los ultimos comentarios) y aqui http://al3x.net/2009/04/04/reasoned-technical-discussion.html:
"I sound like a pretty unreasonable guy filtered through the tech press and Reddit comments, but I hope less so in my own words."
A muchos les encanta filtrar lo que dice alguien para destruir algo(en este caso ruby), por favor mas responsabilidad en javahispano.
Para los que defienden Java, c, c++, python o incluso ruby: no funciona para twitter ni para sistemas de alta escabilidad porque no tienen el mecanismo de share-nothing e inmutabilidad (implicita), que es lo que de verdad importa cuando hablamos de escalabilidad. Erlang y scala son las herramientas de-facto elegidas para este trabajo, fueran disenadas para esto.
notese que escabilidad es MUY diferente de velocidad de procesamiento.
Escribe tu comentario