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

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).

¿Cuál es la diferencia? Muy aproximadamente, IaaS le da los componentes que necesita para construir cosas encima de él; PaaS le da un entorno donde solo empuja 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 a ti mismo.

Para que su código se ejecute en AWS y se parezca un poco a una implementación de Heroku, querrá algunas instancias de EC2: querrá un balanceador 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. Usted querrá un despliegue sistema con algo como Capistrano, y algo haciendo agregación de registro.

Eso 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 un git push.

Así que estás hasta aquí, y quieres escalar. Gran. Estás usando Puppet para tu implementación de EC2, ¿verdad? Así que ahora configura sus archivos Capistrano para girar instancias arriba / abajo según sea necesario; re-jig su configuración de marioneta para que Varnish sea consciente de las instancias de trabajo web y se agrupe automáticamente entre ellas. O usted heroku scale web:+5.

Esperemos que eso le 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 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 mucho de servidores de producción mantenidos internamente que están muy atrasados en las actualizaciones de seguridad, o simplemente generalmente mal ensamblados. 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 despliegues, 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 múltiples dynos se ejecutan en instancias EC2 individuales). 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 despliegues actuales de Heroku consideran que "lo suficientemente bueno". Puede ser un problema para ti, no lo sé.

Escala

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

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

Esto, con a:

heroku scale web:2 worker:10

Tendrá 2 web dynos y 10 worker dynos funcionando. Agradable, simple, fácil. Tenga en cuenta que web es un tipo dyno 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 de Barniz / nginx) que enrutará el tráfico en consecuencia. Sus trabajadores probablemente interactúa con una cola de mensajes para un enrutamiento similar, desde la que obtendrán la ubicación a través de una URL en el entorno.

Rentabilidad

Mucha gente tiene muchas opiniones diferentes sobre esto. Actualmente es de 0 0.05 / hr para una hora dyno, en comparación con $0.025/hr para una instancia de AWS micro o $0.09 / hr para una instancia de AWS small.

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

(Un poco aparte, pero si me conecto a un banco de potencia desde aquí (heroku run bash), una mirada superficial muestra 4 núcleos en /proc/cpuinfo y 36 GB de RAM-esto me lleva creer que estoy en una "Instancia Extra Grande Doble de Alta Memoria". La documentación de Heroku dyno dice que cada dyno recibe 512MB de RAM, así que potencialmente estoy compartiendo con hasta 71 dynos más. (No tengo suficientes datos sobre la homogeneidad de las instancias AWS de Heroku, por lo que su milage puede variar))

¿Cómo les va contra sus competidores?

Me temo que no puedo ayudarte con esto. El único competidor que realmente he mirado fue Google App Motor - en el momento en que estaba buscando para implementar aplicaciones Java, y la cantidad de restricciones en marcos utilizables y tecnologías era increíblemente desagradable. Esto es más que "solo una cosa de Java" - la cantidad de restricciones generales y consideraciones necesarias (las FAQ insinúan varias) parecía menos que conveniente. En contraste, desplegarse en Heroku ha sido un sueño.

Conclusión

Espero que esto responda a sus preguntas (por favor, comente si hay son lagunas / otras áreas que le gustaría abordar). Siento que debo ofrecer mi posición personal. Me encanta Heroku para "despliegues rápidos". Cuando estoy comenzando una aplicación, y quiero un alojamiento barato (el nivel gratuito de Heroku es increíble, esencialmente si solo necesita un banco de pruebas web y 5 MB de PostgreSQL, es gratis alojar una aplicación), Heroku es mi posición de referencia. Para "Implementación de producción seria" con varios clientes de pago, con un acuerdo de nivel de servicio, con tiempo dedicado para gastar en ops, et cetera, no me atrevo a descargar tanto control a Heroku, y luego AWS o nuestros propios servidores han sido la plataforma de alojamiento elegida.

En última instancia, se trata de lo que funciona mejor para usted. Dices que eres "un programador principiante" - podría ser que usar Heroku te permita enfocarte en escribir Ruby, y no tener que gastar tiempo en construir toda la infraestructura alrededor de tu código. Definitivamente lo intentaría.

Tenga en cuenta que AWS realmente tiene una oferta de PaaS, Elastic Beanstalk, que soporta Ruby, Node.js, PHP, Python,. NET y Java. Creo que generalmente 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 ).

PaaS básicamente ayuda a los desarrolladores a acelerar el desarrollo de aplicaciones,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 aplicaciones, como agilidad, Alta Disponibilidad, Monitoreo, Escalar / desincrustar, necesidad limitada de experiencia, fácil implementación y reducción de costos y tiempo de desarrollo.

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

• Menos Control sobre Servidores y bases de datos
• Los costos serán muy altos si no se gobiernan adecuadamente{[14]]}
• Prematuro y dudoso en el día y la edad actual

Aparte de lo anterior, debes tener suficiente conjunto de habilidades para administrarte IaaS:

