¿Alguien puede explicar el verdadero panorama de la implementación de Rails vs PHP, particularmente en el contexto del alojamiento web basado en revendedores (por ejemplo, Hostgator)?


15

Actualmente, tengo una cuenta de revendedor con la compañía HostGator. Diseño sitios web, que hasta ahora ocasionalmente se han incluido en Wordpress CMS y similares (aplicaciones PHP). Luego vendo alojamiento (del sitio que he diseñado) al cliente, lo cual es bastante simple, ya que simplemente puedo hacer clic en un botón y agregar una nueva cuenta / sitio de alojamiento compartido con la configuración que desee. Además, luego utilizo WHMCS para automatizar la facturación y la administración de cuentas.

Es un paquete agradable y bastante simple. Pago algo así como $ 25 al mes, y puedo vender cien cuentas con esto (porque los requisitos de ancho de banda de mis clientes son bajos).

Ahora encuentro la necesidad de desarrollar aplicaciones más personalizadas, incluido un CMS minimalista y varias cosas patentadas. Pronto anticipo desarrollar estas aplicaciones para clientes también. Por lo tanto, pasé los últimos meses aprendiendo Rails, y ahora me está yendo bien.

Sin embargo, lo que me ha fastidiado todo el tiempo es el problema de implementación. No puedo envolver mi cerebro a su alrededor. Parece que todas las opciones populares (Heroku, etc.) tienen una buena automatización con git y están configuradas en "Rails Way". Lo entiendo (más o menos). Pero es terriblemente costoso ... un único banco de pruebas, un ayudante y la base de datos más barata (que dicen que es principalmente adecuada para pruebas) que no se limita a 5 MB cuesta $ 51. ¡Esto es para UNA aplicación! Agregue una base de datos de "producción" y obtendrá más de $ 200. Esto es como ... los mismos precios que conseguir un servidor en alguna parte, ¿verdad?

Mientras tanto, volviendo a lo que supongo es un entorno de alojamiento "tradicional" con Hostgator, su servidor solo tiene Ruby 1.8.7 y Rails 2.3.5 ... No Rails 3. AND, no Passenger (no es que realmente entienda la diferencia en CGI o mod_rails o lo que sea, pero dicen que Passenger es el más simple). ¿Debo entender que si construyo una aplicación en Rails 3, no se ejecutará en este host? Pero maldita sea, ya tengo estas cuentas en mi cuenta de revendedor, todas ejecutan HTML estático y / o PHP, ¿verdad? ¿Y ahora qué? ¿Cómo consigo todo esto bajo un techo simple (y asequible)?

Perdona mi ignorancia, pero no la entiendo. Administrar un VPS es genial y todo, pero implica aprender cosas de administración del servidor y seguridad ... Y es costoso. Entiendo que un revendedor compartido o revendedor "basado en el servidor" (perdón por la terminología) puede ser inadecuado para aplicaciones a gran escala que usan mucho ancho de banda ... Pero ¿qué pasa con aquellos de nosotros que estamos construyendo real (pero pequeño)? y aplicaciones de bajo ancho de banda (con Rails) y ¿quién quiere implementarlas de manera simple y económica, utilizando el mismo enfoque conceptual que PHP? Incluso después de aprender todo esto de Ruby and Rails durante meses, me pregunto si vale la pena cuando se trata de la implementación. Quiero crear una pequeña aplicación, subirla a mi directorio de inicio en una cuenta de servidor compartida y simplemente hacer que se ejecute. ¿Por qué debería ser tan difícil? ¿Estoy eligiendo el lenguaje / marco incorrecto?

Perdona mi ignorancia en el tema; estas preguntas no son retóricas; Solo trato de aprender aquí.

Entonces:

1) Agradecería si alguien me pudiera dar un buen resumen de cómo entender la implementación en Rails vs. PHP.

2) Agradecería si alguien pudiera solucionar mi problema con la gestión de un negocio de alojamiento / web en torno al alojamiento de revendedores (Hostgator) y al mismo tiempo poder alojar aplicaciones Rails. Se puede hacer? ¿Y cómo puede una empresa como Hostgator ignorar por completo lo que está actual en Rails / Ruby?

Gracias.


2
+1 por no decir "¡Hola, alquilaré un VPS! No me piratearán porque tengo actualizaciones automáticas, ¿verdad?"
Pekka

44
@closevoters si tiene que cerrar el voto, al menos vote para migrarlo a serverfault o webmasters. Es una pregunta perfectamente buena, y no es discutidora en absoluto
Pekka

Respuestas:


9

Aunque el alojamiento de Rails probablemente nunca será tan económico como PHP, dado que los requisitos de infraestructura siempre son más altos, no es costoso alojar un sitio de Rails.

Se necesita una cierta cantidad de habilidad técnica para implementar adecuadamente un servidor basado en Linux y cargarlo en Rails y todas las bases de datos asociadas, pero esto no es un obstáculo insuperable. Cualquier programador competente probablemente podría ponerse al día en unas pocas semanas con solo unas pocas horas al día y un buen libro de referencia. Este es el tipo de cosas que es valioso saber de todos modos, ya que le ayuda a ajustar su entorno de implementación.

