En BuildingWebApps, un portal para desarrolladores de Ruby on Rails publican un artículo cuya lectura es realmente recomendable, incluso para cualquiera que no se dedique al mundillo de RoR.
El artículo analiza el porque las aplicaciones desarrolladas en Ruby on Rails pueden escalar tan bien como las desarrolladas en otros lenguajes más maduros. Lo hace desde un punto de vista muy racional, lejos del típico "panfleto" que busca simplemente provocar líos o llamar la atención.
Convention over configuration
Y para explicar por qué Rails puede escalar se centra en un problema que no es común sólo a Ruby on Rails, si no a cualquier framework web que se base en el paradigma de convención frente a configuración, ya sea Ruby on Rails, Groovy on Rails, Spring MVC, JBoss Seam, o cualquier otro.
Al favorecer la convención (es decir, el proporcionar valores por defecto) frente a la configuración (es decir, el tener que configurar todo antes de empezar) se está favoreciendo la creación rápida de aplicaciones. Ahora bien, mucha gente no se da cuenta de que estos valores por defecto no dejan de ser más que eso, una convención. Una convención que nos permite prototipar rápidamente nuestras aplicaciones.
Pero a la hora de la verdad, a la hora de escalar, no quedará más remedio que remangarse y empezar a analizar como son nuestras consultas a base de datos, como está siendo la reserva de memoria, que latencia están introduciendo las diferentes abstracciones, como de pesadas están resultando nuestras páginas, etc. Sin hacer todo esto, es difícil que Ruby on Rails, o cualquier otro framework, pueda escalar.
Utilizar más hardware para escalar
El artículo continua hablando sobre otro tema interesante que es que el overhead de Rails te puede obligar a utilizar más hardware, pero que esto no implica que el framework no pueda escalar horizontalmente. De hecho, escalará igual que cualquier otro framework y utilizando mecanismos muy similares (ej. memcached).
Aunque obviamente dependerá del tipo de proyecto, teniendo en cuenta el precio del hierro hoy en día, y la rapidez de desarrollo con RoR en muchos casos este coste adicional es más que asumible si el time to market va a ser mucho menor.
Aún así, me viene a la cabeza que este argumento le hace a uno preguntarse ¿por qué no utilizar entonces plataformas alternativas como grails o JRuby on Rails que corren en máquinas virtuales más maduras?
En fin, un artículo que me ha parecido realmente interesante, y que además presenta una serie de estadísticas e información sobre sitios web que están utilizando Ruby on Rails actualmente que también refuerza esa idea de que realmente RoR escala, pero que es cuestión de ir madurando la plataforma y que aparezcan más soluciones.
comments
4 Respuestas a "Escalabilidad y Ruby on Rails"9:55
Las mismas razones para justificar que escala pueden ser esgrimidas para justificar que no escala bien. Todos sabemos lo que pasa si dejamos los parámetros por defecto en una cojoaplicación que tiene que escalar hasta el infinito y más alla. Así que no veo una ventaja la convención sobre la configuración para escalar, más bien todo lo contrario.
Decir que usa memcache para escalar es justificar que php escala igual de bien. Entonces Java escalará de la leche ya que hay muchos productos de cachés distribuidas y desde hace tiempo. C++, C# también escalarán igual, tienen cachés distribuidas!
Estuve en un proyecto que tenía 24 servidores en el frontal y apenas manejaba unos 20 usuarios concurrentes por servidor (Tecnología Microsoft del siglo XX mezclado con la bisoñez y soberbia de supuestos arquitectos Microsoft, qué le vamos a hacer!). Y escalaba, ya que podías poner otro servidor más y ya está. Evidentemente el precio era altísimo y no era sostenible. De lo que hablamos cuando decimos "hacer una aplicación escalable" es cuanto nos va a costar en tiempo y recursos hacer que escale hasta el límite marcado por los requisitos del cliente. Y por lo que veo, lo que se ahorra en tiempo de desarrollo con RoR se va en tiempo de ajuste del sistema, y de manera exponencial cuando hablamos de saltar a multiserver.
Este es mi mayor argumento contra Rails: es costoso hacer que escale.
Diego dixit ;-)
10:13
Sí, pero puedes utilizar las mismas razones sólo para afirmar que "escala menos que otras tecnologías, ya sea porque son más maduras o porque no favorecen un conjunto de convenciones que no benefician la escalabilidad".
La convención sobre configuración no se esgrime como una razón para escalar, sino que el artículo afirma todo lo contrario: algo que favorece la convención no va a escalar tan bien como algo que no la favorece. Si quieres hacer que escale, tendrás que mancharte las manos. Algo que por otra parte pasa con todas las tecnologías, pero que esta claro que con sistemas que favorecen la convención sobre la configuración es más agudo ya que muchos desarrolladores asumirán que van a tener un rendimiento excelente por defecto.
El artículo tampoco dice que escala muy bien porque usa memcached (quizás haya dejado yo entender esto), sino que simplemente llegado el momento de escalar todavía más, se pueden utilizar los mismos mecanismos, sea memcached, sean CDNs, sea añadir servidores, etc.
16:07
@Martin,
los argumentos del artículo que comentas olvidan algo muy importante: la escalabilidad horizontal se enfrenta a problemas que hace que dediques tiempo y recursos a solucionarlos. El argumento de que te puedes ahorrar un desarrollador y gastarlo en servidores como dice el artículo es una chorrada. Con $100000 puedes hostear a $300 al mes unos 40 servidores dual xeon? No, si tienes cuarenta servidores (o veinte, o 10) es que necesitas un balanceador de carga en HA, una base de datos con unos cuantos procesadores (y en HA, claro!) y probablemte pagar por una CDN. ¿Y quien monta este chiringuito? ¿Habrá que pagarle, no?
El problema de todos estos talibanes RoR es que realmente no se han enfrentado con lo que significa poner en marcha algo que escale de verdad. Y encima, el paradigma de la escalibilidad con RoR que es twitter, falla más que una escopeta de feria. Falla casi todos los días, y se han gastado una pasta gansa en hardware. Y la aplicación no es muy complicada, vamos.
17:13
Diego,
Si, tienes un punto importante ahí. La "escalabilidad operacional" es probablemente uno de los factores que todo el mundo se olvida comentar a la hora de hablar de escalabilidad de arquitecturas empresariales.
La cuestión en ese caso es, ¿puedes construir una infraestructura que escale operacionalmente en RoR (es que automatize despliegue, administración y monitorización de servidores)? Yo no sé la respuesta; no conozco tanto de la plataforma. Eso sí, estoy seguro de que sí lo puedes hacer en Java.
Publicar un comentario