• Hardware adquisición
• Sistema operativo
• Software de servidor
• Entorno de Scripting del Lado del Servidor
• Servidor web
• Sistema de Gestión de Bases de datos(Mysql, Redis, etc.)
• Configurar el servidor de producción
• Herramienta para pruebas y despliegue
• Aplicación de monitoreo
• Alta disponibilidad
• Carga Blancing / Enrutamiento Http
• Políticas de Copia de seguridad de Servicio
• Colaboración en equipo
• Reconstruir la producción

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

• Pay as you Go {[14]]}
• Bajo costo de puesta en marcha
• Deje la fontanería a experto
• PaaS maneja el escalado/descalcificación automático, el equilibrio de carga, la recuperación ante desastres
• PaaS gestiona todos los requisitos de seguridad
• PaaS gestiona fiabilidad, Alta Disponibilidad
• Paas administra muchos complementos de terceros para usted

Será una elección totalmente individual basado en el requisito. Puede tener detalles sobre mi PPT Hosting Rails Apps.

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

Piense en sus requisitos .

He diseñado sitios web que han mantenido más de 8 millones de unidades al día y entregado terabytes de video a la semana construidos en infraestructuras a partir de $250k en capital hardware unr por un enorme staff MM personal de trabajo de TI.

Pero también he tenido los sitios web más pequeños que fueron diseñados para generar $10-mo 20k por año, no tenían un tráfico muy alto, db o requisitos de procesamiento, y los ejecuté con una cuenta de alojamiento genérico de mo 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 la perilla de TI de escalar infraestructuras de Internet que no es cada vez más automatizable, y nada de esto tiene nada que ver con el valor del producto o servicio que están ofreciendo.

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

Si tiene un servicio que está generando más de 100k únicos al día y tiene problemas de escalado, me encantaría quitárselo ¡manos para usted 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 amazon servers ec2. Luego empújalo (con git) a heroku de forma gratuita durante un tiempo (usa heroku free tier para servirlo al público) y pruébalo de esta manera. 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 "Startup engineering de Coursera/Stanford por Balaji S. Srinivasan y Vijay S. Pande

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 parte 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 saltar al final de este post.

AWS ElasticBeanstalk es un intento de proporcionar una plataforma de escalado automático y fácil implementación 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 barato de ejecutar.

La implementación con EB es muy lenta; la implementación de una actualización puede tomar de 10 a 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 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 utilizar todos los servicios que ElasticBeanstalk utiliza entre bastidores para crear su propio sistema a medida (con CodeDeploy, Elastic Load Balancer, Auto Scaling Groups - y CodeCommit, CodeBuild y CodePipeline si desea hacerlo todo), pero definitivamente puede pasar un buen par de semanas configurándolo la primera vez, ya que bastante complicado y ligeramente más complicado que simplemente configurar cosas en EC2.

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

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

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

2. No subestime el beneficio que supone la implementación automática, el escalado automático y el aprovisionamiento y la configuración SSL.

   La implementación automática cuando actualizas tu repositorio Git es fácil con Heroku. Se es casi instantánea, elegante, por lo que no hay interrupciones para los usuarios finales y se puede configurar para actualizar solo si las pruebas / Integración Continua pasan, por lo que no rompe 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 configurándolo la 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 despliegue.

   Tenga en cuenta al estimar los costos que para una implementación perfecta sin interrupción en EB necesita ejecutar varias instancias - EB despliega actualizaciones a cada servidor individualmente para que su servicio no se degrade - donde Heroku gira un nuevo banco de pruebas para usted y simplemente desactiva el servicio anterior hasta que todas las solicitudes se realizan siendo manejadas (luego lo elimina).

   Curiosamente, el costo de alojamiento de ejecutar varios servidores con EB puede ser más barato que un solo Heroku instancia, especialmente una vez que se incluye el costo de los complementos.

