[Just in case you can't read spanish, the article is here]
La semana pasada se publicó una entrevista con un desarrollador de Twitter en la que se ponía en duda la capacidad para escalar de Rails, en particular en la capa de base de datos, y que generó una polémica bastante grande, la verdad. A la gente de La Coctelera nos pareció una polémica absurda, puesto que hace ya varios meses que nos encontramos con ese problema, y se solucionó de una manera sencilla, con poco tiempo y esfuerzo, gracias (más que a la enorme calidad técnica de los programadores =:-P) al propio diseño de Rails y su filosofía DRY. Por ello, la verdad es que todas aquellas afirmaciones (y algunas de las reacciones) nos sorprendieron bastante. Así que hemos preparado un mini-artículo (ya más en serio) contando un poco cómo lo hicimos, a ver si puede ser que las aguas vuelvan a su cauce, que pelearse está muy feo, niños.
El artículo en PDF (está en inglés). Versión HTML.
Otros enlaces:
- 5 Question Interview with Twitter Developer Alex Payne
- Twitter trouble
- Scaling to multiple databases with Rails
- Entrevista con Alex Payne, uno de los desarrolladores de Twitter
- Los problemas de Twitter (y la escalibilidad)
- Los dolores de Ruby On Rails
- Translation From PR-Speak to English of Selected Portions of Rails Developer David Heinemeier Hansson’s Response to Alex Payne’s Interview
- On Twitter, Rails, and Community
- Mogomillones más
Gracias por compartir este tipo de cosas. Aunque el texto de Nic Williams es la base, se agradece otro de una "gran corporación" en estos temas. :-)
Por cierto, que sobre el tema de la escalabilidad hubo bastante polémica internacional cuando Tim Bray habló el año pasado en la conferencia PHP en Frankfurt. Referencia:
http://www.cmswire.com/cms/industry-news/php-vs-java-vs-ruby-0008...
Gracias por el comentario; efectivamente, la solución que propone Nic es brillante. Sin embargo, dependiendo de lo que persigas, puede ser "demasiado". Nuestra solución es más simple, y, para nuestro problema, más que suficiente. Obviamente, no puedes hacer con ella todo el tipo de cosas que puedes hacer con el plugin de Nic, pero en muchos casos no te hará falta (a nosotros no nos hacía falta).
En realidad, con la escalabilidad sucede parecido a lo que pasa con la internacionalización: hay tantas formas de resolverla como aplicaciones que la necesiten. Que además, son muy pocas. ¿Cuántas aplicaciones Rails tienen las necesidades de escalar de Twitter o de La Coctelera? ¿2, 3 de cada 100? Es algo que obviamente no tiene por qué estar en el core. Cuando te llegue el momento, lo resolverás de la manera que más se adapte a tu necesidad y lo mejor que te permita el framework. Que, con un framework tan limpio como Rails, normalmente será bastante bien... con 6 líneas para una solución particular como la nuestra, y 75 para una más general (y más elegante) como la de Nic.
Aparte de esto, esta polémica es una polémica vacía, alimentada por gente que:
1) ni le va ni le viene
2) no ha hecho los deberes, confunde el tocino con la velocidad y la escalabilidad con el rendimiento. Que sí, que están (levemente) relacionados, pero no, no son lo mismo.
Nosotros a lo nuestro, no ha sido para tanto.