gratis aws ruby-on-rails heroku amazon-web-services

ruby on rails - gratis - ¿Por qué la gente usa Heroku cuando AWS está presente? ¿Qué distingue a Heroku de AWS?



heroku storage (16)

¡Bien! El observador Heroku es famoso entre los desarrolladores incipientes y recién nacidos, mientras que AWS tiene una personalidad de desarrollador avanzado. DigitalOcean también es un jugador importante en este campo. Cloudways ha hecho mucho más fácil crear la pila de lámparas con un clic en DigitalOcean y AWS. Tener todos los servicios y actualizaciones de paquetes en un clic es mucho mejor que hacer todo manualmente.

Puede consultar completamente aquí: https://www.cloudways.com/blog/host-php-on-aws-cloud/

Soy un programador principiante de RoR que planea implementar mi aplicación utilizando Heroku. La noticia de mis otros amigos asesores dice que Heroku es realmente fácil, bueno de usar. El único problema es que todavía no tengo idea de lo que hace Heroku ...

He mirado su website y, en pocas palabras, lo que Heroku hace es ayudar con la escala, pero ... ¿por qué eso importa? ¿Cómo ayuda Heroku con:

  1. Velocidad: mi investigación implicó que la implementación de AWS en la costa este de los EE. UU. Sería la más rápida si me dirijo a una audiencia con base en los EE. UU. Y Asia.

  2. Seguridad - ¿Qué tan seguros son?

  3. Escalado - ¿Cómo funciona realmente?

  4. Eficiencia de costos: hay algo así como un dinamómetro que hace que sea fácil de escalar.

  5. ¿Cómo les va contra sus competidores? Por ejemplo, ¿ Engine Yard y bluebox ?

Por favor, use los términos en inglés de Layman para explicar ... Soy un programador principiante.

A veces, me pregunto por qué la gente compara AWS con Heroku. AWS es una IAAS (infraestructura como servicio) que habla claramente sobre qué tan robusto y calculador es el sistema. Heroku, por otro lado, es solo un SAAS, es básicamente una fracción de los servicios de AWS. Entonces, ¿por qué luchar con la configuración de AWS cuando puede enviar su primer producto al mejor uso de Heroku?

Heroku es gratis, simple y fácil de implementar casi todos los tipos de pilas en la web. Heroku está específicamente diseñado para evitar todas las molestias de enviar su aplicación a un servidor en vivo en menos de un momento.

Sin embargo, es posible que desee implementar su aplicación utilizando cualquiera de los tutoriales de ambas partes y comparar

AWS DOCS y Heroku Docs

AWS / Heroku son gratuitos para proyectos de pequeños pasatiempos (para empezar).

Si desea iniciar una aplicación de inmediato, sin mucha personalización de la arquitectura, elija Heroku .

Si desea centrarse en la arquitectura y poder utilizar diferentes servidores web, elija AWS . AWS consume más tiempo en función del servicio / producto que elija, pero puede valer la pena. AWS también viene con muchos servicios y productos de complementos.

Heroku

  • Plataforma como servicio (PAAS)
  • Buena documentacion
  • Tiene herramientas y arquitectura incorporadas.
  • Control limitado sobre la arquitectura mientras se diseña la aplicación.
  • La implementación está a cargo (solo a través de los comandos git).
  • No consume mucho tiempo.

AWS

  • Infraestructura como servicio (IAAS)
  • Versátil: tiene muchos productos como EC2, LAMBDA, EMR, etc.
  • Puede usar una instancia dedicada para tener más control sobre la arquitectura, como elegir el sistema operativo, la versión de software, etc. Hay más de una capa de fondo.
  • Elastic Beanstalk es una característica similar a la PAAS de Heroku.
  • Puede utilizar el despliegue automatizado, o rodar el suyo propio.

Amazon Web Services (AWS) ofrece una gran cantidad de servicios de IaaS a PaaS con un 99.9999999% de durabilidad y disponibilidad garantizada de datos e infraestructura. AWS ofrece automatización de infraestructura junto con varias herramientas para que los desarrolladores puedan canalizar su proceso de implementación de aplicaciones.

