Question Pourquoi les gens utilisent Heroku quand AWS est présent? Qu'est-ce qui distingue Heroku d'AWS?


Je suis un programmeur RoR débutant qui prévoit de déployer mon application en utilisant Heroku. Le mot de mes autres amis conseillers me dit que Heroku est vraiment facile à utiliser. Le seul problème est que je n'ai toujours aucune idée de ce que fait Heroku ...

J'ai regardé leur site Internet et en un mot, ce que fait Heroku est d'aider à la mise à l'échelle mais ... pourquoi est-ce important? Comment Heroku aide-t-il:

  1. Rapidité - Ma recherche a laissé entendre que le déploiement d'AWS sur la côte est des États-Unis serait le plus rapide si je ciblais un public basé aux États-Unis et en Asie.

  2. Sécurité - Quel est leur niveau de sécurité?

  3. Mise à l'échelle - Comment cela fonctionne-t-il réellement?

  4. Rentabilité - Il y a quelque chose comme un dyno qui le rend facile à mettre à l'échelle.

  5. Comment se comportent-ils contre leurs concurrents? Par exemple, Cour de moteur et boite bleue?

S'il vous plaît utiliser des termes anglais laïques pour expliquer ... Je suis un programmeur débutant.


971
2018-03-21 10:00


origine


Réponses:


AWS / Heroku sont tous deux gratuits pour les petits projets de loisir (pour commencer).

Si vous voulez démarrer une application tout de suite, sans beaucoup de personnalisation de l'architecture, choisissez Heroku.

Si vous voulez vous concentrer sur l'architecture et pouvoir utiliser différents serveurs Web, choisissez AWS. AWS prend plus de temps en fonction du service / produit que vous choisissez, mais peut en valoir la peine. AWS est également livré avec de nombreux services et produits de plugin.


Heroku

  • Plate-forme en tant que service (PAAS)
  • Bonne documentation
  • A intégré des outils et de l'architecture.
  • Contrôle limité sur l'architecture lors de la conception de l'application.
  • Le déploiement est pris en charge (via les commandes git uniquement).
  • Pas de temps.

AWS

  • L'infrastructure en tant que service (IAAS)
  • Polyvalent - a de nombreux produits tels que EC2, LAMBDA, EMR, etc.
  • Peut utiliser une instance Dedicated pour plus de contrôle sur l'architecture, comme le choix du système d'exploitation, de la version du logiciel, etc. Il y a plusieurs couches backend.
  • Elastic Beanstalk est une fonctionnalité similaire au PAAS d'Heroku.
  • Peut utiliser le déploiement automatisé ou lancer le vôtre.

133
2017-10-05 08:46



Tout d'abord, AWS et Heroku sont des choses différentes. AWS offre l'infrastructure en tant que service (IaaS) considérant qu'Heroku offre une plateforme en tant que service (PaaS).

Quelle est la différence? Très approximativement, IaaS vous donne les composants dont vous avez besoin pour construire des choses dessus; PaaS vous offre un environnement où vous ne faites que pousser le code et une configuration basique pour obtenir une application en cours d'exécution. IaaS peut vous donner plus de puissance et de flexibilité, au prix d'avoir à construire et à maintenir plus vous-même.

Pour que votre code s'exécute sur AWS et ressemble un peu à un déploiement Heroku, vous aurez besoin de certaines instances EC2 - vous aurez besoin d'un calibreur de charge / couche de mise en cache installé dessus (par ex. Vernis), vous aurez besoin d'instances exécutant quelque chose comme Passager et nginx pour servir votre code, vous devez déployer et configurer une instance de base de données en cluster de quelque chose comme PostgreSQL. Vous voulez un système de déploiement avec quelque chose comme Capistranoet quelque chose faisant l'agrégation de journal.

Ce n'est pas une quantité insignifiante de travail à mettre en place et à maintenir. Avec Heroku, l'effort requis pour arriver à ce genre d'étape est peut-être quelques lignes de code d'application et un git push.

