Pourquoi les gens utilisent-ils Heroku lorsque AWS est présent? Qu'est-ce qui distingue Heroku d'AWS? [fermé]


1102

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 dit que Heroku est vraiment facile, bon à utiliser. Le seul problème est que je n'ai toujours aucune idée de ce que fait Heroku ...

J'ai regardé leur site Web 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 avec:

  1. Vitesse - Mes recherches impliquent que le déploiement d'AWS sur la côte est des États-Unis serait le plus rapide si je cible un public américain / asiatique.

  2. Sécurité - Dans quelle mesure sont-ils sécurisés?

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

  4. Rentabilité - Il y a quelque chose comme un dynamo qui facilite la mise à l'échelle.

  5. Comment se comportent-ils face à leurs concurrents? Par exemple, Engine Yard et bluebox ?

Veuillez utiliser des termes anglais profanes pour expliquer ... Je suis un programmeur débutant.


267
Je l'utilise en fait à cause du plan gratuit;).
weddingcakes

56
Vous auriez dû demander quelle est la différence entre Heroku et AWS élastique beanstalk .. Sinon, vous obtiendrez les réponses habituelles "PaaS vs IaaS", pas ce que vous recherchez probablement.
Jus12

38
développer sur heroku, le mettre à l'échelle sur heroku, innover sur heroku ... puis une fois que l'idée est le succès de l'entreprise, puis transférer vers aws ... comme lorsque vous embauchez.
Muhammad Umer

10
Il peut être difficile de migrer une fois que vous utilisez quelques services et devez transférer, configurer, tout tester ... Cela aura certainement un coût
Paolo

37
Une de mes choses préférées à propos de Heroku est qu'il se déploie automatiquement depuis Github, donc je peux avoir une productionbranche sur mon dépôt. Chaque fois qu'un nouveau commit est poussé vers ce dépôt, Heroku le saisit automatiquement, le construit et le déploie. Je n'ai pas du tout à me soucier de quoi que ce soit côté serveur!
Razi Shaban

Réponses:


245

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

Si vous souhaitez démarrer une application immédiatement, sans beaucoup de personnalisation de l'architecture, choisissez Heroku .

Si vous souhaitez 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 plug-in.


Heroku

  • Plateforme en tant que service (PAAS)
  • Bonne documentation
  • Possède des outils et une architecture intégrés.
  • Contrôle limité de l'architecture lors de la conception de l'application.
  • Le déploiement est pris en charge (automatique via GitHub ou manuel via les commandes git ou CLI).
  • Pas de temps.

AWS

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

7
ElasticBeanstalk est beaucoup plus rentable que Heroku car il n'y a pas de balisage pour le service au-delà des serveurs que vous utilisez. Vous pouvez également utiliser ElasticBeanstalk avec le niveau gratuit AWS aws.amazon.com/elasticbeanstalk/pricing
Zags

25
@Zags "rentable" est une question d'opinion. Si je peux créer et déployer une application Heroku en moins d'une minute et qu'il faut potentiellement des heures pour configurer Beanstalk - ce n'est pas rentable étant donné que plusieurs heures de temps de développeur détruisent toutes les "économies" que Beanstalk pourrait avoir. Cela dépend vraiment des priorités - les fonctionnalités d'expédition sont-elles plus importantes ou la configuration et la maintenance des infrastructures sont-elles plus importantes?
Brian Dear

5
La facilité de configuration de @BrianDear dépend de votre connaissance des différents systèmes. Même si ElasticBeanstalk prend plus de temps à configurer, étant donné une familiarité égale, AWS représente généralement 60% du coût de Heroku (comparez un Heruku performance-m à un AWS m4.xlarge). Avec une facture de serveur aussi basse que 100 $ / mois, une économie de 40% permettra de récupérer le coût de "plusieurs heures d'ingénierie" en un an. Plus la facture du serveur est élevée, plus l'argument en faveur d'AWS est fort.
Zags

4
Il faut environ 5 minutes pour se déployer sur Beanstalk. Choisissez la plate-forme -> Téléchargez le zip -> Réjouissez-vous. Vous voulez déployer en poussant pour maîtriser? Passez encore 5 minutes à configurer CodePipeline. Ces deux workflows peuvent être effectués en utilisant uniquement la console GUI si la CLI est intimidante pour vous.
Anthony Manning-Franklin