Por otro lado, Heroku es solo PaaS, que ofrece servicios para administrar su plataforma en su nube. AWS no se encuentra en ninguna parte, ya sea en infraestructura o seguridad.

Bueno, Heroku usa AWS en segundo plano, todo depende del tipo de solución que necesite. Si usted es un fanático de Linux y devops, no le preocupa crear VM desde cero, como seleccionar AMI al elegir las opciones de control, etc., puede optar por AWS. Si quieres hacer cosas en el nivel de la superficie sin tener esas nettigrities puedes ir con heroku.

Bueno, la gente suele hacer esta pregunta: Heroku o AWS cuando comienzan a implementar algo.

Mi experimento de usar tanto Heroku como AWS, aquí está mi rápida revisión y comparación:

Heroku

  • Un comando para implementar cualquier tipo de proyecto: Ruby on Rails, Nodejs
  • Tantos clics con 1 clic para integrar complementos y terceros: Es muy fácil comenzar con algo.
  • No tiene autoescala; eso significa que necesitas escalar arriba / abajo manualmente
  • El costo es caro, especialmente cuando el sistema necesita más recursos
  • Instancia gratuita disponible
  • La instancia gratuita se pone a dormir si está inactiva.
  • Centro de datos: solo EE. UU. Y UE
  • PUEDE zambullirse en / acceder al nivel de la máquina usando Heroku run bash (Gracias, MJafar Mash por el consejo) pero está limitado. ¡No tienes acceso completo!
  • No necesitas saber mucho sobre DevOps

AWS - EC2

  • Esto es como una máquina con sistema operativo de configuración previa (o no), por lo que necesita instalar un software, una biblioteca para que su sitio web / servicio esté en línea.
  • El complemento y la biblioteca deben integrarse manualmente, o el script de automatización (script público y escrito por usted)
  • El escalado automático y el equilibrador de carga son los servicios compatibles, simplemente aprenda cómo configurar e integrar su sistema
  • El costo es bastante bajo, depende de los servicios y la cantidad de horas que lo use
  • Hay varias horas libres para las instancias de T2.micro, pero por lo general, pagará unos pocos dólares cada mes (si aún usa T2.micro)
  • Tu instancia gratuita no se activará, disponible las 24 horas del día, los 7 días de la semana (porque puedes pagarla :))
  • Centro de datos: en todo el mundo. Elija la región que mejor se adapte a usted.
  • Sumérgete en el nivel de la máquina. Para que lo disfrutes
  • Algunos conocimientos sobre DevOps, pero está bien, ¡ es útil allí!

AWS Elastic Beanstalk una alternativa de Heroku, pero más barato

  • Elastic Beanstalk se anunció como beta pública a partir de 2010; Nos ayuda a que sea más fácil trabajar con la implementación. Para más detalles por favor vaya here

  • Beanstalk es gratis, el costo que pagará será por los servicios que use y la cantidad de horas de uso.

  • Uso Elastic Beanstalk durante mucho tiempo, ¡y creo que puede ser el reemplazo de Heroku y más barato!

Resumen

  • Heroku: Fácil al principio, instancia GRATUITA , pero caro después
  • AWS: no es fácil, hay horas libres disponibles, un poco más barato , Beanstalk debería preocuparse por el uso

¡Así que en mi sistema actual, uso Heroku para la puesta en escena y Beanstalk para la producción!

Como dijo Kristian Glass, no hay comparación entre IaaS ( AWS ) y PaaS ( Heroku , EngineYard ).

Básicamente, PaaS ayuda a los desarrolladores a acelerar el desarrollo de la aplicación, ahorrando dinero y, lo que es más importante, innovando sus aplicaciones y negocios en lugar de configurar configuraciones y administrar cosas como servidores y bases de datos. Otras características que compran para usar PaaS es el proceso de implementación de la aplicación, como agilidad, Alta disponibilidad, Monitoreo, Escala / Descalcificación, necesidad limitada de experiencia, implementación fácil y menor costo y tiempo de desarrollo.