Donc vous êtes si loin, et vous voulez passer à l'échelle. Génial. Vous utilisez Fantoche pour votre déploiement EC2, non? Alors maintenant, vous configurez vos fichiers Capistrano pour faire tourner les instances de haut en bas si nécessaire; vous re-jig votre config Puppet afin que Varnish soit au courant des instances du web-worker et qu'il les mette automatiquement en pool. Ou toi heroku scale web:+5.

J'espère que cela vous donne une idée de la comparaison entre les deux. Maintenant, pour répondre à vos points spécifiques:

La vitesse

Actuellement, Heroku ne fonctionne que sur les instances AWS us-east et eu-west. Pour vous, cela ressemble à ce que vous voulez de toute façon. Pour d'autres, c'est potentiellement plus une considération.

Sécurité

J'ai vu beaucoup de serveurs de production maintenus en interne qui sont très en retard sur les mises à jour de sécurité ou qui sont généralement mal assemblés. Avec Heroku, vous avez quelqu'un d'autre qui gère ce genre de choses, ce qui est soit une bénédiction soit une malédiction selon la façon dont vous le regardez!

Lorsque vous déployez, vous transmettez votre code directement à Heroku. Cela peut être un problème pour vous. Leur article sur Dyno Isolation détaille leurs technologies d'isolation (il semble que plusieurs dynos sont exécutés sur des instances EC2 individuelles). Plusieurs collègues ont exprimé des problèmes avec ces technologies et la force de leur isolement; Je ne suis hélas pas dans une position de suffisamment de connaissance / expérience pour vraiment commenter, mais mes déploiements actuels d'Heroku considèrent que c'est "assez bon". Cela peut être un problème pour vous, je ne sais pas.

Mise à l'échelle

J'ai abordé la façon dont on pourrait mettre en œuvre ceci dans ma comparaison IaaS vs PaaS ci-dessus. Environ, votre application a un Procfile, qui a des lignes de la forme dyno_type: command_to_run, par exemple (à partir de http://devcenter.heroku.com/articles/process-model):

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

Ceci, avec un:

heroku scale web:2 worker:10

se traduira par vous avoir 2 web dynos et 10 worker dynos en cours d'exécution. Nice, simple, facile. Notez que web est un type dyno spécial, qui a accès au monde extérieur, et qui est derrière son bon multiplexeur de trafic Web (probablement une sorte de combinaison Varnish / nginx) qui acheminera le trafic en conséquence. Vos employés interagissent probablement avec une file d'attente de messages pour un routage similaire, à partir duquel ils obtiendront l'emplacement via une URL dans l'environnement.

Rapport coût-efficacité

Beaucoup de gens ont beaucoup d'opinions différentes à ce sujet. Actuellement, c'est 0,05 $ / h pour une heure dyno, contre 0,025 $ / h pour une micro-instance AWS ou 0,09 $ / h pour une petite instance AWS.

Heroku documentation dyno dit que vous avez environ 512 Mo de RAM, donc ce n'est probablement pas aussi déraisonnable de considérer un dyno comme un peu comme une micro-instance EC2. Cela vaut-il le double du prix? Combien appréciez-vous votre temps? La quantité de temps et d'efforts nécessaires pour construire au-dessus d'une offre IaaS pour l'obtenir à cette norme n'est certainement pas bon marché. Je ne peux pas vraiment répondre à cette question pour vous, mais ne sous-estimez pas les «coûts cachés» de l'installation et de la maintenance.