1
Malheureusement, la documentation n'est pas répertoriée sous AWS. AWS possède l'une des meilleures documentations de toutes les technologies / plates-formes. Je l'avais utilisé avant même que cette réponse ne soit publiée, vers 2013.
lupchiazoem

2055

Tout d'abord, AWS et Heroku sont des choses différentes. AWS propose Infrastructure as a Service ( IaaS ) tandis que Heroku propose une plateforme as a Service ( PaaS ).

Quelle est la différence? Très approximativement, IaaS vous donne les composants dont vous avez besoin pour construire des choses par-dessus; PaaS vous offre un environnement dans lequel vous n'avez qu'à pousser du code et une configuration de base et obtenir une application en cours d'exécution. L'IaaS peut vous donner plus de puissance et de flexibilité, au prix d'avoir à construire et à entretenir davantage vous-même.

Pour faire fonctionner votre code sur AWS et ressembler un peu à un déploiement Heroku, vous aurez besoin de certaines instances EC2 - vous voudrez un équilibreur de charge / couche de mise en cache installé sur elles (par exemple Varnish ), vous voudrez des instances exécutant quelque chose comme Passager et nginx pour servir votre code, vous voudrez déployer et configurer une instance de base de données en cluster de quelque chose comme PostgreSQL . Vous voudrez un système de déploiement avec quelque chose comme Capistrano , et quelque chose faisant l'agrégation de journaux.

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

Vous êtes donc loin et vous souhaitez vous développer. Génial. Vous utilisez Puppet pour votre déploiement EC2, non? Alors maintenant, vous configurez vos fichiers Capistrano pour faire monter / descendre les instances selon vos besoins; vous redéfinissez votre configuration Puppet pour que Varnish soit au courant des instances de Web Worker et les regroupera automatiquement. Ou toiheroku scale web:+5 .

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

La vitesse

Actuellement, Heroku ne fonctionne que sur les instances AWS dans us-easteteu-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 loin derrière les mises à jour de sécurité, ou tout simplement mal assemblés. Avec Heroku, vous avez quelqu'un d'autre qui gère ce genre de chose, qui est soit une bénédiction soit une malédiction selon la façon dont vous le voyez!

Lorsque vous déployez, vous remettez efficacement votre code directement à Heroku. Cela peut être un problème pour vous. Leur article sur Dyno Isolation détaille leurs technologies d'isolement (il semble que plusieurs dynos soient 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 en position d'avoir suffisamment de connaissances / d'expérience pour vraiment commenter, mais mes déploiements Heroku actuels considèrent que "assez bien". Cela peut être un problème pour vous, je ne sais pas.

Mise à l'échelle

J'ai abordé la façon dont on pourrait implémenter cela dans ma comparaison IaaS vs PaaS ci-dessus. En gros, votre application possède un Procfile, qui comporte des lignes du formulaire dyno_type: command_to_run, par exemple (extrait de http://devcenter.heroku.com/articles/process-model ):

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

Ceci, avec:

heroku scale web:2 worker:10

entraînera l' webexécution de 2 dynos et 10 workerdynos. Nice, simple, facile. Notez que webc'est un type de dyno spécial, qui a accès au monde extérieur, et qui est derrière leur joli 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 de dyno, contre 0,025 $ / h pour une micro-instance AWS ou 0,09 $ / h pour une petite instance AWS.

La documentation du dyno de Heroku dit que vous avez environ 512 Mo de RAM, il n'est donc probablement pas trop déraisonnable de considérer un dyno comme un peu comme une micro-instance EC2. Vaut-il le double du prix? Combien appréciez-vous votre temps? Le temps et les efforts nécessaires pour s'appuyer sur une offre IaaS pour l'obtenir à ce niveau ne sont 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 la configuration et de la maintenance.

