No soy un experto en estos términos, pero consideraré:
IaaS: cualquier empresa que me presta infraestructura, servidores básicos, redes y demás. No hay problemas inherentes aquí porque tendría acceso a la máquina y haría lo que quisiera. Puede enumerar cualquier proveedor de VPS o Amazon EC2.
PaaS: cualquier empresa de alojamiento web que me comparta sus recursos y me brinde soporte para abandonar mi aplicación y, con suerte, tenerla en funcionamiento. El más diferente es Heroku y Google App Engine, hasta cierto punto, los más comunes son Dreamhost o cualquier otra empresa de alojamiento web compartido.
- Cómo aprovisionar servidores en la nube (por ejemplo, Amazon, EC2) sin Puppet Enterprise
- ¿Cuál es el flujo de trabajo estándar para implementar aplicaciones de back-end en AWS?
- ¿Cuáles son las mejores comunidades de alojamiento en la nube?
- ¿Existe alguna adopción de la nube pública (IaaS) en las grandes empresas?
- ¿Qué tecnología debo aprender para conseguir un trabajo más rápido en India, Hadoop, cloud computing o Android?
Hay varios problemas al ejecutar RoR en un entorno compartido. El alojamiento web compartido tradicional basado en PHP o CGI se basa en la suposición de que las aplicaciones no son grandes, que los tiempos de recarga de código son bajos y que las aplicaciones inactivas se cierran fácilmente para no desperdiciar RAM durante demasiado tiempo. PHP es buen candidato. También significa que las aplicaciones que son demasiado complejas y que tardan demasiado en recargarse no son adecuadas para esos entornos.
RoR, por otro lado, se basa en un enfoque de servidor de aplicaciones, un proceso de larga duración. Matarlo y recargarlo es costoso. Se necesita más memoria. Por lo tanto, es difícil tenerlo en un entorno compartido de alto acceso. Java tiene los mismos problemas, por lo que, supongo, no se ve la adopción generalizada de Java en el alojamiento web compartido. Por lo tanto, una economía de escala, RoR y entornos similares probablemente no sean adecuados dólar por dólar, en comparación con PHP y tal. Significa que el mismo hardware que puede admitir 1000 sitios PHP solo puede tener 100 aplicaciones RoR.
Por lo tanto, para que se incorporen de la misma manera que PHP está en un entorno de alojamiento web compartido, Ruby tendría que cambiar significativamente. Tal vez el enfoque multi-vm donde podría ejecutar varias aplicaciones aisladas dentro de la misma VM. Java tiene algo en esta dirección.
O siga el camino de Heroku, suponiendo que los costos no disminuirán trivialmente, por lo que agregará más valor perceptible a sus clientes, también suponiendo que no será una corriente principal. Heroku sufre las mismas limitaciones, pero han agregado capas inteligentes de servicios que, por ejemplo, hacen que sea fácil agregar nuevos nodos horizontales sin esfuerzo, lo cual es una característica asesina para grandes sitios web con tráfico errático de clientes.
O incluso siga el enfoque de Google App Engine y comience a hackear las máquinas virtuales para que se comporten como desea, pero paralizándolas en el proceso. Incluso entonces no logrará adopciones de alojamiento web compartido de nivel PHP.
No hay una respuesta simple para eso. El modelo CGI permitió que los sitios web simples y las pequeñas aplicaciones web crecieran significativamente en entornos de alojamiento web compartidos, donde podría compartir los recursos de un solo hardware para tener miles de sitios web a la vez, en el supuesto de que la mayoría de ellos estarían inactivos la mayor parte del tiempo
El escenario suele ser este: la mayoría de los sitios web están inactivos la mayor parte del tiempo. La gente piensa que necesitarán súper servidores porque alcanzarán el nivel de tráfico de Twitter. Estan soñando El 99% de Internet está inactivo. Entonces, lo más probable es que un alojamiento web compartido muy simple sea más que suficiente para la mayoría.
Ahora el 1% restante, con alta demanda y alto tráfico es un grupo muy diferente. No hay una solución simple que se ajuste a todos. Amazon EC2 es un buen punto de partida para construir una solución de PaaS, luego terminas con servicios similares a Heroku, que son geniales. Luego comienza a ofrecer aún más servicios ortogonales, como mensajes asíncronos como Pusher.com. Amazon RDS para bases de datos distribuidas. Amazon S3 para compartir activos distribuidos. Y las aplicaciones web más exigentes serían una mezcla de servicios distribuidos.
Específicamente para Ruby on Rails, deberá tener soporte para muchos Rubies diferentes (desde 1.8.7, 1.9.2, JRuby, Rubinius y algunas versiones vanguardistas para las pruebas), tendría que ofrecer varias opciones de implementación (desde Passenger hasta Unicorn ), opciones de equilibrio de carga fáciles de mantener (HAProxy), configuración de host web fácil de administrar para nginx, opciones de almacenamiento en caché fáciles de conectar (Barniz para front-end, memcache para back-end), fácil de configurar RDBMS replicado (postgres o mysql) , idealmente con opciones de partición más fáciles de entender, luego también algunas bases de datos NoSQL replicadas y fáciles de escalar (Mongo, Couch, Redis, etc.). Todo eso respaldado por algunas comodidades, como un espejo Rubygems.org disponible para que su aplicación dependa. Heroku es el único que va en esa dirección. Todavía es demasiado costoso para los pequeños profesionales independientes, pero probablemente sea el precio correcto para nuevas empresas más serias y compañías que desean aprovechar las tecnologías de Ruby on Rails sin la molestia de mantener una infraestructura complicada.
Espero que más compañías vayan en la misma dirección.
