¿Por qué la gente usa Heroku cuando AWS está presente? ¿Qué distingue a Heroku de AWS? [cerrado]

Soy un programador principiante de RoR que planea implementar mi aplicación con 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 visto su sitio web y, en pocas palabras, lo que Heroku hace es ayudar con el escalado, pero ... ¿por qué eso importa? ¿Cómo ayuda Heroku con:

1. Velocidad: mi investigación implicaba 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 un público con sede en los EE. UU. / Asia.

2. Seguridad: ¿qué tan seguros son?

3. Escalado: ¿cómo funciona realmente?

4. Rentabilidad: hay algo así como un banco de pruebas que facilita la escala.

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

Utilice los términos en inglés para explicar ... Soy un programador principiante.

AWS / Heroku son gratuitos para pequeños proyectos de hobby (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 lleva más tiempo según el 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 documentación
• Tiene herramientas y arquitectura incorporadas.
• Control limitado sobre la arquitectura al diseñar la aplicación.
• La implementación se realiza (automática a través de GitHub o manual a través de comandos git o CLI).
• 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 del software, etc. Hay más de una capa de back-end.
• Elastic Beanstalk es una característica similar al PAAS de Heroku.
• Puede usar la implementación automatizada o rodar la suya.

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

¿Cual es la diferencia? Muy aproximadamente, IaaS le brinda los componentes que necesita para construir cosas sobre él; PaaS le brinda un entorno en el que simplemente inserta código y alguna configuración básica y obtiene una aplicación en ejecución. IaaS puede darle más potencia y flexibilidad, a costa de tener que construir y mantener más usted mismo.

Para que su código se ejecute en AWS y se parezca un poco a una implementación de Heroku, querrá algunas instancias EC2; querrá un equilibrador de carga / capa de almacenamiento en caché instalada en ellas (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 en clúster de algo como PostgreSQL . Querrá un sistema de implementación con algo como Capistrano , y algo que haga agregación de registros.

Esa no es una cantidad insignificante de trabajo para configurar y mantener. Con Heroku, el esfuerzo requerido para llegar a ese tipo de etapa es tal vez unas pocas líneas de código de aplicación y a git push.

Así que estás tan lejos y quieres escalar. Excelente. Estás utilizando Puppet para tu implementación de EC2, ¿verdad? Así que ahora configura sus archivos Capistrano para aumentar / disminuir las instancias según sea necesario; vuelve a mover la configuración de Puppet para que Varnish conozca las instancias de los trabajadores web y se agrupe automáticamente entre ellas. O usted 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-easty 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 en general mal ensamblados. Con Heroku, tienes a alguien más manejando ese tipo de cosas, ¡lo cual es una bendición o una maldición dependiendo de cómo lo mires!

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

Escalada

Toqué 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 del formulario dyno_type: command_to_run, por ejemplo (citado desde 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 tenga 2 webdynos y 10 workerdynos corriendo. Agradable, simple, fácil. Tenga en cuenta que webes un tipo de dinamómetro especial, 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 Varnish / nginx) que enrutará el tráfico en consecuencia. Sus trabajadores probablemente interactúen con una cola de mensajes para un enrutamiento similar, del 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 una hora dyno, en comparación con $ 0.025 / hr para una micro instancia de AWS o $ 0.09 / hr para una pequeña instancia de AWS.

La documentación del dinamómetro de Heroku dice que tiene aproximadamente 512 MB de RAM, por lo que probablemente no sea demasiado irrazonable considerar un dinamómetro como un poco como una micro instancia EC2. ¿Vale el doble del precio? ¿Cuánto valoras tu tiempo? La cantidad de tiempo y esfuerzo necesarios 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 configuración y el mantenimiento.

(Un poco aparte, pero si me conecto a un banco de pruebas desde aquí ( heroku run bash), un aspecto superficial muestra 4 núcleos /proc/cpuinfoy 36 GB de RAM; esto me lleva a creer que estoy en una "Instancia doble extra grande de alta memoria" " . La documentación del dinamómetro de Heroku dice que cada dinamómetro recibe 512 MB de RAM, por lo que potencialmente estoy compartiendo con hasta otros 71 dinamómetros.

¿Cómo les va a sus competidores?

Esto, me temo que realmente no puedo ayudarte. El único competidor que he visto realmente fue Google App Engine , en el momento en 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 cuestión de Java": la cantidad de restricciones generales y las consideraciones necesarias ( las preguntas más frecuentes sugieren varias) parecían menos que convenientes. En contraste, desplegarse en Heroku ha sido un sueño.

Conclusión

Espero que esto responda a sus preguntas (comente si hay lagunas / otras áreas que le gustaría abordar). Siento que debería ofrecer mi posición personal. Amo a Heroku por "despliegues rápidos". Cuando estoy iniciando una aplicación, y quiero un alojamiento barato (el nivel gratuito de Heroku es increíble, esencialmente si solo necesita un dinamómetro web y 5MB 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 tiempo dedicado para gastar en operaciones, etc., no puedo descargar ese control en Heroku, y luego AWS o nuestros propios servidores han sido la plataforma de alojamiento elegida.

En definitiva, se trata de lo que funciona mejor para usted. Dices que eres "un programador principiante", puede ser que usar Heroku te permita concentrarte en escribir Ruby y no tengas que perder el tiempo construyendo toda la infraestructura alrededor de tu código. Definitivamente lo probaría.

Tenga en cuenta que AWS en realidad 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 y S3 y EBS, que definitivamente son ofertas de IaaS

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 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 costos reducidos y tiempo de desarrollo.

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

• Menos control sobre el servidor y las bases de datos
• Los costos serán muy altos si no se gobiernan adecuadamente
• Prematuro y dudoso en el día y edad actuales

Además de lo anterior, debe tener suficientes 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 bases de datos (Mysql, Redis, etc.)
• Configurar servidor de producción
• Herramienta para pruebas y despliegue
• Aplicación de monitoreo
• Alta disponibilidad
• Blanqueo de carga / Enrutamiento HTTP
• Políticas de respaldo de servicio
• Colaboración en equipo
• Reconstruir producción

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

• Paga lo que consumas
• Bajo costo inicial
• Deje la fontanería a un experto
• PaaS maneja escalado / descalcificación automáticos, equilibrio de carga, recuperación ante desastres
• PaaS gestiona todos los requisitos de seguridad
• PaaS gestiona la fiabilidad, alta disponibilidad
• Paas gestiona muchos complementos de terceros para usted

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

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

Piensa en tus requisitos .

He diseñado sitios web que han prestado servicio a más de 8 millones de usuarios únicos al día y han entregado terabytes de video a la semana basados ​​en infraestructuras a partir de $ 250k en hardware de capital, bajo la supervisión de un enorme personal de trabajo de TI de $ MM.

Pero también tuve sitios web más pequeños que fueron diseñados para generar $ 10- $ 20k por año, no tenían un tráfico muy alto, db o requisitos de procesamiento, y los ejecuté en una cuenta de alojamiento genérico de $ 10 / mes sin compromiso.

En el futuro, la implementación se parecerá más a Heroku que a AWS, solo por el progreso. Hay un valor cero en el giro de perillas de TI para escalar las infraestructuras de Internet que no es cada vez más automatizable, y nada de eso tiene nada 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 con sitios como Facebook y Twitter eran de alto perfil, no tuvieron ningún efecto negativo en su éxito. incluso podría haber contribuido a más registros (toda la prensa es buena prensa).

Si tiene un servicio que genera más de 100k únicos al día y tiene problemas de escala, ¡me alegraría quitárselo de encima sin importar el idioma, la base de datos, la plataforma o la infraestructura en la que se esté ejecutando!

La escalabilidad es un problema de implementación solucionable: no tener clientes es un problema existencial.

En realidad, puede usar ambos: puede desarrollar una aplicación con los servidores de Amazon ec2. Luego, empújalo (con git) a heroku gratis por un tiempo (usa el nivel libre de heroku para servirlo al público) y pruébalo así. Es muy rentable en comparación con alquilar un servidor, pero tendrá que hablar con una api heroku más restrictiva, que es algo en lo que debe 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

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

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

Heroku

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

AWS - EC2

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

AWS Elastic Beanstalk, una alternativa a Heroku, pero más barata

• Elastic Beanstalk se anunció como una versión beta pública desde 2010; nos ayuda a trabajar más fácilmente con la implementación. Para más detalles, vaya aquí

• 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 costosa más tarde
• AWS: no es fácil, hay horas libres disponibles, es un poco más barato , Beanstalk debería preocuparse por usar

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

Las respuestas existentes son ampliamente precisas:

• Heroku es muy fácil de usar e implementar, se puede configurar fácilmente para el despliegue automático 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, equilibrio de carga, almacenamiento de archivos barato y tiene características empresariales como poder definir políticas de seguridad.

Para el tl; dr salte al final de esta publicación.

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

La implementación con EB es muy lenta; 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 fluida, lo que puede imponer restricciones en el diseño de la aplicación.

Puede usar todos los servicios que ElasticBeanstalk usa detrás de escena para construir su propio sistema a medida (con CodeDeploy, Elastic Load Balancer, Auto Scaling Groups - y CodeCommit, CodeBuild y CodePipeline si quiere participar) pero definitivamente puede gastar 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 las cosas en EC2.

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

Algunas reflexiones sobre la comparación (para tratar de responder las preguntas, aunque de forma indirecta):

1. No subestimes cuánto es la administración del sistema de trabajo, incluido mantener actualizado todo lo que has instalado con parches de seguridad (y actualizaciones ocasionales del sistema operativo).

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

   La implementación automática 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 se pasan las pruebas / Integración continua para que no rompa su sitio si implementa un código roto.

   También puede usar ElasticBeanstalk para la implementación automática, pero prepárese para pasar una semana configurando eso por primera vez; es posible que tenga que cambiar la forma en que implementa y crea 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 y sin interrupciones en EB, necesita ejecutar varias instancias: EB implementa actualizaciones en cada servidor individualmente para que su servicio no se degrade, mientras que Heroku hace girar un nuevo banco de pruebas para usted y simplemente lo deja en desuso el servicio anterior hasta que se hayan procesado todas las solicitudes (luego lo elimina).

   Curiosamente, el costo de alojamiento 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.

Algunas otras cuestiones que no se preguntan específicamente, pero que surgen de otras respuestas:

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

   Me da pena que la gente sugiera esto. Si bien lo ideal es que el código se ejecute bien en cualquier plataforma razonable, por lo que es lo más portátil posible, las versiones de software en cada host variarán enormemente y solo porque el código se ejecute en etapas no significa que se ejecutará en producción (por ejemplo, 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 detectarse incluso si tiene una cobertura de prueba decente).

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

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

2. Si usa AWS, tenga cuidado con las instancias preconfiguradas de AWS de proveedores como Bitnami; son una pesadilla de seguridad. Pueden exponer muchas aplicaciones notoriamente vulnerables de forma predeterminada sin mencionarlo en la descripción.

   Considere en su lugar simplemente usar una distribución convencional bien soportada, como Ubuntu o Debian (o CentOS si necesita soporte RPM).

   Nota: La oferta de Amazon tiene su propia distribución llamada Amazon Linux, que usa RPM, pero es específica de EC2 y no está bien respaldada por un software de fuente abierta / de terceros.

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

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

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

tl; dr

Si el dinero nunca fuera un problema, usaría Heroku para casi todo, ya que es un gran ahorro de tiempo, pero todavía quiero 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 simplemente funcionara más como Heroku, es decir, con una configuración más fácil y un mecanismo de implementación más rápido y mejor.

Un ejemplo de un servicio que es casi esto es now.sh , que en realidad usa AWS detrás de escena, pero hace que las implementaciones y la agrupación sean tan fáciles como en Heroku (con SSL automático, DNS, implementaciones elegantes, configuración de clúster 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 advertencia principal es que las instancias se comparten (algo reflejado 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 en instancias dedicadas en AWS, así como en Google Cloud y Azure.

Ha sido un porcentaje significativo de nuestro negocio la migración de personas de Heroku a AWS. Ambos tienen ventajas, pero Heroku se vuelve complicado después de un tiempo ... una vez que necesita un cierto nivel de complejidad ya no es fácil de mantener con las limitaciones de Heroku.

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

Lo curioso es que Heroku realmente usa AWS en el backend. Elimina todos los gastos generales y gestiona la arquitectura en EC2 por usted. (Obtuve ese conocimiento de un ingeniero senior en una gran empresa durante una entrevista)

¡Bien! Observé que Heroku es famoso en desarrolladores incipientes y recién nacidos, mientras que AWS tiene una personalidad de desarrollador avanzada. DigitalOcean también es un jugador importante en este terreno. Cloudways ha facilitado mucho la creación de 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.

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

Bueno, Heroku usa AWS en segundo plano, todo depende del tipo de solución que necesite. Si usted es un núcleo de Linux y devops, no le preocupa crear vm desde cero, como seleccionar ami, elegir opciones de ubicación, etc., puede usar AWS. Si quieres hacer cosas a nivel de superficie sin tener esas redes, puedes ir con heroku.

Amazon Web Services (AWS) ofrece muchos servicios desde IaaS a PaaS con un 99.9999999% de durabilidad y disponibilidad de datos e infraestructura asegurados. AWS ofrece automatización de infraestructura junto con varias herramientas para que los desarrolladores canalicen 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 tiene nada que ver con la infraestructura o la seguridad.

A veces, me pregunto por qué la gente compara AWS con Heroku. AWS es un IAAS (infraestructura como servicio) que claramente dice cuán robusto y calculador es el sistema. Heroku, por otro lado, es solo un SAAS, básicamente es solo 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 primer uso con Heroku?

Heroku es gratuito, simple y fácil de implementar en la web, casi todos los tipos de pilas. 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

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

Heroku es como un subconjunto de AWS. Es solo una plataforma como servicio, mientras que AWS se puede implementar como cualquier cosa y en cualquier nivel.

La implementación depende de lo que requiera el negocio. Si encaja bien, úselo en consecuencia.