Una diatriba de Zed Shaw, el hombre que escribió la versión original del servidor de aplicaciones Ruby Mongrel me hizo pensar en las experiencias que DreamHost ha tenido alojando sitios web impulsados por Ruby on Rails durante los últimos años. La diatriba en sí era algo extensa pero una lectura interesante (aunque autoindulgente) si eres un desarrollador de Ruby on Rails, un nerd al que le gustan estas cosas, o estás interesado en los entresijos de un proyecto de código abierto muy público.
No tengo nada que agregar a los comentarios de Zed Shaw sobre cómo opera el equipo de desarrollo de Rails ya que no tengo conocimiento personal de ello. Lo que sí tengo conocimiento personal es de lo difícil que puede ser poner en funcionamiento una aplicación Rails y mantenerla funcionando. DreamHost tiene más de 10 años de experiencia ejecutando aplicaciones en la mayoría de los frameworks de programación web más populares y Rails ha sido y continúa siendo uno de los más frustrantes.
Algo de Historia
Cuando comenzamos a implementar nuestro soporte para Ruby on Rails, quisimos hacer todo lo posible por apoyarlo. Era un marco de trabajo web nuevo y emocionante que estaba revitalizando el desarrollo de aplicaciones web. Ruby on Rails parecía encajar realmente bien con la filosofía de nuestra empresa y pensamos que a nuestra base de clientes existente le encantaría. Terminamos implementando bastantes características nuevas solo para soportar Ruby on Rails, incluido el soporte para FastCGI. Rails en sí resultó ser demasiado lento para usar sin algún tipo de aceleración (a diferencia de cualquier otro entorno de programación web que soportamos), y FastCGi es, con mucho, el más adecuado para un entorno de alojamiento web compartido. Desafortunadamente, ¡Rails y FastCGI realmente no se llevan bien! No importa lo que hiciéramos, los usuarios de Ruby on Rails seguían viendo errores internos del servidor regularmente. La mejor suposición que tengo es que el gestor de procesos dinámicos de FastCGI estaba pidiendo educadamente al proceso de Rails que terminara y en cambio, simplemente se salían y dejaban la aplicación colgada y seca. ¡Eso en términos laicos, por supuesto!
Estos problemas fueron posteriormente mitigados en su mayoría por un solo usuario de Ruby on Rails que quería que funcionara mejor en nuestros servidores, pero la solución de la comunidad de Rails en sí fue, francamente, estúpida. Dijeron que dejaran de usar Apache y FastCGI (una combinación que alimenta exitosamente a bazillones de sitios web, solo que no los de Ruby on Rails) y en su lugar reequiparan completamente nuestros servidores con Lighttpd y SCGI (un protocolo similar a FastCGI que puede ser técnicamente superior, pero casi nadie usa). Esa sugerencia muestra ya sea una falta completa de entendimiento de cómo funciona el alojamiento web o un total desprecio por el mundo real. Está muy bien recomendar que los usuarios usen alojamiento de servidores dedicados de gama alta para sus aplicaciones comerciales pero simplemente no se puede ignorar el hecho de que casi todos querrán usar alojamiento compartido de bajo costo para empezar. Es simplemente economía básica. Además, las personas que usan sistemas como Ruby on Rails quieren pasar tiempo programando y no tiempo configurando servidores. Recomendar tecnologías que no son ampliamente utilizadas o soportadas por ninguna compañía importante de alojamiento web es poner demasiada carga en tus usuarios, las personas que quieres mantener felices. ¡Es bueno que nunca intentamos cambiar nuestro sistema para soportar Lighttpd y SCGI, también, porque 6 meses después lo ‘de moda’ en la comunidad de Rails había cambiado a Mongrel, en cambio. ¡Decídanse ya!
Cómo podría mejorar
Zed Shaw menciona en su crítica que incluso la aplicación Ruby on Rails dirigida por DHH (¡el tipo que escribió Rails!) tiene problemas regulares y necesita reiniciarse varias veces al día. La comunidad de Rails está llena de programadores muy inteligentes y han implementado un gran sistema que funciona de maravilla cuando no necesita atención. Es uno de los sistemas de aplicaciones web más caprichosos con los que he tenido experiencia, y esto lo dice alguien que ha experimentado tanto el desafortunado servidor web de Netscape como muchas iteraciones de PHP (PHP tiene muchos problemas propios, así que no se sientan demasiado complacidos, gente de PHP).
Ruby on Rails tiene un potencial increíble, pero aquí hay algunas cosas que simplemente deben arreglarse antes de que pueda ser tan ampliamente utilizado como entornos de aplicaciones web menos publicitados como PHP…
- Ruby on Rails necesita ser mucho más rápido. Con un acelerador adecuado, es bastante usable pero sin uno es doloroso. Ruby en sí es una gran parte del problema por lo que esto puede reducirse a simplemente simplificar la gestión de las tecnologías de aceleración, desafortunadamente. Mongrel parece un gran paso en la dirección correcta, aunque no es específico de Rails. Espero que los desarrolladores principales de Rails cooperen mucho más estrechamente con los desarrolladores de Mongrel en el futuro.
- Ruby on Rails necesita funcionar más o menos en CUALQUIER entorno. No puedes esperar que tus usuarios configuren sus servidores de cualquier manera. Hay millones de sistemas establecidos que simplemente no pueden integrar cualquier tecnología de vanguardia que pienses que es mejor esta semana. Si continúas manteniendo esta actitud, seguramente te estás disparando en ambos pies.
- Necesitas mantener una mejor compatibilidad hacia atrás. Admito que este es el área donde PHP históricamente ha tenido un rendimiento muy pobre, pero eso no es razón para no superarlos. Además, Rails es admitidamente muy joven como plataforma de desarrollo y ustedes han recibido MUCHA atención muy temprano. Sin embargo, con una gran expectativa viene una gran responsabilidad. Necesitas mantener el impulso ahora.
- Ofrecer soporte oficial para entornos de alojamiento compartido. La sensación que tengo de la comunidad de Rails es que Rails se está promoviendo como un tipo de sistema de aplicación de alta gama y eso hace que esté bien ignorar la vast majority de los entornos web de los usuarios. Simplemente no puedes ignorar a los usuarios de alojamiento compartido. En mi opinión, lo que hicieron las personas de PHP que los llevó a donde están hoy es abrazar el alojamiento compartido y trabajar duro para hacer que su software funcione bien dentro de él. Eso significa que tiene que ser muy ligero (¡puede que ya sea demasiado tarde para eso en Rails!), y tiene que “enchufarse” a una amplia variedad de entornos operativos con el mínimo de problemas y complicaciones. Trabajos de compatibilidad como ese no son glamorosos, emocionantes, ni divertidos, pero hay que hacerlos.
¿Y ahora qué?
DreamHost tiene la intención de continuar apoyando completamente a Ruby on Rails. Ruby on Rails tiene un gran potencial, y creo que con el tiempo puede estar a la altura de la expectación que lo rodea. ¡Solo espero que la comunidad no se engría antes de que eso ocurra!
Las opiniones presentadas aquí son completamente desde la perspectiva de un externo con alguna experiencia web. Sé que Ruby on Rails se usa en algunos sitios web de muy alto tráfico y es ciertamente posible hacer que funcione bien. Lo que estoy diciendo es que realmente necesita ser mucho más fácil. Debes tener cuidado de no confundir el entusiasmo del usuario con fácil de usar. Los usuarios entusiastas llenarán muchos vacíos en la usabilidad (¡DreamHost prospera con ese hecho!), pero no puedes depender de eso a largo plazo.
