Pregunta ¿Por qué las personas usan Heroku cuando AWS está presente? ¿Qué distingue a Heroku de AWS?


Soy un programador RoR principiante que planea implementar mi aplicación usando Heroku. La palabra 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 qué hace Heroku ...

He visto su sitio web y, en pocas palabras, lo que hace Heroku es ayudar a escalar, pero ... ¿por qué importa eso? ¿Cómo ayuda Heroku con:

  1. Velocidad: mi investigación implicaba que la implementación de AWS en la costa este de EE. UU. Sería la más rápida si mi objetivo es una audiencia basada en EE. UU. / Asia.

  2. Seguridad - ¿Cuán seguros son?

  3. Escala - ¿Cómo funciona realmente?

  4. Rentabilidad: hay algo así como un banco de pruebas que hace que sea fácil de escalar.

  5. ¿Cómo les va contra sus competidores? Por ejemplo, Patio del motor y caja azul?

Usa los términos en inglés para explicar ... soy un programador principiante.


971
2018-03-21 10:00


origen


Respuestas:


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

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

Si desea enfocarse en la arquitectura y poder usar diferentes servidores web, elija AWS. AWS consume 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 mientras se diseña la aplicación.
  • La implementación se realiza (solo a través de 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 back-end.
  • Elastic Beanstalk es una característica similar a la PAAS de Heroku.
  • Puede usar la implementación automatizada, o hacer su propia versión.

133
2017-10-05 08:46



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 proporciona los componentes que necesita para construir cosas encima; PaaS le brinda un entorno en el que solo debe presionar el código y alguna configuración básica y obtener una aplicación en ejecución. IaaS puede darle más poder 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 de EC2; querrá tener instalada una capa de balanceador de carga / almacenamiento en caché (p. Barniz), querrás instancias que ejecuten algo así como Pasajero y nginx para servir su código, querrá implementar y configurar una instancia de base de datos en clúster de algo así como PostgreSQL. Querrá un sistema de despliegue con algo así como Capistranoy algo que hace agregación de registros.

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

Así que estás tan lejos y quieres aumentar tu escala. Estupendo. Estás usando Marioneta para su despliegue de EC2, ¿verdad? Así que ahora configura sus archivos Capistrano para girar las instancias arriba / abajo según sea necesario; vuelve a ajustar la configuración de Puppet para que Varnish conozca las instancias del trabajador web y se agrupe automáticamente. O tu heroku scale web:+5.

Espero 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 retrasados ​​en las actualizaciones de seguridad o, por lo general, están mal integrados. 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 se despliega, efectivamente está entregando su código directamente a Heroku. Esto puede ser un problema para ti. Su artículo sobre Aislamiento Dyno detalla sus tecnologías de aislamiento (parece que múltiples dinnos 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 conocimiento / experiencia suficiente para comentar realmente, pero mis despliegues actuales de Heroku consideran que es "lo 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 IaaS vs PaaS anterior. Aproximadamente, su aplicación tiene una Procfile, que tiene líneas de la forma dyno_type: command_to_run, por ejemplo, (cifrado de 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

dará como resultado que tengas 2 web dynos y 10 worker dynos corriendo. Agradable, simple, fácil. Tenga en cuenta que web es un tipo de dinamómetro especial, que tiene acceso al mundo exterior, y está detrás de su simpático multiplexor de tráfico web (probablemente algún tipo de combinación de Varnish / nginx) que enrutará el tráfico en consecuencia. Es probable que sus trabajadores 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 / h para una hora dyno, en comparación con $ 0.025 / h para una micro instancia de AWS o $ 0.09 / h para una instancia pequeña de AWS.

Heroku documentación de dyno dice que tienes unos 512 MB de RAM, por lo que probablemente no sea también irrazonable considerar un dyno como un microinstancia EC2. ¿Vale la pena el doble de 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, 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 una "High-Memory Double Extra Large Instance". El Heroku documentación de dyno dice que cada dinamómetro recibe 512MB de RAM, así que estoy potencialmente compartiendo con hasta otros 71 dinamómetros. (No tengo suficientes datos sobre la homogeneidad de las instancias de AWS de Heroku, 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 que he visto realmente era Motor de aplicaciones de Google - 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 cosa de Java": la cantidad de restricciones generales y consideraciones necesarias (las preguntas frecuentes consejos a varios) parecía menos que conveniente. Por el contrario, desplegar a Heroku ha sido un sueño.

Conclusión

Espero que esto responda a sus preguntas (por favor coméntenos si hay lagunas / otras áreas que desea abordar). Siento que debería ofrecer mi posición personal. Amo a Heroku por "despliegues rápidos". Cuando estoy comenzando una aplicación, y quiero un hosting barato (el nivel gratuito de Heroku es impresionante, esencialmente si solo necesitas un dinamómetro web y 5MB de PostgreSQL, es libre de alojar una aplicación), Heroku es mi lugar de referencia . Para "Implementación de producción seria" con varios clientes que pagan, con un acuerdo de nivel de servicio, con tiempo dedicado a gastar en operaciones, etcétera, no me canso de descargar ese control a Heroku, y luego AWS o nuestros propios servidores han sido la plataforma de alojamiento preferida.

En definitiva, se trata de lo que funciona mejor para ti. Usted dice que es "un programador principiante"; podría ser que el uso de Heroku le permita centrarse en escribir Ruby, y no tener que gastar tiempo acumulando toda la otra infraestructura alrededor de su código. Definitivamente lo probaría.


Tenga en cuenta que AWS realmente tiene una oferta de PaaS, Beanstalk elástico, que es compatible con 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


1953
2018-03-21 10:57



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

PaaS básicamente ayuda a los desarrolladores a acelerar el desarrollo de la aplicación, ahorrando dinero y lo más importante innovando en sus aplicaciones y negocios en lugar de configurar configuraciones y administrar cosas como servidores y bases de datos. Otras características para comprar para usar PaaS es el proceso de implementación de la aplicación, como la agilidad, la alta disponibilidad, el monitoreo, la escala / descalcificación, la necesidad limitada de experiencia, la implementación sencilla y los costos reducidos y el tiempo de desarrollo.

Pero aún hay un lado oscuro de PaaS que lidera 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 la edad actuales

Además de lo anterior, deberías tener suficiente habilidad para administrar IaaS:

  • Adquisición de hardware
  • 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 prueba e implementación
  • Aplicación de monitoreo
  • Alta disponibilidad
  • Load Blancing / Http Routing
  • Políticas de respaldo del servicio
  • Colaboración en equipo
  • Reconstruir producción

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

  • Pague lo que consuma
  • Bajo costo de inicio
  • Deje la plomería a experto
  • PaaS maneja escalado / desincrustado automático, equilibrio de carga, recuperación ante desastres
  • PaaS gestiona todos los requisitos de seguridad
  • PaaS gestiona la fiabilidad, la alta disponibilidad
  • Paas administra muchos complementos de terceros para usted

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


57
2018-02-04 07:52



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

Piensa en tu requisitos.

He diseñado sitios web que han atendido más de 8 millones de unidades únicas al día y he entregado terabytes de video a la semana basados ​​en infraestructuras a partir de $ 250 mil en hardware de capital por un gran equipo de trabajo de TI $ 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ían requisitos de tráfico, db o procesamiento muy altos, y los ejecuté en una cuenta de hosting 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 la pericia informática de 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 que en 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 muy importantes, no tuvieron ningún efecto negativo en su éxito: las noticias podría tener incluso contribuido a más suscripciones (toda la prensa es buena prensa).

Si tiene un servicio que está generando más de 100k + por día y tiene problemas de escalado, me gustaría quitarlo de sus manos 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 reparable: no tener clientes es un problema existencial.


30
2018-02-16 17:31



En realidad, puede usar ambos; puede desarrollar una aplicación con Amazon servers ec2. Luego empújalo (con git) a heroku gratis por un tiempo (usa heroku free tier para servirlo al público) y pruébalo de esa manera. Es muy rentable en comparación con el alquiler de un servidor, pero tendrá que hablar con un heroku api más restrictivo, que es algo en lo que debe pensar. Fuente: este método fue adoptado para una de mis clases en línea. "Startup engineering from Coursera / Stanford by Balaji S. Srinivasan and Vijay S. Pande.

Added a scheme so my explanation will be easier to understand


30
2018-02-17 11:30



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 cargos más por instancia.

  • AWS tiene una gama más amplia de servicios de primera clase a precios competitivos que incluyen DNS, equilibrio de carga, almacenamiento de archivos económico y funciones empresariales como la capacidad de definir políticas de seguridad.

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

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

La implementación con EB es muy lenta; La implementación de una actualización puede demorar de 10 a 15 minutos por servidor y la implementación en un clúster más grande puede tomar la mayor parte de una hora, en comparación con solo unos segundos para implementar una actualización en Heroku. Los despliegues en EB tampoco se manejan de manera particularmente transparente, lo que puede imponer restricciones al diseño de la aplicación.

Puede utilizar todos los servicios que ElasticBeanstalk utiliza entre bastidores para crear su propio sistema personalizado (con CodeDeploy, Elastic Load Balancer, Grupos de escala automática - y CodeCommit, CodeBuild y CodePipeline si quiere incluirlo todo) pero definitivamente puede gastar un buen un par de semanas configurándolo por primera vez, ya que es bastante intrincado y un poco más complicado que simplemente configurar cosas en EC2.

AWS Lightsail ofrece una opción de alojamiento con precios competitivos, pero no ayuda con el despliegue o la ampliación: en realidad es solo un envoltorio 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 agradable, pero es costoso en comparación con el costo de simplemente configurar una instancia EC2 (que también puede hacer mediante programación).

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

  1. No subestime la cantidad de trabajo que se realiza en la administración del sistema, incluida la actualización de todo lo que tiene instalado 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.

    La implementación automática cuando actualiza su repositorio de 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 / integración continua pasan, por lo que no se rompe el sitio si se implementa un código dañado.

    También puede usar ElasticBeanstalk para la implementación automática, pero prepárese para pasar una semana configurándola por primera vez. Tal vez tenga que cambiar la forma de implementar y crear activos (como CSS y JS) para trabajar con ElasticBeanstalk en las implementaciones o la lógica de compilación. en su aplicación para manejar implementaciones.

    Tenga en cuenta al estimar los costos que para una implementación sin interrupciones en EB necesita ejecutar instancias múltiples: EB implementa las actualizaciones en cada servidor individualmente para que su servicio no se vea degradado, mientras Heroku activa un nuevo banco de pruebas para usted y lo desaprueba el servicio anterior hasta que se hayan procesado todas las solicitudes (luego lo borra).

    Curiosamente, el costo de alojamiento de ejecutar varios 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 temas no específicamente preguntados, pero planteados por otras respuestas:

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

    Me encoge pensar que la gente sugiera esto. Aunque lo ideal es que el código funcione correctamente en cualquier plataforma razonable para que sea lo más portátil posible, las versiones de software en cada host variarán enormemente y el hecho de que 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 de maneras 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 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 la configuración y el mantenimiento.

    Asegúrese de tener en cuenta el costo de ejecutar las 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; son una pesadilla de seguridad. Pueden exponer muchas aplicaciones notoriamente vulnerables por defecto sin mencionarlo en la descripción.

    Considere, en cambio, utilizar una distribución principal 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 usa RPM, pero es específica de EC2 y menos compatible con software de terceros o de código abierto.

  3. También podría configurar una instancia de EC2 en AWS (o Lightsail) y configurar algo parecido a flynn o dokku en él, en el que luego podría implementar múltiples sitios fácilmente, lo que puede valer la pena si mantiene muchos servicios o desea poder crear cosas nuevas fácilmente. Sin embargo, configurarlo no es tan automático como usar Heroku y puede terminar gastando mucho tiempo en configurarlo y mantenerlo (hasta el punto en que he encontrado que implementar utilizando clustering de Amazon y Docker Swarm es más fácil que configurarlo; YMMV).

He utilizado las instancias de AWS EC (solo y en clústeres), Elastic Beanstalk y Lightsail y Heroku al mismo tiempo, según 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 utilizo para todo y AWS soluciona una fracción del costo.

tl; dr

Si el dinero nunca fuera un problema, usaría Heroku para casi todo, ya que ahorrará mucho tiempo, pero igual me gustaría usar AWS para proyectos más complicados donde necesito la flexibilidad y 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 esto es ahora.sh, que en realidad utiliza AWS detrás de escena, pero hace que las implementaciones y la agrupación sean tan sencillas como en Heroku (con SSL automático, DNS, implementaciones elegantes, configuración y administración súper fáciles de clúster).

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 costo más bajo) y actualmente no hay ninguna opción para comprar instancias dedicadas. Sin embargo, su herramienta de implementación de código abierto 'ahora' también se puede usar para implementar en instancias dedicadas en AWS, así como en Google Cloud y Azure.


22
2018-01-12 07:49



Bueno, la gente generalmente hace esta pregunta: Heroku o AWS cuando comienzan a desplegar algo.

Mi experimento de utilizar tanto Heroku como AWS, esta es mi revisión y comparación rápida:

Heroku

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

AWS - EC2

  • Esto es como una máquina con sistema operativo preconfigurado (o no), por lo que necesita instalar software, biblioteca para hacer que su sitio web / servicio se conecte.
  • El complemento y la biblioteca deben estar integrados manualmente, o una secuencia de comandos de automatización (secuencia de comandos pública y escrita por usted)
  • El escalado automático y el equilibrador de carga son los servicios compatibles, solo aprenda a configurar e integrar a su sistema
  • El costo es bastante bajo, depende de los servicios y el número de horas que lo usa
  • Hay varias horas libres para las instancias de T2.micro, pero por lo general, pagará pocos dólares cada mes (si todavía está usando T2.micro)
  • Tu instancia gratuita no se irá a dormir, disponible 24/7 (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 puedas disfrutarlo
  • Algo de conocimiento sobre DevOps, pero está bien, ¡Stackoverflow es útil allí!

AWS Elastic Beanstalk una alternativa de 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 detalles, vaya aquí

  • Beanstalk es gratuito, el costo que pagará será por los servicios que usa y el número de horas de uso.

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

Resumen

  • Heroku: Fácil al principio, GRATIS instancia, pero costoso más tarde
  • AWS: no es fácil, hay horas gratis disponibles, tipo de más barato, Beanstalk debería preocuparse por usar

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


20
2018-05-23 10:36



Ha sido un porcentaje significativo de nuestra migración empresarial de personas de Heroku a AWS. Hay ventajas para ambos, pero se vuelve complicado en Heroku después de un tiempo ... una vez que necesitas 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 frameworks / herramientas.


6
2018-01-08 20:54



Lo gracioso es que Heroku realmente usa AWS en el back-end. Le quita todos los gastos generales y gestiona la arquitectura en EC2 por usted. (Obtuve ese conocimiento de un ingeniero superior en una gran empresa durante una entrevista)


1
2018-03-07 01:33



Amazon Web Services (AWS) ofrece muchos servicios desde IaaS hasta PaaS con una garantía de 99.9999999% de durabilidad y disponibilidad de datos e infraestructura. 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.


1
2018-06-02 03:57



¡Bien! El observador Heroku es famoso en los desarrolladores en ciernes y recién nacidos, mientras que AWS tiene una personalidad avanzada de desarrollador. Digital Ocean también es un jugador importante en este terreno. Cloudways ha hecho que sea mucho más fácil crear Lamp stack en un clic en DigitalOcean y AWS. Tener todas las actualizaciones de servicios y paquetes en un clic es mucho mejor que hacerlo todo manualmente.

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


0
2017-08-26 14:39