Pero todavía hay un lado oscuro de PaaS que lleva la barrera a la adopción de PaaS:

  • Menos control sobre el servidor y las bases de datos
  • Los costos serán muy altos si no se rigen adecuadamente
  • Prematuro y dudoso en la época actual.

Aparte de lo anterior, deberías tener suficiente conjunto de habilidades para administrar IaaS:

  • Adquisición de hardware
  • Sistema operativo
  • Software de servidor
  • Entorno de secuencias de comandos del lado del servidor
  • Servidor web
  • Sistema de gestión de base de datos (Mysql, Redis, etc.)
  • Configurar servidor de producción
  • Herramienta para prueba y despliegue
  • Aplicación de monitoreo
  • Alta disponibilidad
  • Load Blancing / Http Routing
  • Políticas de copia de seguridad del servicio
  • Colaboración en equipo
  • Reconstruir la producción

Si tiene negocios de pequeña escala, PaaS será la mejor opción para usted:

  • Paga a medida que vas
  • Bajo costo de puesta en marcha
  • Deja la plomería al experto.
  • PaaS maneja la escala / descalcificación automática, el equilibrio de carga, la recuperación de desastres
  • PaaS gestiona todos los requisitos de seguridad.
  • PaaS gestiona la fiabilidad, alta disponibilidad
  • Paas gestiona muchos complementos de terceros para ti

Será una elección totalmente individual basada en el requerimiento. Puedes tener detalles sobre mis aplicaciones de PPT Hosting Rails .

En realidad, puede utilizar ambos: puede desarrollar una aplicación con servidores amazon ec2. Luego empújalo (con git) a heroku gratis por un tiempo (usa el nivel gratuito de heroku para servirlo al público) y pruébalo como tal. Es muy rentable en comparación con el alquiler de un servidor, pero tendrá que hablar con una heroku api más restrictiva, que es algo en lo que debería pensar. Fuente: este método fue adoptado para una de mis clases en línea "Ingeniería de inicio de Coursera / Stanford por Balaji S. Srinivasan y Vijay S. Pande

Ha sido un porcentaje significativo de nuestra gente que migra negocios de Heroku a AWS. Hay ventajas para ambos, pero Heroku se complica después de un tiempo ... una vez que necesitas un cierto nivel de complejidad, ya no es fácil mantenerlo con las limitaciones de Heroku.

Dicho esto, hay cada vez más opciones para tener la facilidad de Heroku y la flexibilidad de AWS al estar en AWS con grandes marcos / herramientas.

Hay muchas maneras diferentes de ver esta decisión desde el desarrollo, la TI y los objetivos empresariales, así que no se sienta mal si parece abrumador. Pero también - no pienses demasiado en la escalabilidad.

Piense en sus necesidades .

He diseñado sitios web que han prestado servicios a más de 8 millones de ejemplares al día y he entregado terabytes de video a la semana basados ​​en infraestructuras a partir de $ 250,000 en hardware de capital por parte de un enorme personal laboral de $ MM.

Pero también he tenido sitios web más pequeños que fueron diseñados para generar $ 10- $ 20k por año, no tenía requisitos de procesamiento, de db o de procesamiento muy altos, y los ejecuté en una cuenta de hospedaje genérica de $ 10 / mes sin compromiso.

En el futuro, la implementación se parecerá más a Heroku que a AWS, solo por el progreso. El valor de giro de las infraestructuras de Internet escalables no tiene un valor nulo, lo que no es cada vez más automatizable, y nada de esto tiene que ver con el valor del producto o servicio que está ofreciendo.

Además, tenga en cuenta un sitio web comercial: la escalabilidad es lo que a menudo llamamos un ''buen problema'', aunque los problemas de escalabilidad en sitios como Facebook y Twitter fueron muy importantes, no tuvieron ningún efecto negativo en su éxito: la noticia Incluso podría haber contribuido a más inscripciones (toda la prensa es buena prensa).