(Un peu à part, mais si je me connecte à un dyno d'ici (heroku run bash), un regard rapide montre 4 noyaux dans /proc/cpuinfo et 36 Go de RAM - ce qui me conduit à croire que je suis sur un "Instance Double Extra Large Mémoire Haute". Le Heroku documentation dyno dit que chaque dyno reçoit 512 Mo de RAM, donc je partage potentiellement avec jusqu'à 71 autres dynos. (Je n'ai pas assez de données sur l'homogénéité des instances AWS d'Heroku, donc votre salaire peut varier))

Comment se comportent-ils contre leurs concurrents?

Ceci, j'ai peur de ne pas pouvoir vraiment vous aider. Le seul concurrent que j'ai jamais regardé était Google App Engine - Au moment où je cherchais à déployer des applications Java, et le montant des restrictions sur les cadres et les technologies utilisables était incroyablement rebutant. C'est plus que "juste une chose de Java" - le montant des restrictions générales et des considérations nécessaires (la FAQ conseils à plusieurs) semblait moins que pratique. En revanche, le déploiement à Heroku a été un rêve.

Conclusion

J'espère que cela répondra à vos questions (veuillez commenter s'il y a des lacunes / d'autres domaines que vous aimeriez aborder). Je pense que je devrais offrir ma position personnelle. J'aime Heroku pour les "déploiements rapides". Quand je lance une application, et que je veux un hébergement bon marché (le niveau gratuit Heroku est génial - essentiellement si vous avez seulement besoin d'un dyno web et 5 Mo de PostgreSQL, c'est gratuit pour héberger une application), Heroku est ma position . Pour "Serious Production Deployment" avec plusieurs clients payants, avec un accord de niveau de service, avec du temps consacré aux opérations, et cetera, je ne peux pas me résoudre à décharger autant de contrôle sur Heroku, puis sur AWS ou nos propres serveurs ont été la plate-forme d'hébergement de choix.

En fin de compte, il s'agit de ce qui fonctionne le mieux pour vous. Vous dites que vous êtes "un programmeur débutant" - il se peut que l'utilisation de Heroku vous permette de vous concentrer sur l'écriture de Ruby, et que vous n'ayez pas à passer du temps à rassembler toutes les autres infrastructures autour de votre code. Je vais certainement essayer.


Notez qu'AWS a effectivement une offre PaaS, Beanstalk élastique, qui prend en charge Ruby, Node.js, PHP, Python, .NET et Java. Je pense généralement que la plupart des gens, quand ils voient "AWS", sautent à des choses comme EC2 et S3 et EBS, qui sont certainement des offres IaaS


1953
2018-03-21 10:57



Comme Kristian Glass l'a dit, il n'y a pas de comparaison entre IaaS (AWS) et PaaS (Heroku, EngineYard).

PaaS aide les développeurs à accélérer le développement de l'application, économisant de l'argent et surtout innovant dans leurs applications et leurs activités au lieu de configurer des configurations et de gérer des choses comme des serveurs et des bases de données. D'autres fonctionnalités permettant d'utiliser PaaS sont le processus de déploiement des applications, comme l'agilité, la haute disponibilité, la surveillance, l'échelle / détartrage, le besoin limité d'expertise, le déploiement facile et la réduction des coûts et du temps de développement.

Mais il y a toujours un côté obscur pour PaaS qui fait obstacle à l'adoption de PaaS:

  • Moins de contrôle sur le serveur et les bases de données
  • Les coûts seront très élevés s'ils ne sont pas gérés correctement
  • Prématurée et douteuse au jour et à l'âge actuels

En dehors de ci-dessus, vous devriez avoir assez de compétences pour gérer votre IaaS:

  • Acquisition de matériel
  • Système opérateur
  • Logiciel serveur
  • Environnement de script côté serveur
  • serveur Web
  • Système de gestion de base de données (Mysql, Redis, etc.)
  • Configurer le serveur de production
  • Outil de test et de déploiement
  • Application de surveillance
  • La haute disponibilité
  • Charge Blancing / Http Routing
  • Stratégies de sauvegarde de service
  • La collaboration d'équipe
  • Reconstruire la production

Si vous avez une entreprise à petite échelle, PaaS sera la meilleure option pour vous:

  • Payez comme vous allez
  • Faible coût de démarrage
  • Laissez la plomberie à l'expert
  • PaaS gère la mise à l'échelle / le détartrage automatique, l'équilibrage de charge, la reprise après sinistre
  • PaaS gère toutes les exigences de sécurité
  • PaaS gère la fiabilité, la haute disponibilité
  • Paas gère de nombreux add-ons tiers pour vous

Ce sera un choix totalement individuel basé sur l'exigence. Vous pouvez avoir des détails sur mon PPT Applications Rails d'hébergement.


57
2018-02-04 07:52



Il y a de nombreuses façons d'examiner cette décision à partir des objectifs de développement, de TI et d'affaires, alors ne vous sentez pas mal si cela vous semble écrasant. Mais aussi - ne pas trop penser à l'évolutivité.

Pensez à votre exigences.

J'ai conçu des sites Web qui ont traité plus de 8 millions d'utilisateurs uniques par jour et livré des téraoctets de vidéos par semaine, construits sur des infrastructures à partir de 250 000 dollars de matériel informatique par un énorme personnel de TI.

Mais j'ai également eu de plus petits sites Web qui ont été conçus pour générer 10 à 20 000 $ par an, ne nécessitaient pas beaucoup de trafic, de base de données ou de traitement, et je les exploitais sans compromis.

À l'avenir, le déploiement ressemblera plus à Heroku qu'AWS, simplement à cause des progrès. Il n'y a aucune valeur dans le bouton IT: le tournage des infrastructures Internet évolutives n'est pas de plus en plus automatisable, et rien de tout cela n'a de rapport avec la valeur du produit ou du service que vous proposez.

Gardez à l'esprit un site Web commercial - l'évolutivité est ce que nous appelons souvent un «bon problème à avoir» - bien que les problèmes d'évolutivité avec des sites comme Facebook et Twitter soient très médiatisés, ils n'ont eu aucun effet négatif sur leur succès. pourrait même avoir contribué à plus d'inscriptions (toute la presse est bonne presse).

Si vous avez un service qui génère 100k + uniques par jour et des problèmes de mise à l'échelle, je serais ravi de vous le retirer, quelle que soit la langue, la base de données, la plate-forme ou l'infrastructure utilisée!

L'évolutivité est un problème d'implémentation réparable - ne pas avoir de clients est un problème existentiel.


30
2018-02-16 17:31



En fait, vous pouvez utiliser les deux - vous pouvez développer une application avec Amazon serveurs ec2. Ensuite, poussez-le (avec git) à heroku gratuitement pendant un certain temps (utilisez le niveau gratuit Heroku pour le servir au public) et testez-le comme ça. Il est très rentable par rapport à la location d'un serveur, mais vous devrez parler avec une api d'heroku plus restrictive qui est quelque chose que vous devriez penser. Source: cette méthode a été adoptée pour l'une de mes classes en ligne "Startup engineering de Coursera / Stanford par Balaji S. Srinivasan et Vijay S. Pande

Added a scheme so my explanation will be easier to understand


30
2018-02-17 11:30



Les réponses existantes sont globalement précises:

  • Heroku est très facile à utiliser et à déployer, peut être facilement configuré pour le déploiement automatique d'un dépôt (par exemple GitHub), a beaucoup d'add-ons de tiers et charge plus par instance.

  • AWS dispose d'une gamme plus large de services de première partie à des prix compétitifs, y compris le DNS, l'équilibrage de charge, le stockage de fichiers bon marché et possède des fonctionnalités d'entreprise comme la possibilité de définir des politiques de sécurité.

Pour le tl; dr passez à la fin de ce post.

AWS ElasticBeanstalk est une tentative de fournir une plate-forme autoscaling de type Heroku et une plate-forme de déploiement facile. Comme il utilise des instances EC2 (qu'il crée automatiquement), les serveurs EB peuvent faire tout ce que n'importe quelle autre instance EC2 peut faire et c'est bon marché à exécuter.

Le déploiement avec EB est très lent. le déploiement d'une mise à jour peut prendre entre 10 et 15 minutes par serveur et le déploiement sur un cluster plus important peut prendre la meilleure partie d'une heure - comparé à quelques secondes pour déployer une mise à jour sur Heroku. Les déploiements sur EB ne sont pas gérés de façon particulièrement transparente non plus, ce qui peut imposer des contraintes sur la conception de l'application.

Vous pouvez utiliser tous les services qu'ElasticBeanstalk utilise en coulisses pour créer votre propre système sur mesure (avec CodeDeploy, Elastic Load Balancer, Groupes de mise à l'échelle automatique - et CodeCommit, CodeBuild et CodePipeline si vous voulez tout faire), mais vous pouvez certainement dépenser Deux semaines de mise en place la première fois car il est assez compliqué et légèrement plus compliqué que de simplement configurer des choses dans EC2.

AWS Lightsail offre une option d'hébergement à un prix compétitif, mais n'aide pas au déploiement ou à la mise à l'échelle - c'est juste un emballage pour leur offre EC2 (mais coûte beaucoup plus cher). Il vous permet d'exécuter automatiquement un script bash lors de la configuration initiale, ce qui est agréable, mais il est coûteux comparé au coût de la simple configuration d'une instance EC2 (que vous pouvez également faire par programmation).

Quelques réflexions sur la comparaison (pour tenter de répondre aux questions, mais de façon détournée):

  1. Ne sous-estimez pas la quantité d'administration du système de travail, y compris la mise à jour de tout ce que vous avez installé avec les correctifs de sécurité (et les mises à jour occasionnelles du système d'exploitation).

  2. Ne sous-estimez pas les avantages d'un déploiement automatique, d'une mise à l'échelle automatique et de l'approvisionnement et de la configuration SSL.

    Le déploiement automatique lorsque vous mettez à jour votre référentiel Git est facile avec Heroku. Il est presque instantané, gracieux donc il n'y a pas d'indisponibilité pour les utilisateurs finaux et peut être mis à jour uniquement si les tests / Intégration Continue réussissent à ne pas casser votre site si vous déployez du code cassé.

    Vous pouvez également utiliser ElasticBeanstalk pour le déploiement automatique, mais préparez-vous à passer une semaine à la première fois. Vous devrez peut-être modifier la manière dont vous déployez et créez des ressources (CSS et JS) pour gérer ElasticBeanstalk. dans votre application pour gérer les déploiements.

    Soyez conscient de l'estimation des coûts que pour un déploiement transparent sans interruption sur EB, vous devez exécuter plusieurs instances - EB déploie des mises à jour sur chaque serveur individuellement afin que votre service ne soit pas dégradé - où Heroku crée un nouveau dyno pour vous et désapprouve l'ancien service jusqu'à ce que toutes les demandes soient traitées (il le supprime ensuite).

    Fait intéressant, le coût d'hébergement de plusieurs serveurs avec EB peut être moins cher qu'une seule instance Heroku, surtout une fois que vous avez inclus le coût des add-ons.

Quelques autres questions non spécifiquement posées, mais soulevées par d'autres réponses:

  1. Utiliser un autre fournisseur pour la production et le développement est une mauvaise idée.

    Je regrette que les gens suggèrent cela. Bien qu'idéalement le code fonctionne correctement sur toute plate-forme raisonnable afin qu'il soit aussi portable que possible, les versions des logiciels sur chaque hôte varieront considérablement et simplement parce que le code s'exécute en staging ne signifie pas qu'il fonctionnera en production (par exemple Node.js / Les versions de Ruby / Python / PHP / Perl peuvent différer d'une manière qui rend le code incompatible, souvent de manière silencieuse et qui pourrait ne pas être détectée même si vous avez une couverture de test décente.

    Ce qui est une bonne idée est de tirer parti de quelque chose comme Heroku pour le prototypage, les petits projets et les microsites - afin que vous puissiez construire et déployer les choses rapidement sans investir beaucoup de temps dans la configuration et la maintenance.

    Assurez-vous de prendre en compte le coût d'exécution des instances de production et de préproduction lors de la prise de décision, sans oublier le coût de réplication de l'environnement complet (y compris les services tiers tels que les magasins de données, l'installation et la configuration SSL, etc.) .

  2. Si vous utilisez AWS, méfiez-vous des instances préconfigurées AWS de la part de fournisseurs tels que Bitnami - ils constituent un cauchemar pour la sécurité. Ils peuvent exposer beaucoup d'applications notoirement vulnérables par défaut sans le mentionner dans la description.

    Envisagez plutôt d'utiliser simplement une distribution mainstream bien supportée, comme Ubuntu ou Debian (ou CentOS si vous avez besoin de support RPM).

    Remarque: L'offre Amazon a sa propre distribution appelée Amazon Linux, qui utilise RPM, mais elle est spécifique à EC2 et moins bien supportée par un logiciel tiers / open source.

  3. Vous pouvez également configurer une instance EC2 sur AWS (ou Lightsail) et configurer avec quelque chose comme flynn ou dokku dessus - sur lequel vous pouvez ensuite déployer plusieurs sites facilement, ce qui peut valoir la peine si vous maintenez beaucoup de services ou si vous voulez pouvoir créer de nouvelles choses facilement. Cependant, sa configuration n'est pas aussi automagique que l'utilisation d'Heroku et vous pouvez passer beaucoup de temps à la configurer et la maintenir (au point que j'ai trouvé le déploiement en utilisant Amazon clustering et Docker Swarm plus facile que de les configurer; YMMV).

J'ai utilisé des instances AWS EC (seules et en grappes), Elastic Beanstalk et Lightsail et Heroku en même temps en fonction des besoins du projet sur lequel je travaille.

Je déteste passer du temps à configurer les services, mais mon facture de Heroku serait de milliers par an si je l'utilisais pour tout et AWS travaille à une fraction du coût.

tl; dr

Si l'argent n'était jamais un problème j'utiliserais Heroku pour presque tout car c'est un énorme gain de temps - mais je voudrais toujours utiliser AWS pour des projets plus compliqués où j'ai besoin de la flexibilité et des services plus avancés qu'Heroku n'offre pas.

Le scénario idéal pour moi serait si ElasticBeanstalk fonctionnait plus comme Heroku - c'est-à-dire avec une configuration plus simple et un mécanisme de déploiement plus rapide et meilleur.

Un exemple de service qui est presque ça est now.sh, qui utilise réellement AWS en coulisse, mais rend les déploiements et les clusters aussi simples que sur Heroku (avec le SSL automatique, le DNS, les déploiements gracieux, la configuration et la gestion de clusters super faciles).

Je l'ai beaucoup utilisé pour l'application Node.js et les déploiements d'images Docker, la principale mise en garde est que les instances sont partagées (ce qui se reflète dans leur coût inférieur) et actuellement aucune option pour acheter des instances dédiées. Cependant, leur outil de déploiement Open Source 'now' peut également être utilisé pour déployer des instances dédiées sur AWS, Google Cloud et Azure.


22
2018-01-12 07:49



Eh bien, les gens posent généralement cette question: Heroku ou AWS quand ils commencent à déployer quelque chose.

Mon expérience d'utilisation de Heroku et AWS, voici mon examen rapide et la comparaison:

Heroku

  • Une commande pour déployer quels que soient les types de projets: Ruby on Rails, Nodejs
  • Tellement de 1 clic pour intégrer des plugins et des tiers: C'est super facile de commencer avec quelque chose.
  • Ne pas avoir d'auto-mise à l'échelle; cela signifie que vous devez augmenter / réduire manuellement
  • Le coût est élevé, en particulier lorsque le système a besoin de plus de ressources
  • Instance gratuite disponible
  • L'instance libre se met en veille si elle est inactive.
  • Centre de données: États-Unis et UE seulement
  • Peut plonger / accéder au niveau de la machine en utilisant Heroku run bash (Merci, MJafar Mash pour les conseils) mais c'est un peu limité! Vous n'avez pas un accès complet!
  • Ne pas besoin d'en savoir trop sur DevOps

AWS - EC2

  • Cela ressemble à une machine avec pré-config OS (ou pas), de sorte que vous devez installer un logiciel, une bibliothèque pour rendre votre site web / service en ligne.
  • Plugin et bibliothèque doivent être intégrés manuellement, ou script d'automatisation (script public et écrit par vous)
  • La mise à l'échelle automatique et l'équilibrage de charge sont les services pris en charge. Apprenez simplement comment configurer et intégrer à votre système
  • Le coût est assez bon marché, cela dépend des services et du nombre d'heures d'utilisation.
  • Il y a plusieurs heures gratuites pour les instances de T2.micro, mais généralement, vous payez quelques dollars chaque mois (si vous utilisez encore T2.micro)
  • Votre instance gratuite ne va pas dormir, disponible 24h / 24 et 7j / 7 (parce que vous pouvez payer pour cela :))
  • Centre de données: autour du monde. Choisissez la région qui vous convient le mieux.
  • Plongez dans le niveau de la machine. Donc vous pouvez en profiter
  • Quelques connaissances sur DevOps, mais ça va, Stackoverflow est utile là-bas!

AWS Elastic Beanstalk une alternative de Heroku, mais moins cher

  • Elastic Beanstalk a été annoncé comme une version bêta publique à partir de 2010; cela nous aide à travailler plus facilement avec le déploiement. Pour plus de détails s'il vous plaît aller ici

  • Beanstalk est gratuit, le coût que vous paierez sera pour les services que vous utilisez et le nombre d'heures d'utilisation.

  • J'utilise Elastic Beanstalk depuis longtemps, et je pense qu'il peut être le remplacement d'Heroku et moins cher!

Résumé

  • Heroku: Facile au début, GRATUIT par exemple, mais cher plus tard
  • AWS: Pas facile, heures libres disponibles, genre de moins cher, Beanstalk devrait être préoccupé d'utiliser

Donc, dans mon système actuel, j'utilise Heroku pour la mise en scène et Beanstalk pour la production!


20
2018-05-23 10:36



Il s'agit d'un pourcentage important de notre activité de migration de personnes d'Heroku vers AWS. Il y a des avantages à la fois pour les deux, mais cela devient désordonné sur Heroku après un certain temps ... une fois que vous avez besoin d'un certain niveau de complexité, ce n'est plus facile à maintenir avec les limitations d'Heroku.

Cela dit, il y a de plus en plus d'options pour avoir la facilité d'Heroku et la flexibilité d'AWS en étant sur AWS avec de superbes frameworks / outils.


6
2018-01-08 20:54



Chose amusante, Heroku utilise AWS sur le backend. Il enlève tous les frais généraux et fait la gestion de l'architecture sur EC2 pour vous. (A obtenu cette connaissance d'un ingénieur senior dans une grande entreprise lors d'une interview)


1
2018-03-07 01:33



Amazon Web Services (AWS) offre de nombreux services de IaaS à PaaS avec une fiabilité et une disponibilité de données et d'infrastructure de 99,9999999%. AWS offre l'automatisation de l'infrastructure ainsi que plusieurs outils permettant aux développeurs d'intégrer leur processus de déploiement d'applications.

D'autre part, Heroku est juste PaaS qui offre des services pour gérer votre plate-forme sur leur nuage. Il n'y a nulle part avec AWS qu'il s'agisse d'infrastructure ou de sécurité.


1
2018-06-02 03:57



Bien! J'observe Heroku est célèbre dans les développeurs naissants et naissants tandis que AWS a avancé le personnage du développeur. DigitalOcean est également un acteur majeur sur ce terrain. Cloudways a facilité la création de la pile de lampes en un clic sur DigitalOcean et AWS. Avoir tous les services et les mises à jour de paquets dans un clic est bien mieux que de tout faire manuellement.

Vous pouvez vérifier complètement ici: https://www.cloudways.com/blog/host-php-on-aws-cloud/


0
2017-08-26 14:39