(Un peu de côté, mais si je me connecte à un dyno à partir d'ici ( heroku run bash), un aperçu rapide montre 4 cœurs /proc/cpuinfoet 36 Go de RAM - cela me porte à croire que je suis sur une "double instance extra-large à haute mémoire" " . La documentation du dyno Heroku indique 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 de Heroku, donc votre kilométrage peut varier))

Comment font-ils face à leurs concurrents?

Je crains de ne pouvoir vraiment vous aider. Le seul concurrent que j'ai jamais vraiment examiné était Google App Engine - à l'époque où je cherchais à déployer des applications Java, et la quantité de restrictions sur les cadres et technologies utilisables était incroyablement rebutante. C'est plus que "juste une chose Java" - la quantité de restrictions générales et de considérations nécessaires ( la FAQ suggère plusieurs) semblait moins que pratique. En revanche, le déploiement sur Heroku a été un rêve.

Conclusion

J'espère que cela répond à vos questions (veuillez commenter s'il y a des lacunes / d'autres domaines que vous souhaitez aborder). Je pense que je devrais offrir ma position personnelle. J'adore Heroku pour les "déploiements rapides". Lorsque je démarre une application et que je veux un hébergement bon marché (le niveau gratuit Heroku est génial - essentiellement si vous n'avez besoin que d'un dyno web et de 5 Mo de PostgreSQL, c'est gratuit pour héberger une application), Heroku est ma position de prédilection . Pour "Déploiement de production sérieux" avec plusieurs clients payants, avec un accord de niveau de service, avec du temps dédié à passer sur les 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 plateforme d'hébergement de choix.

En fin de compte, il s'agit de ce qui vous convient le mieux. 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 de ne pas avoir à passer du temps à construire toutes les autres infrastructures autour de votre code. J'essaierais certainement.


Remarque: AWS dispose en fait d'une offre PaaS, Elastic Beanstalk , qui prend en charge Ruby, Node.js, PHP, Python, .NET et Java. Je pense qu'en général, la plupart des gens, lorsqu'ils voient "AWS", passent à des choses comme EC2 et S3 et EBS, qui sont définitivement des offres IaaS


33
Notez que le haricot élastique maintenant prend entièrement en charge les applications rubis derrière le passager.
réécrit

4
Heroku prend désormais également en charge les serveurs dans l'UE et pas seulement dans la région des États-Unis.
Thomas Welton

7
Étant donné AWS BeanStalk, toute la discussion sur la façon dont Heroku est une solution PaaS alors qu'AWS est "juste" une offre IaaS n'est-elle pas invalidée?
Gmu

6
@KristianGlass Ce serait génial si nous pouvions obtenir une réponse mise à jour qui ressemble vraiment aux deux offres PaaS (Beanstalk et Heroku)
Alex Chumbley

3
Heureux que cela ait été utile aux gens :) @Gmu Au moment de répondre, EB était suffisamment limité pour que supposer que «AWS» signifiait «EC2» semblait tout à fait raisonnable, mais comme Alex le suggère, je vais envisager de répondre à nouveau maintenant EB a considérablement améliorée.
Kristian Glass

68

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

PaaS aide essentiellement les développeurs à accélérer le développement de l'application, économisant ainsi de l'argent et surtout innovant leurs applications et leur entreprise au lieu de configurer des configurations et de gérer des choses comme les serveurs et les bases de données. Les autres fonctionnalités achetant pour utiliser PaaS sont le processus de déploiement d'application tel que l'agilité, la haute disponibilité, la surveillance, la mise à l'échelle / le détartrage, le besoin limité d'expertise, le déploiement facile et le coût et le temps de développement réduits.

Mais il y a toujours un côté sombre du PaaS qui fait obstacle à l'adoption du 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 correctement gérés
  • Prématuré et douteux dans la journée et l'âge actuels

En dehors de ce qui précède, vous devriez avoir suffisamment 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é
  • Charger le routage de blanchiment / Http
  • Stratégies de sauvegarde de service
  • La collaboration d'équipe
  • Reconstruire la production

Si vous avez une petite entreprise, le PaaS sera la meilleure option pour vous:

  • Payez au fur et à mesure
  • Coût de démarrage faible
  • Laissez la plomberie à un expert
  • PaaS gère la mise à l'échelle / 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 modules complémentaires tiers pour vous

Ce sera un choix totalement individuel en fonction des besoins. Vous pouvez avoir des détails sur mes applications PPT Hosting Rails .


3
Je vois EngineYard et Heroku, et bien sûr ElasticBeanstalk ... tous fonctionnent sur AWS en dessous. En fait, existe-t-il des PaaS majeurs qui ne fonctionnent PAS sur les aws en dessous? Des idées? Cheers
Fattie

5
Joe, je sais que c'est tard, mais pour répondre à votre question, IBM Bluemix fonctionne sur SoftLayer.
Antonio Cangiano

PaaS gère toutes les exigences de sécurité Sécurisation du serveur, peut-être, mais très trompeuse (en particulier dans un monde où les développeurs semblent supposer que leur système est sécurisé par défaut). Cela ne vous protégera certainement pas de XSS, CSRF et ne définira probablement aucun en-tête HTTP important pour vous. Je peux le voir maintenant: Thank you for your concerns. We assure you that we take security very seriously and run or systems on secure servers. There is no need to worry about [insert security issue here] as all that is handled by.... -1 mais je l'inverse s'il est correctement édité.
Nateowami

4
Il existe de plus en plus une catégorie de solutions PaaS (PaaS DIY) qui fonctionnent sur votre propre infrastructure, répondant ainsi à certaines des préoccupations liées à la flexibilité / contrôle PaaS. Quelques exemples: openshift , cloudfoundry , Hasura . Avertissement: je travaille chez Hasura.
iamnat

35

Il existe de nombreuses façons de considérer cette décision à partir des objectifs de développement, informatiques et commerciaux, alors ne vous sentez pas mal si cela vous semble écrasant. Mais aussi - ne pensez pas trop à l'évolutivité.

Pensez à vos besoins .

J'ai conçu des sites Web qui ont desservi plus de 8 millions d'unités par jour et livré des téraoctets de vidéo par semaine, construits sur des infrastructures commençant à 250 000 $ en matériel informatique et par un énorme personnel informatique de $ MM.

Mais j'ai également eu de plus petits sites Web conçus pour générer de 10 à 20 000 $ par an, sans trafic, base de données ou exigences de traitement très élevés, et je les ai exécutés sans compromis sur un compte d'hébergement générique de 10 $ / mois.

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

En outre, gardez à l'esprit un site Web commercial - l'évolutivité est ce que nous appelons souvent un `` bon problème '' - bien que les problèmes d'évolutivité avec des sites comme Facebook et Twitter aient été très médiatisés, ils n'ont eu aucun effet négatif sur leur succès - l'actualité aurait même pu contribuer à plus d'inscriptions (toute presse est bonne presse).

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

L'évolutivité est un problème de mise en œuvre réparable - ne pas avoir de clients est un problème existentiel.


35

En fait, vous pouvez utiliser les deux - vous pouvez développer une application avec les serveurs amazon ec2. Ensuite, poussez-le (avec git) sur 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 Heroku plus restrictive, ce à quoi vous devriez penser. Source: cette méthode a été adoptée pour l'un de mes cours en ligne "Ingénierie de démarrage de Coursera / Stanford par Balaji S. Srinivasan et Vijay S. Pande

Ajout d'un schéma pour que mon explication soit plus facile à comprendre


15
Quel est l'avantage d'utiliser la micro-instance comme machine de développement, au lieu d'utiliser votre ordinateur local? Je ne vois pas l'avantage supplémentaire d'ajouter l'AWS dans ce cas particulier. Merci!
Mateo

5
probablement parce que dans un environnement académique, cela rendra les instructions de configuration de l'environnement de développement plus cohérentes et qu'ils n'ont pas à s'inquiéter de le faire fonctionner sur Windows
Jeff Dickey

2
Cette architecture permet d'éviter de nombreuses incompatibilités Windows / Linux OS. Et apprenez également le système d'exploitation Linux sans avoir à l'installer sur votre machine locale. Si vous avez un Mac, c'est moins un problème mais beaucoup de gens utilisent Windows.
sivi

13
Cela s'appelle une machine virtuelle, je ne vois toujours pas grand chose à faire.
Abe Petrillo

2
Avoir une plate-forme séparée pour la mise en scène et la production est une idée super terrible; les principales versions du logiciel vont différer de manière incompatible. Vous devriez être en mesure d'exécuter votre code localement pour le développement, même si le système d'exploitation natif diffère du système d'exploitation de production (au pire, avec quelque chose comme VMware ou vagabond ou avec un émulateur si vous construisez pour une plate-forme intégrée; mais nativement, il est généralement plus facile de travailler avec). Seul le fait de pouvoir déployer du code à distance dans le cloud est un obstacle horrible au développement rapide d'applications qui rend les tests et le débogage inutilement longs.
Iain Collins

28

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

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

Heroku

  • Une commande pour déployer tous les types de projets: Ruby on Rails, Nodejs
  • Tant de 1-clic pour intégrer des plugins et des tiers: il est super facile de commencer avec quelque chose.
  • Ne pas avoir de mise à l'échelle automatique; cela signifie que vous devez augmenter / réduire manuellement
  • Le coût est cher, surtout lorsque le système a besoin de plus de ressources
  • Instance gratuite disponible
  • L'instance gratuite se met en veille si elle est inactive.
  • Centre de données: États-Unis et UE uniquement
  • PEUT plonger dans / 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!
  • Pas besoin d'en savoir trop sur DevOps

AWS - EC2

  • Cela ressemble à une machine avec un système d'exploitation pré-configuration (ou non), vous devez donc installer un logiciel, une bibliothèque pour rendre votre site Web / service en ligne.
  • Le plugin et la bibliothèque doivent être intégrés manuellement ou un script d'automatisation (script public et écrit par vous)
  • La mise à l'échelle automatique et l'équilibreur de charge sont les services pris en charge, apprenez simplement à configurer et à intégrer à votre système
  • Le coût est assez bon marché, dépend des services et du nombre d'heures d'utilisation
  • Il y a plusieurs heures gratuites pour les instances T2.micro, mais généralement, vous paierez quelques dollars par mois (si vous utilisez toujours T2.micro)
  • Votre instance gratuite ne se mettra pas en veille, disponible 24h / 24 et 7j / 7 (car vous pouvez la payer :))
  • Centre de données: dans le monde. Choisissez la région qui vous convient le mieux.
  • Plongez au niveau de la machine. Vous pouvez donc en profiter
  • Quelques connaissances sur DevOps, mais ça va, Stackoverflow y est utile!