Si tiene un servicio que está generando más de 100,000 unidades al día y tiene problemas de escalado, ¡me encantaría quitárselo sin importar el idioma, la plataforma, la infraestructura o la infraestructura en la que se está ejecutando!

La escalabilidad es un problema de implementación corregible, no tener clientes es un problema existencial.

Las respuestas existentes son ampliamente precisas:

  • Heroku es muy fácil de usar e implementar, se puede configurar fácilmente para la implementación automática de un repositorio (por ejemplo, GitHub), tiene muchos complementos de terceros y cobra más por instancia.

  • AWS tiene una gama más amplia de servicios de primera calidad a precios competitivos que incluyen DNS, balanceo de carga, almacenamiento de archivos barato y tiene características empresariales como poder definir políticas de seguridad.

Para el tl; dr salta al final de este post.

AWS ElasticBeanstalk es un intento de proporcionar una plataforma de autoescalado y fácil implementación similar a Heroku. Como utiliza las instancias de EC2 (que crea automáticamente), los servidores de EB pueden hacer todo lo que cualquier otra instancia de EC2 puede hacer y es barato de ejecutar.

El despliegue con EB es muy lento; la implementación de una actualización puede demorar entre 10 y 15 minutos por servidor y la implementación en un clúster más grande puede tomar la mejor parte de una hora, en comparación con solo unos segundos para implementar una actualización en Heroku. Las implementaciones en EB tampoco se manejan de manera particularmente transparente, lo que puede imponer restricciones en el diseño de la aplicación.

Puede usar todos los servicios que ElasticBeanstalk utiliza en segundo plano para crear su propio sistema a la medida (con CodeDeploy, Elastic Load Balancer, Auto Scaling Groups, y CodeCommit, CodeBuild y CodePipeline si quiere hacerlo todo), pero definitivamente puede pasar un buen Un par de semanas configurándolo por primera vez, ya que es bastante complicado y un poco más complicado que solo configurar cosas en EC2.

AWS Lightsail ofrece una opción de alojamiento a precios competitivos, pero no ayuda con la implementación o la ampliación; en realidad es solo un contenedor para su oferta de EC2 (pero cuesta mucho más). Le permite ejecutar automáticamente un script de bash en la configuración inicial, que es un buen toque pero es costoso en comparación con el costo de solo configurar una instancia de EC2 (que también puede hacer mediante programación).

Algunas reflexiones sobre la comparación (para intentar responder a las preguntas, aunque de manera indirecta):

  1. No subestime la cantidad de trabajo que realiza la administración del sistema, incluido mantener todo lo que ha instalado actualizado con parches de seguridad (y actualizaciones ocasionales del sistema operativo).

  2. No subestime la ventaja de la implementación automática, el escalado automático y el aprovisionamiento y la configuración de SSL.

    El despliegue automático cuando actualiza su repositorio Git es fácil con Heroku. Es casi instantáneo, elegante, por lo que no hay interrupciones para los usuarios finales y se puede configurar para que se actualice solo si las pruebas / la integración continua pasan para que no rompa su sitio si implementa código roto.

    También puede usar ElasticBeanstalk para la implementación automática, pero prepárese para pasar una semana configurando la primera vez; es posible que tenga que cambiar la forma en que implementa y construye los activos (como CSS y JS) para trabajar con la forma en que ElasticBeanstalk maneja las implementaciones o la lógica de construcción. en su aplicación para manejar implementaciones.

    Tenga en cuenta al estimar los costos que, para una implementación sin interrupciones sin interrupciones en EB, necesita ejecutar varias instancias: EB implementa las actualizaciones de cada servidor de manera individual para que su servicio no se degrade, donde Heroku crea un nuevo dinamómetro para usted y desaprueba el servicio anterior hasta que todas las solicitudes se hayan procesado (luego se eliminará).

    Curiosamente, el costo de hospedaje de ejecutar múltiples servidores con EB puede ser más barato que una sola instancia de Heroku, especialmente una vez que se incluye el costo de los complementos.