Algunas otras cuestiones no específicamente preguntadas, pero planteadas por otras respuestas:

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

   Me estoy encogiendo 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 mucho y solo porque el código se ejecuta en la puesta en escena no significa que se ejecutará en producción (por ejemplo, nodo principal.las versiones de js/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 capturadas 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 la costo de ejecutar instancias de producción y 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 usa AWS, tenga cuidado con las instancias preconfiguradas de AWS de proveedores como Bitnami, ya que son una pesadilla para la seguridad. Pueden exponer muchas aplicaciones notoriamente vulnerables por defecto sin mencionarlo en la descripción.

   Considere 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 utiliza RPM, pero es específica de EC2 y menos soportada por software de terceros/código abierto.

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

He utilizado instancias de AWS EC (solas y en clústeres), 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 calculara 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í querría usar AWS para proyectos más complicados donde necesito la flexibilidad y más servicios 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 fácil y más rápida y un mejor mecanismo de implementación.

Un ejemplo de un servicio que es casi esto es now.sh , que en realidad usa AWS entre bastidores, pero hace que las implementaciones y la agrupación en clústeres sean tan fáciles como en Heroku (con SSL automático, DNS, implementaciones elegantes, configuración de clústeres súper fácil y gestión).

Lo he usado bastante para ambos nodos.las implementaciones de js app y Docker image, la advertencia principal 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 'now' también se puede usar para implementar en instancias dedicadas en AWS, así como en Google Cloud y Azure.

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

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

Heroku

• Un comando para implementar cualquiera que sea su tipo de proyecto: Ruby on Rails, Nodejs
• Tantos 1-click para integrar plugins y terceros: Es súper fácil comenzar con algo.
• No tiene escalado automático; eso significa que necesita escalar hacia arriba / hacia abajo manualmente
• El costo es caro, especialmente, cuando el sistema necesita más recursos
• Instancia gratuita disponible
• La instancia libre se pone en reposo si está inactiva.
• Centro de datos: solo en EE.UU. y la UE
• PUEDE sumergirse en / acceder al nivel de la máquina utilizando Heroku run bash (Gracias, MJafar Mash por el consejo), pero es un poco limitado! ¡No tienes acceso completo!
• No es necesario saber demasiado sobre DevOps

AWS-EC2

• Esto solo como una máquina con sistema operativo pre-config (o no), por lo que necesita instalar software, biblioteca para hacer que su sitio web/servicio vaya en línea.
• El complemento y la biblioteca deben integrarse manualmente, o el script de automatización (script público y escrito por usted)
• Auto scaling & load balancer son los servicios compatibles, solo aprenda a configurar e integrar en su sistema
• El costo es bastante barato, depende de los servicios y el número de horas que lo use
• Hay varias horas libres para T2.micro instancias, pero generalmente, pagará pocos dólares cada mes (si aún usa T2.micro)
• Su instancia gratuita no se va a dormir, disponible 24/7 (porque puede pagar por ella:))
• 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 de Heroku, pero más barato

• Elastic Beanstalk se anunció como beta pública a partir de 2010; nos ayuda a trabajar más fácilmente con la implementación. Para más detalles por favor ir aquí

• Las habichuelas mágicas son gratuitas, el costo que pagará será por los servicios que use y el número de horas de uso.

• Uso habichuelas mágicas elásticas durante mucho tiempo, y creo que puede ser el reemplazo de Heroku y más barato!

Resumen

• Heroku: Fácil al principio, LIBRE instancia, pero caro después
• AWS: No es fácil, horas libres disponibles, tipo de más barato , Habichuelas mágicas debe preocuparse de usar

Así que en mi sistema actual, uso Heroku para la puesta en escena y habichuelas mágicas para la producción!

Ha sido un porcentaje significativo de nuestro negocio migrar personas de Heroku a AWS. Hay ventajas para ambos, pero se vuelve desordenado en Heroku después de un tiempo... una vez que se 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 hace la gestión de arquitectura en EC2 por usted. (Obtuvo ese conocimiento de un ingeniero senior en una Gran Empresa durante una Entrevista)

Amazon Web Services (AWS) ofrece muchos servicios, desde IaaS hasta PaaS, con una durabilidad y disponibilidad de datos e infraestructura aseguradas del 99,9999999%. AWS ofrece automatización de la 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. En ninguna parte se encuentra con AWS, ya sea infraestructura o seguridad.

Bueno! Observo que Heroku es famoso en desarrolladores en ciernes 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 hecho que sea mucho más fácil crear Lamp stack con un clic en DigitalOcean y AWS. Tener todos los servicios y paquetes de actualizaciones en un clic es mucho mejor que hacer todo manualmente.

Usted puede comprobar hacia fuera completamente aquí: https://www.cloudways.com/blog/host-php-on-aws-cloud /

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

Heroku es gratis, simple y fácil de desplegar casi todos los tipos de pilas a la web. Heroku está diseñado específicamente para evitar todo 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

Bueno, Heroku usa AWS en segundo plano, todo depende del tipo de solución que necesite. Si usted es un chico de core linux y devops no está preocupado por crear vm desde cero como seleccionar ami elegir opciones de palcement, etc., puede ir con AWS. Si quieres hacer cosas a nivel de superficie sin tener esas nettigrities puedes ir con heroku.

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

He leído algunas respuestas acerca de que HEROKU y AWS son tan diferentes (la primera es Plataforma como Servicio y la segunda es Infra como Servicio. Para poner la comparación en perspectiva, amazon ofrece una solución PaaS llamada AWS Elastic Beanstalk. Para la comparación sobre ésos , compruebe por favor la URL abajo https://dzone.com/articles/heroku-or-amazon-web-services-which-is-best-for-your-startup

Bueno.. no es tan rosado..

En primer lugar: AWS no es una ciencia de cohetes, y si sabe cómo implementar "cosas" al final del día, es mejor usar AWS y más barato .. en lugar de cualquier otro PaaS que tienden a ser siempre más caros a cambio de hacer "cosas" para usted ... En mi humilde opinión AWS es mucho mejor y usted tiene mucho más control en general,

Especialmente ahora cuando hay RightScale, bitnami, etc... y todas esas imágenes EC2 pre hechas para tantos diferentes pilas de software.