AWS Elastic Beanstalk, une alternative à 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, veuillez cliquer 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 que cela peut être le remplacement de Heroku et moins cher!

Sommaire

  • Heroku: Facile au début, GRATUIT instance , mais coûteuse par la suite
  • AWS: Pas facile, heures libres disponibles, un peu moins cher , Beanstalk devrait être soucieux d'utiliser

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


3
J'aime la façon dont vous répondez à la question. J'ai essayé Heroku et AWS. Je suis d'accord avec vous pour recommander:Use Heroku for staging, and Beanstalk for production!
Chetabahana

1
heroku run bashet vous avez un accès shell à votre dynamo
Mohammad Jafar Mashhadi

Pouvez-vous donner une estimation des prix? je vais devoir publier Java Web App sur Tomcat (framework Spring, angularJS etc.), pensons à environ 1000 utilisateurs par mois, chacun utilisant l'application pendant 5 minutes. Quel est le prix estimé? (comme une très faible utilisation, mais la disponibilité pour un mois complet)
rasoir

1
@razor si vous utilisez une micro instance t2 (bonne pour la pré-production ou un petit projet), le prix est si bon marché, il est d'environ 5 $ à 10 $ par mois comme ma mémoire dans le projet précédent. Le détail ici aws.amazon.com/ec2/pricing
Hieu Pham