Algunos otros problemas no se preguntan específicamente, pero se plantean en otras respuestas:

  1. El uso de un proveedor diferente para la producción y el desarrollo es una mala idea.

    Estoy temblando de que la gente está sugiriendo esto. Si bien lo ideal es que el código se ejecute bien en cualquier plataforma razonable para que sea lo más portátil posible, las versiones de software en cada host variarán enormemente y solo porque el código que se ejecuta en la preparación no significa que se ejecutará en producción (p. Ej., Node.js / Las versiones de Ruby / Python / PHP / Perl pueden diferir en formas que hacen que el código sea incompatible, a menudo en formas silenciosas que podrían no ser detectadas incluso si tiene una cobertura de prueba decente).

    Lo que es una buena idea es aprovechar algo como Heroku para crear prototipos, proyectos más pequeños y micrositios, para que pueda construir e implementar cosas rápidamente sin tener que invertir mucho tiempo en configuración y mantenimiento.

    Asegúrese de tener en cuenta el costo de ejecutar las instancias de producción y de preproducción al tomar esa decisión, sin olvidar el costo de replicar todo el entorno (incluidos servicios de terceros, como almacenes de datos / complementos, instalación y configuración de SSL, etc.) .

  2. Si utiliza AWS, desconfíe de las instancias preconfiguradas de AWS de proveedores como Bitnami, ya que son una pesadilla de seguridad. Pueden exponer muchas aplicaciones notoriamente vulnerables de forma predeterminada sin mencionarlo en la descripción.

    En su lugar, considere usar solo una distribución general bien soportada, como Ubuntu o Debian (o CentOS si necesita soporte de RPM).

    Nota: la oferta de Amazon tiene su propia distribución llamada Amazon Linux, que utiliza RPM, pero es específica de EC2 y es menos compatible con software de terceros / fuente abierta.

  3. También puede configurar una instancia de EC2 en AWS (o Lightsail) y configurar con algo como flynn o dokku en él, en el que puede implementar múltiples sitios fácilmente, lo que puede valer la pena si mantiene muchos servicios o desea serlo. capaz de hacer girar cosas nuevas fácilmente. Sin embargo, configurarlo no es tan automático como usar Heroku y puede pasar mucho tiempo configurándolo y manteniéndolo (hasta el punto que encontré implementando el uso de Amazon clustering y Docker Swarm es más fácil que configurarlos; YMMV).

He usado instancias de EC de AWS (solo y en grupos), Elastic Beanstalk y Lightsail y Heroku al mismo tiempo, según las necesidades del proyecto en el que estoy trabajando.

Odio perder el tiempo configurando servicios, pero mi factura de Heroku sería de miles por año si lo usara para todo y AWS resulte una fracción del costo.

tl; dr

Si el dinero nunca fuera un problema, usaría Heroku para casi todo, ya que ahorra mucho tiempo, pero aún así quisiera usar AWS para proyectos más complicados donde necesito la flexibilidad y los servicios más avanzados que Heroku no ofrece.

El escenario ideal para mí sería si ElasticBeanstalk funcionara más como Heroku, es decir, con una configuración más sencilla y un mecanismo de implementación más rápido y mejor.

Un ejemplo de un servicio que es casi este es now.sh , que en realidad usa AWS detrás de la escena, pero hace que las implementaciones y el agrupamiento sean tan fáciles como lo es en Heroku (con SSL automático, DNS, implementaciones elegantes, configuración de clústeres súper fácil y administración).

Lo he usado bastante tanto para la aplicación Node.js como para las implementaciones de imágenes de Docker, la principal advertencia es que las instancias se comparten (algo que se refleja en su menor costo) y actualmente no hay opción para comprar instancias dedicadas. Sin embargo, su herramienta de implementación de código abierto ''ahora'' también se puede utilizar para implementar instancias dedicadas en AWS, así como en Google Cloud y Azure.

Lo curioso es que Heroku en realidad usa AWS en el backend. Quita todos los gastos generales y realiza la gestión de la arquitectura en EC2 para usted. (Obtuve ese conocimiento de un ingeniero senior en una gran compañía durante una entrevista)