Muchos sistemas de alojamiento Rails "listos para usar" son caros. EngineYard , Joyent y Heroku son excelentes ejemplos de eso, pero en todos los casos tienen una prima sobre la alternativa autohospedada.

Si tiene un cliente que puede pagar esta prima, vale la pena aprovechar su experiencia. Si tiene un presupuesto muy ajustado, es posible que no pueda justificar esto.

La menos costosa solución de alojamiento de Rails que conozco que funciona es usar Linode con una distribución estándar combinada con Passenger . Con algunos ajustes básicos, nada especialmente difícil, puede alojar un sitio de pequeña a mediana escala incluso en su oferta más económica. Una máquina con 512 MB de memoria normalmente puede alojar dos o tres sitios Rails con poca carga o uno ocupado. Por ligera carga me refiero a cientos de visitantes por día. Ocupado es de miles a decenas de miles.

De hecho, he tenido tantos problemas con el alojamiento compartido de PHP que no vale la pena ahorrar costos para hacerlo de esa manera. En cambio, tengo varios sistemas VPS en Linode que son específicamente para hosting PHP, blogs de WordPress, por lo general, y funcionan muy bien. Aunque es posible que le moleste que tenga que entrar y parchear las máquinas de vez en cuando, al menos puede programar eso y anticipar posibles problemas en lugar de estar a merced de su proveedor.

Las empresas de alojamiento de productos básicos a menudo rompen las cosas accidentalmente y la restauración del servicio puede ser un proceso lento de tickets de problemas y llamadas telefónicas.

La implementación de cualquier aplicación, Rails o de otro tipo, tiene que ver con el flujo de trabajo. Muchas herramientas orientadas a Ruby como Capistrano y Chef pueden hacer que la administración de aplicaciones sea mucho más fácil que un enfoque manual.

Mi opinión sobre Rails: puede ser un poco más caro, pero es mucho más fácil de administrar una vez que te acostumbras a las herramientas y automatizas tu flujo de trabajo.


1
Una buena visión general sobre cómo alojar rieles, +1. Lo que pasa con el autohospedaje es que tienes que ser algo bueno en eso, reservar algo de tiempo para cuidar tu caja con frecuencia y saber qué hacer cuando esto sucede en medio de la noche. Eso es lo que siempre me mantuvo alejado de eso
Pekka

5

No es una respuesta a su pregunta, pero para ser honesto, mi impulso inicial cuando leí sobre la configuración de su negocio fue: "¿Por qué no se queda solo con PHP?"

No me malinterpreten: estoy seguro de que Ruby es un lenguaje hermoso, y Rails es un gran marco y gran parte es superior en muchos aspectos a PHP. También es genial para un desarrollador explorar nuevos campos, etc., etc.

Pero desde una perspectiva puramente comercial, PHP podría decirse "dónde está" para tres cosas importantes en este momento:

  • Alojamiento barato y

  • Software CMS para todos los gustos, tamaños, niveles de habilidad y requisitos y colores favoritos. Algunos de ellos son incluso utilizables hasta la mitad, y

  • Desarrolladores asequibles, algunos de ellos incluso a mitad de camino.

Entonces, si fuera usted, investigaría si sus requisitos se pueden cumplir con PHP primero.

De lo contrario, +1 por hacer una pregunta muy reflexiva, y será interesante ver los resultados. Yo he visto los carriles de alojamiento asequible pero es pocos y distantes entre sí.


Parece que PHP está a mitad de camino en cada recuento según su descripción. Realmente no es tan malo en lo que respecta al medio ambiente, y desde una perspectiva comercial, aparte de la codificación, es solo un componente para otro. El tipo de desarrolladores que tiene disponibles podría ser el factor determinante aquí.
tadman

Gracias. Espero no haber comenzado una guerra con esta pregunta, y que no se convierta en eso. Solo trato de entender esto desde la perspectiva de un negocio y de un aspirante a desarrollador (sin ningún apego real a ningún lenguaje o paradigma en particular).

@rcd de nada. Lo único es que esta pregunta podría ser mejor en Serverfault.com o Webmasters.SE: si cinco personas votan en consecuencia, se migrará automáticamente allí.
Pekka

Suena bien; Mantendré esos sitios en mente de ahora en adelante; si debo hacer algo para moverlo allí (o simplemente volver a publicarlo allí), hágamelo saber; Es posible que no tenga conocimiento de tal característica.

3

He encontrado un muy buen host compartido de rails: webfaction . Estoy muy contento con eso. ¡Echale un vistazo! Los precios son increíblemente bajos, ofrecen instaladores de un solo clic para rieles, la cantidad de sitios que puede alojar es ilimitada. ¡Su versión de rieles más alta es 3.0.5! :) Tiene acceso ssh a su recurso compartido, por lo que tiene control total, puede implementarlo utilizando capistrano o hacer cosas a mano en el servidor. Realmente asombroso.

Su documentación es realmente buena, y tienen un foro de soporte muy activo, para todas las demás preguntas.


1

Una buena solución para este viejo problema es Digital Ocean .

Implementamos una aplicación Rack y no es tan difícil. El precio comienza en $ 5 / mes / aplicación.

Tienen una aplicación de un solo clic para Rails que debería facilitar las cosas.

Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.