et Heroku sera beaucoup plus cher? (2 fois?) Avec une utilisation similaire? Je connais les pages de prix, mais il est difficile de calculer / d'imaginer combien de puissance CPU une application aussi simple prendra ou quelle sera l'utilisation de la base de données après un mois (la base de données sera assez petite)
rasoir

27

Les réponses existantes sont globalement exactes:

  • Heroku est très facile à utiliser et à déployer, peut être facilement configuré pour le déploiement automatique d'un référentiel (par exemple GitHub), possède de nombreux modules complémentaires tiers et facture plus par instance.

  • AWS propose une gamme plus large de services propriétaires à des prix compétitifs, notamment DNS, équilibrage de charge, stockage de fichiers bon marché et propose des fonctionnalités d'entreprise telles que 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 plateforme de mise à l'échelle automatique de type Heroku et un déploiement facile. Comme il utilise des instances EC2 (qu'il crée automatiquement), les serveurs EB peuvent faire tout ce que toute autre instance EC2 peut faire et son exécution est bon marché.

Le déploiement avec EB est très lent; le déploiement d'une mise à jour peut prendre 10 à 15 minutes par serveur et le déploiement sur un cluster plus important peut prendre la meilleure partie d'une heure, contre seulement quelques secondes pour déployer une mise à jour sur Heroku. Les déploiements sur EB ne sont pas non plus traités de manière particulièrement transparente, ce qui peut imposer des contraintes sur la conception des applications.

Vous pouvez utiliser tous les services qu'ElasticBeanstalk utilise en arrière-plan pour créer votre propre système sur mesure (avec CodeDeploy, Elastic Load Balancer, Auto Scaling Groups - et CodeCommit, CodeBuild et CodePipeline si vous voulez vous lancer) mais vous pouvez certainement dépenser un bon quelques semaines pour le configurer la première fois car il est assez compliqué et légèrement plus difficile que de simplement configurer les choses dans EC2.

AWS Lightsail propose une option d'hébergement à prix compétitif, mais n'aide pas au déploiement ou à la mise à l'échelle - c'est vraiment juste un wrapper 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 c'est cher par rapport au coût de la simple configuration d'une instance EC2 (ce que vous pouvez également faire par programme).

Quelques réflexions sur la comparaison (pour essayer de répondre aux questions, quoique de manière détournée):

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

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

    Le déploiement automatique lorsque vous mettez à jour votre référentiel Git est sans effort avec Heroku. Il est presque instantané, gracieux, il n'y a donc pas de pannes pour les utilisateurs finaux et ne peut être configuré pour se mettre à jour que si les tests / l'intégration continue réussissent afin de ne pas casser votre site si vous déployez du code cassé.

    Vous pouvez également utiliser ElasticBeanstalk pour le déploiement automatique, mais soyez prêt à passer une semaine à le configurer la première fois - vous devrez peut-être modifier la façon dont vous déployez et créez des actifs (comme CSS et JS) pour travailler avec la façon dont ElasticBeanstalk gère les déploiements ou la logique de construction dans votre application pour gérer les déploiements.

    Soyez conscient lors 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 les mises à jour sur chaque serveur individuellement afin que votre service ne soit pas dégradé - alors qu'Heroku lance un nouveau dynamo pour vous et déconseille simplement l'ancien service jusqu'à ce que toutes les requêtes soient traitées (puis il le supprime).

    Fait intéressant, le coût d'hébergement de l'exécution de plusieurs serveurs avec EB peut être moins cher qu'une seule instance Heroku, en particulier une fois que vous incluez le coût des modules complémentaires.

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 crains que les gens ne suggèrent cela. Alors qu'idéalement, le code devrait fonctionner très bien sur toute plate-forme raisonnable afin qu'il soit aussi portable que possible, les versions de logiciel sur chaque hôte varieront considérablement et ce n'est pas parce que le code s'exécute en staging qu'il s'exécutera en production (par exemple, Node.js / Les versions Ruby / Python / PHP / Perl peuvent différer de manière à rendre le code incompatible, souvent de manière silencieuse qui pourrait ne pas être détectée même si vous disposez d'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 créer et déployer des 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 lorsque vous prenez cette décision, sans oublier le coût de la réplication de l'environnement entier (y compris les services tiers tels que les magasins de données / modules complémentaires, l'installation et la configuration de SSL, etc.) .

  2. Si vous utilisez AWS, méfiez-vous des instances préconfigurées AWS de fournisseurs comme Bitnami - elles sont un cauchemar pour la sécurité. Ils peuvent exposer de nombreuses applications notoirement vulnérables par défaut sans le mentionner dans la description.

    Envisagez plutôt d'utiliser simplement une distribution traditionnelle bien prise en charge, comme Ubuntu ou Debian (ou CentOS si vous avez besoin de la prise en charge de RPM).

    Remarque: l'offre d'Amazon a sa propre distribution appelée Amazon Linux, qui utilise RPM, mais elle est spécifique à EC2 et moins bien prise en charge par des logiciels 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 facilement plusieurs sites, ce qui peut valoir la peine si vous maintenez de nombreux services ou si vous voulez être capable de faire tourner de nouvelles choses facilement. Cependant, la configuration n'est pas aussi automatique que l'utilisation de Heroku et vous pouvez finir par passer beaucoup de temps à le configurer et à le maintenir (au point que j'ai trouvé que le déploiement à l'aide d'Amazon clustering et Docker Swarm était 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 des services, mais ma facture Heroku serait de milliers par an si je l'utilisais pour tout et AWS représente une fraction du coût.

tl; dr

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

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

Un exemple d'un service qui est presque celui-ci est now.sh , qui utilise en fait AWS dans les coulisses, mais rend les déploiements et le regroupement aussi facile car il est sur Heroku (avec SSL automatique, DNS, les déploiements gracieuses, la configuration du cluster super facile et la gestion).

Je l'ai beaucoup utilisé pour les déploiements d'applications Node.js et 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 `` maintenant '' peut également être utilisé pour déployer sur des instances dédiées sur AWS ainsi que Google Cloud et Azure.


8

Il s'agit d'un pourcentage important de nos activités de migration de personnes de Heroku vers AWS. Il y a des avantages aux deux, mais ça devient désordonné sur Heroku après un certain temps ... une fois que vous avez besoin d'un certain niveau de complexité plus facile à maintenir avec les limites de Heroku.

Cela dit, il existe de plus en plus d'options pour bénéficier de la facilité d'Heroku et de la flexibilité d'AWS en étant sur AWS avec d'excellents cadres / outils.


Pouvez-vous donner une estimation des prix? je vais devoir publier Java Web App sur Tomcat (framework Spring, angularJS etc.), pensons à environ 1000 utilisateurs par mois, chacun utilisant l'application pendant 5 minutes. Quel est le prix estimé? (comme une très faible utilisation, mais la disponibilité pour un mois complet)
rasoir

3

Le plus drôle est que Heroku utilise réellement AWS sur le backend. Il supprime tous les frais généraux et gère 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

Bien! J'observateur Heroku est célèbre pour les développeurs en herbe et les développeurs nouvellement nés, tandis qu'AWS a un développeur avancé. DigitalOcean est également un acteur majeur dans ce domaine. Cloudways a facilité la création de piles de lampes en un clic sur DigitalOcean et AWS. Avoir tous les services et packages mis à jour en 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/


1

Eh bien, Heroku utilise AWS en arrière-plan, tout dépend du type de solution dont vous avez besoin. Si vous êtes un noyau Linux et devops, vous ne craignez pas de créer vm à partir de zéro, comme sélectionner un ami en choisissant des options de palette, etc., vous pouvez opter pour AWS. Si vous voulez faire des choses au niveau de la surface sans avoir ces qualités, vous pouvez aller avec heroku.


0

Amazon Web Services (AWS) offre de nombreux services de l'IaaS au PaaS avec une durabilité et une disponibilité de 99,9999999% et de la disponibilité des données et de l'infrastructure assurées. AWS propose une automatisation de l'infrastructure ainsi que plusieurs outils permettant aux développeurs de canaliser leur processus de déploiement d'applications.

D'un autre côté, Heroku est juste PaaS qui propose des services pour gérer votre plateforme sur leur cloud. Il n'est nulle part avec AWS, qu'il s'agisse d'infrastructure ou de sécurité.


6
Une citation s'imposait pour: "Il n'y a rien avec AWS, que ce soit l'infrastructure ou la sécurité.".
pdoherty926

0

Parfois, je me demande pourquoi les gens comparent AWS à Heroku. AWS est un IAAS (infrastructure en tant que service), il indique clairement la robustesse et le calcul du système. Heroku, d'autre part, est juste un SAAS, il n'est fondamentalement qu'une fraction des services AWS. Alors pourquoi avoir du mal à configurer AWS lorsque vous pouvez expédier votre premier produit au premier à l'aide de Heroku.

Heroku est gratuit, simple et facile à déployer presque tous les types de piles sur le Web. Heroku est spécialement conçu pour contourner tous les tracas liés à l'expédition de votre application vers un serveur en direct en moins de temps.

Néanmoins, vous souhaiterez peut-être déployer votre application à l'aide de l'un des didacticiels des deux parties et comparer

AWS DOCS et Heroku Docs


0

Même si AWS et Heroku sont des plates-formes cloud, ils sont différents car AWS est IaaS et Heroku est PaaS


2
Ce n'est pas correct. AWS propose des offres IAAS et PAAS.
Glenn Bech

0

Heroku est comme un sous-ensemble d'AWS. C'est juste une plate-forme en tant que service, tandis qu'AWS peut être implémenté comme n'importe quoi et à n'importe quel niveau.

La mise en œuvre dépend de ce que l'exigence métier. S'il convient à l'un ou l'autre, utilisez-le en conséquence.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.