Lo primero es lo primero, AWS y Heroku son cosas diferentes. AWS ofrece Infraestructura como un Servicio ( IaaS ) mientras que Heroku ofrece una Plataforma como un Servicio ( PaaS ).

¿Cual es la diferencia? Muy aproximadamente, IaaS le proporciona los componentes que necesita para construir cosas sobre ellos; PaaS le brinda un entorno en el que solo presiona código y alguna configuración básica y obtiene una aplicación en ejecución. IaaS puede darle más poder y flexibilidad, al costo de tener que construir y mantener más usted mismo.

Para que su código se ejecute en AWS y se vea un poco como una implementación de Heroku, querrá algunas instancias de EC2; querrá tener instalada una capa de almacenamiento / equilibrador de carga (por ejemplo, Varnish ), querrá instancias que ejecuten algo como Passenger y nginx para servir su código, querrá implementar y configurar una instancia de base de datos agrupada de algo como PostgreSQL . Querrá un sistema de implementación con algo como Capistrano y algo que haga agregación de registros.

Eso no es una cantidad insignificante de trabajo para configurar y mantener. Con Heroku, el esfuerzo requerido para llegar a ese tipo de escenario es quizás unas pocas líneas de código de aplicación y un git push .

Así que estás tan lejos y quieres escalar. Genial. Estás utilizando Puppet para tu despliegue de EC2, ¿verdad? Así que ahora configura sus archivos de Capistrano para las instancias de activación / desactivación según sea necesario; usted vuelve a ajustar su configuración de Puppet para que Varnish esté al tanto de las instancias de trabajadores web y se agrupará automáticamente entre ellas. O tu heroku scale web:+5 .

Esperemos que eso te dé una idea de la comparación entre los dos. Ahora para abordar sus puntos específicos:

Velocidad

Actualmente, Heroku solo se ejecuta en instancias de AWS en us-east y eu-west . Para ti, esto suena como lo que quieres de todos modos. Para otros, es potencialmente más una consideración.

Seguridad

He visto muchos servidores de producción mantenidos internamente que están muy atrasados ​​en las actualizaciones de seguridad, o simplemente en general mal organizados. Con Heroku, tienes a alguien más manejando ese tipo de cosas, que es una bendición o una maldición, ¡dependiendo de cómo lo mires!

Cuando implementas, efectivamente estás entregando tu código directamente a Heroku. Esto puede ser un problema para usted. Su artículo sobre Dyno Isolation detalla sus tecnologías de aislamiento (parece como si se ejecutaran múltiples dynos en instancias individuales de EC2). Varios colegas han expresado problemas con estas tecnologías y la fuerza de su aislamiento; Lamentablemente, no estoy en una posición de suficiente conocimiento / experiencia para realmente comentar, pero mis implementaciones actuales de Heroku lo consideran "suficientemente bueno". Puede ser un problema para ti, no lo sé.

Escalada

