En la conferencia Rails de Madrid hubo una ponencia llamada “Keynote:
mesa redonda sobre frameworks” en la que participé desde el publico
criticando lo “dificil” que es hacer un deployment en Rails y lo facil
que es hacerlo con otros frameworks como por ejemplo Django. (Dejo
claro que me encanta trabajar con Rails y Ruby.)
Parece que estos dias se ha levantado un flame. Despues del “rant” de
Zed S., los señores de Dreamhost2 han escrito un post hablando de
los problemas que tienen para dar soporte a este framework y DHH3 ya
ha respondido dando como respuesta un …
“Now if you’re a user of shared hosting and you’re not satisfied with
the results you’re getting — and you’re not getting good vibes that
things will be better — there are alternatives.”
Opiniones …
-
Los señores de Dreamhost estan haciendo un “overselling” sus
servicios. He visto server loads de 25. No es que Rails no funcione,
es que no funciona ni Movable Type, que es perl … así que, no creo
una aplicación Rails pueda funcionar en sus servidores cuando tienen
los servidores a reventar. Hay otras empresas, como Site5 que dan
soporte a Rails sin tanto problema.
-
Necesitamos mod_ruby. Me parecen muy bien los proyectos que hay
en desarrollo de Rails, pero arreglar mod_ruby para poder lanzar
aplicaciones Rails al menos a una velocidad entre cgi y fastcgi no
estaria mal. Hablo desde el punto de vista de aplicaciones pequeñas.
… and that all.
Francesc
–
name. Francesc E. i Martí
voice. +34 678.681.603
Francesc E.
escribió:> Parece que estos dias se ha levantado un flame. Despues del “rant” de
Zed S., los señores de Dreamhost[2] han escrito un post hablando de
los problemas que tienen para dar soporte a este framework
Por un lado, no termino de entender por qué Dreamhost centra sus quejas
en Rails, ya que los frameworks de python sufren el mismo problema, como
bien comentan Ryan T. y en The-B-list:
http://tomayko.com/weblog/2008/01/10/web-frameworks-and-shared-hosting
Web frameworks and web hosts
(Recomiendo especialmente este último enlace, en el que describen
bastante bien algunos problemas de fondo que hay en todo este asunto).
Y por otra parte, la actitud de Dreamhost me parece muy poco
constructiva y ahí le doy la razón a DHH: si tu negocio se beneficia
directamente de este framework, no te quejes tanto y echa un cable.
Mediáticamente creo que se han disparado en el pie.
–
Raul M. - Freelance Web D.
http://raul.murciano.net
Yo creo que el problema es la juventud de Rails. Hasta hace bien poco
todo el mundo se tomaba a RoR como algo experimental y nadie se lo
tomaba en serio como una alternativa a PHP, ASP o Java. Eso ha hecho
que no se haya evolucionado lo suficiente en el tema del deployment.
Pero cabe recordar que la mayoria de lenguajes han pasado por ahí.
¿Nadie se acuerda de cuando había que ejecutar PHP con un cgi?? Cuando
los de Apache consideraron que era importante programaron mod_php y lo
mismo pasará con Rails, no tardará en aparecer mod_ruby.
Hay otros indicadores que hacen pensar que se está empezando a tomar
en serio a Rails. Plesk, uno de los paneles de control más utilizados
para gestionar servidores incorporó soporte para Rails en la versión
8.2 si no recuerdo mal. No le he probado pero supongo que lo iran
evolucionando hasta que sea tan facil como PHP. Otros paneles de
control estan haciendo lo mismo.
Es cuestión de tiempo que los servidores web más importantes tomen
medidas y incorporen Ruby a su lista de lenguajes soportados. Por el
momento nos tocará hacerlo a mano o con capistrano.
Una solución seria programar un mix entre nginx y mongrel cluster para
tener un solo servidor web de manera que no hubiese que hacer
configuraciones por duplicado. Esto esta en mi lista de cosas que me
gustaría hacer pero que nunca tendré tiempo para hacer 
Por lo que respecta a Dreamhost, sin comentarios, ya lo ha dicho Raul.
Menos quejarse y más colaborar.
Saludos
El 10/01/2008, a las 19:40, Raul M.
escribió:
Francesc E. escribió:
Parece que estos dias se ha levantado un flame. Despues del “rant” de
Aclaraciones:
-
mod_ruby existe … modruby.net
-
El deployment de Rails està resuelto. Tenemos capistrano, vlad …
así que yo creo que si que està resuelto.
-
nginx + mongrel_cluster o apache + mongrel_cluster estan más que
probados i la configuración es realmente sencilla. Recordemos cuando
teniamos que configurar apache + mod_fastcgi o lighttpd …
Es cierto que la gente de Dreamhost tendria que quejarse menos y
buscar soluciones, pero hay que tener en cuenta que quizas el problema
no sea de Dreamhost, sino de los desarrolladores por hacer
aplicaciones que consumen mucha memoria y las metemos en un servidor
compartido. El CMS Typo consumia muchisimos recursos.
Empresas como RailsPlayground lo que han hecho es vender hosting con
instancias de mongrel. Es decir, te venden un puero para que puedas
correr Rails en el … creo que es una de las mejores opciones que he
visto en hostings compartidos.
Un saludo,
Francesc
On Jan 10, 2008, at 10:23 PM, Emili Parreño wrote:
para gestionar servidores incorporó soporte para Rails en la versión
8.2 si no recuerdo mal. No le he probado pero supongo que lo iran
gustaría hacer pero que nunca tendré tiempo para hacer 
de
Raul M. - Freelance Web D.
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
–
name. Francesc E. i Martí
voice. +34 678.681.603
On Jan 10, 2008 4:23 PM, Emili Parreño [email protected] wrote:
Yo creo que el problema es la juventud de Rails. Hasta hace bien poco
todo el mundo se tomaba a RoR como algo experimental y nadie se lo
tomaba en serio como una alternativa a PHP, ASP o Java. Eso ha hecho
que no se haya evolucionado lo suficiente en el tema del deployment.
Pero cabe recordar que la mayoria de lenguajes han pasado por ahí.
¿Nadie se acuerda de cuando había que ejecutar PHP con un cgi?? Cuando
los de Apache consideraron que era importante programaron mod_php y lo
mismo pasará con Rails, no tardará en aparecer mod_ruby.
Les recomiendo mirar los comentarios de
http://www.rubyinside.com/no-true-mod_ruby-is-damaging-rubys-viability-on-the-web-693.html
, donde discuten el tema, la viabilidad (o falta de esta) de un
mod_ruby, los problemas de hacer un “Ruby Tomcat” y hasta la
posibilidad de usar JRuby para shared hosts.
On Jan 10, 2008 4:36 PM, Francesc E. [email protected]
wrote:
- nginx + mongrel_cluster o apache + mongrel_cluster estan más que
probados i la configuración es realmente sencilla. Recordemos cuando
teniamos que configurar apache + mod_fastcgi o lighttpd …
Debes recordar que en la mayoría de los shared hosts (que es lo que se
está tratando en los articulos de DHH y Dreamhost) no tienes permisos
para dejar un script corriendo (mongrel), mucho menos escoger el
servidor web que vas a utilizar.
Es cierto que la gente de Dreamhost tendria que quejarse menos y
buscar soluciones, pero hay que tener en cuenta que quizas el problema
no sea de Dreamhost, sino de los desarrolladores por hacer
aplicaciones que consumen mucha memoria y las metemos en un servidor
compartido.
Teniendo en cuenta las restricciones de no dejar corriendo un proceso
por más de “n” segundos, el problema se daría en estar deteniendo y
reiniciando Rails para cada request.
En caso de que los procesos no tengan límite entonces habrían
aplicaciones corriendo continuamente así solo reciban una petición al
día. El consumo de memoria por cada usuario hace que el shared hosting
deje de ser negocio.
El que haya trabajado algo con Java, J2EE y demás, sabrá que la gente de
Dreamhost no dice más que tonterías
Probablemente lo que pasa es que va a haber un incremento en los precios
de
los servicios, y alguna excusa tienen que buscar…
En fin, c’est la vie
Saludos
On Jan 10, 2008 5:06 PM, Hari S. [email protected]
wrote:
El que haya trabajado algo con Java, J2EE y demás, sabrá que la gente de
Dreamhost no dice más que tonterías
¿Podrías profundizar un poco más en el comentario?
On Jan 10, 2008 5:12 PM, Francesc E. [email protected]
wrote:
“Tu applicación ocupa demasiados recursos, te invitamos a que
contrates una maquina virtual”.
Gracias por la
aclaración.
Por otro lado, hay un gem recomendado para cualquier que esté haciendo
deployments de Rails en producción, deprec:
http://www.deprec.org/wiki/AboutDeprec
Peepcode ofrece un screencast gratis que cubre la instalación de un
sistema con deprec en:
Sí, básicamente la máquina virtual de Java chupa muchos recursos.
Y encima, en cada server pues… Pueden cambiar cosillas. En fin, que
para
que una aplicación J2EE vaya bien, necesitas tener montado en un server un
servidor de contenidos estáticos, otro para JSP + Servlets, y si usas EJB,
también tener su server (apache + tomcat + jonas, por ejemplo). O bien
usar
una solución propietaria como puede ser Bea Weblogic
Normalmente el deployment no deja de ser subir unos war y declararlos en
el
server, mediante xml, habitualmente
Yo hace tiempo que no hago nada en Java, y ni ganas que tengo… Desde
el
2000, más o menos; y eso, había historias que por rendimiento iban fatal;
cuándo se trabaja para un cliente corporativo grande (como era el caso),
pues la cuestión se resuelve poniendo dos servidores; pero en los tiempos
que corren, no creo que esa sea la solución idónea.
En fin, lo dicho, que probablemente la cuestión sea que hay que justificar
un aumento en las tarifas 
Saludos
PD: aunque soy muy novato en Rails, y aún no he hecho nada de nada serio, me
parece una plataforma muy potente e interesante; y la sigo de cerca… Y
con
ganas de hacer el primer proyecto en ella 
“Tu applicación ocupa demasiados recursos, te invitamos a que
contrates una maquina virtual”.
Francesc
On Jan 10, 2008, at 11:06 PM, Hari S. wrote:
Saludos
buscar soluciones, pero hay que tener en cuenta que quizas el
Un saludo,
Pero cabe recordar que la mayoria de lenguajes han pasado por ahí.
¿Nadie se acuerda de cuando había que ejecutar PHP con un cgi??
control estan haciendo lo mismo.
de
Web frameworks and web hosts
Emili Parreño
http://www.abecedata.com
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
Ror-es mailing list
[email protected]
http://lists.simplelogica.net/mailman/listinfo/ror-es
–
name. Francesc E. i Martí
voice. +34 678.681.603
Yo creo que el problema es que el stack estándar de Rails en un
entorno de producción (apache|nginx) + mongrel requiere mucha
másmemoria RAM que un Apache con mod_ruby y sus FastCGIs, que es lo que
tienen ahora.
No sé a qué niveles os movéis vosotros de tamaño de mongrels, pero yo
creo que no se libran de que cada instancia les ocupe entre 60 y
120Mb, y eso si tienen suerte y el programa que ejecutan no hace
alguna locura.
Y eso se pelea con su estrategia de overselling, y ya se les hace casi
imposible.
Yo sinceramente estoy pasando mis aplicaciones Rails de Dreamhost a
Slicehost y estoy encantado.
Saludos!
2008/1/10 Francesc E. [email protected]:
Fernando B. wrote:
Y eso se pelea con su estrategia de overselling, y ya se les hace casi
imposible.
Bueno, nadie da duros a cuatro pesetas.
Yo debo de ser uno de los pocos clientes satisfechos con Dreamhost… no
creo que nadie en su sano juicio intente poner una aplicación en
producción en DH, pero para los primeros pasos es adecuado (creo yo).
Vamos, mi blog (sobrerailes.com) me parece que tira razonablemente bien.
La cuestion aqui es si esos “primeros pasos” son suficientemente faciles
de dar o se ponen muy cuesta arriba. Con PHP, podias crear tu primera
paginilla, subirla via FTP y echarla a andar en 3 minutos. Con Rails
tienes que tener una base mas bien sólida de Unix y lÃnea de comandos
para poner la aplicacion “viva” en la red Esto es una realidad, pero
ocurre lo mismo con Java y nadie se rasga tampoco las vestiduras.
Saludos.