Me referí a cómo se podría implementar esto en mi comparación de IaaS vs PaaS anterior. Aproximadamente, su aplicación tiene un Procfile , que tiene líneas de la forma dyno_type: command_to_run , así que por ejemplo (cribbed from http://devcenter.heroku.com/articles/process-model ):

web: bundle exec rails server worker: bundle exec rake jobs:work

Esto, con un:

heroku scale web:2 worker:10

resultará en que tengas 2 dinosaurios web y 10 dinámicos de worker ejecución. Agradable, sencillo, fácil. Tenga en cuenta que la web es un tipo especial de dinamómetro, que tiene acceso al mundo exterior y está detrás de su agradable multiplexor de tráfico web (probablemente algún tipo de combinación de Barniz / nginx) que enrutará el tráfico en consecuencia. Sus trabajadores probablemente interactúan con una cola de mensajes para un enrutamiento similar, desde el cual obtendrán la ubicación a través de una URL en el entorno.

Eficiencia de costo

Mucha gente tiene muchas opiniones diferentes sobre esto. Actualmente cuesta $ 0.05 / hr por hora de dinamómetro, en comparación con $ 0.025 / hr para una micro instancia de AWS o $ 0.09 / hr para una instancia pequeña de AWS.

La documentación del dato de Heroku dice que tienes aproximadamente 512 MB de RAM, por lo que probablemente no sea demasiado irrazonable considerar un dino como un ejemplo de micro instancia de EC2. ¿Vale la pena el doble del precio? ¿Cuánto valoras tu tiempo? La cantidad de tiempo y esfuerzo requeridos para construir sobre una oferta de IaaS para llegar a este estándar definitivamente no es barata. Realmente no puedo responder esta pregunta por usted, pero no subestime los ''costos ocultos'' de la instalación y el mantenimiento.

(Un poco aparte, pero si me conecto a un dinamómetro desde aquí ( heroku run bash ), una mirada superficial muestra 4 núcleos en /proc/cpuinfo y 36GB de RAM. Esto me lleva a creer que estoy en un " Instancia extra grande doble de memoria alta " . La documentación del dino Heroku dice que cada dinamómetro recibe 512 MB de RAM, por lo que potencialmente estoy compartiendo con otros 71 dines. (No tengo suficientes datos sobre la homogeneidad de las instancias de Heroku AWS, por lo que su kilometraje puede variar))

¿Cómo les va contra sus competidores?

Esto, me temo que realmente no puedo ayudarte. El único competidor al que realmente he mirado fue el motor de aplicaciones de Google , en el momento en el que buscaba implementar aplicaciones Java, y la cantidad de restricciones en los marcos y tecnologías utilizables fue increíblemente desagradable. Esto es más que "solo una cosa de Java": la cantidad de restricciones generales y las consideraciones necesarias ( las sugerencias de preguntas frecuentes en varias) parecían menos convenientes. En contraste, desplegarse a Heroku ha sido un sueño.

Conclusión

Espero que esto responda a sus preguntas (por favor, comente si hay lagunas u otras áreas que le gustaría abordar). Siento que debo ofrecer mi posición personal. Me encanta Heroku para "despliegues rápidos". Cuando estoy iniciando una aplicación, y quiero un alojamiento barato (el nivel gratuito de Heroku es increíble, básicamente si solo necesitas un dinamómetro web y 5 MB de PostgreSQL, es gratis alojar una aplicación), Heroku es mi posición de acceso. . Para el "Despliegue de producción serio" con varios clientes que pagan, con un acuerdo de nivel de servicio, con un tiempo dedicado para invertir en operaciones, etc., no puedo dejar de descargar ese control a Heroku, y luego AWS o Nuestros propios servidores han sido la plataforma de hosting de elección.

En última instancia, se trata de lo que funciona mejor para usted. Dice que es un "programador principiante"; es posible que el uso de Heroku le permita concentrarse en escribir Ruby, y no tenga que dedicar tiempo a desarrollar toda la otra infraestructura alrededor de su código. Definitivamente lo probaría.

Tenga en cuenta que AWS realmente tiene una oferta de PaaS, Elastic Beanstalk , que admite Ruby, Node.js, PHP, Python, .NET y Java. Creo que en general la mayoría de las personas, cuando ven "AWS", saltan a cosas como EC2, S3 y EBS, que definitivamente son ofertas de IaaS.

Aunque tanto AWS como Heroku son plataformas en la nube, son diferentes, ya que AWS es IaaS y Heroku es PaaS.

bueno .. no es todo lo que es rosa ...

En primer lugar: AWS no es ciencia espacial, y si conoce cómo implementar "cosas" al final del día, es mejor usar AWS y más barato ... en lugar de cualquier otro PaaS que tiende a ser siempre más caro intercambio de hacer "cosas" por ti ... IMHO AWS es mucho mejor y tienes mucho más control en general,

especialmente ahora que hay rightScale, bitnami, etc ... y todas esas imágenes de EC2 creadas previamente para tantas pilas de software diferentes.