[ruby-on-rails] Pourquoi les gens utilisent Heroku quand AWS est présent? Qu'est-ce qui distingue Heroku d'AWS?


5 Answers

Tout d'abord, AWS et Heroku sont des choses différentes. AWS propose l'infrastructure en tant que service ( IaaS ) alors qu'Heroku propose 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 d'instances EC2 - vous aurez besoin d'un calibreur de charge / couche de cache installé dessus (par exemple Varnish ), vous aurez besoin d'instances exécutant quelque chose comme Passenger 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 aurez besoin d'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 à maintenir. Avec Heroku, l'effort nécessaire pour arriver à ce genre d'étape est peut-être quelques lignes de code d'application et une git push .

Donc vous êtes si loin, et vous voulez passer à l'échelle. Génial. Vous utilisez Puppet pour votre déploiement EC2, n'est-ce pas? 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 vous 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 des instances AWS en 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. Approximativement, votre application a un Procfile , qui a des lignes de la forme dyno_type: command_to_run , ainsi par exemple (cribbed 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 l'exécution de 2 dynos web et de 10 dynos worker . Nice, simple, facile. Notez que web est un type dyno spécial, qui a accès au monde extérieur, et qui est à l'origine de leur 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.

La documentation dyno d'Heroku indique que vous avez environ 512 Mo de RAM, donc il n'est probablement pas trop déraisonnable de considérer un dyno comme un micro-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 coup d'oeil rapide montre 4 cœurs dans /proc/cpuinfo et 36Go de RAM - ce qui m'amène à croire que je suis sur un "La mémoire d' Heroku dyno indique que chaque dyno reçoit 512 Mo de RAM, donc je partage potentiellement avec 71 autres dynos (je n'ai pas assez de données sur l'homogénéité des instances AWS d'Heroku, donc votre kilométrage 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 vu était Google App Engine - au moment où je cherchais à déployer des applications Java, et la quantité de restrictions sur les frameworks et les technologies utilisables était incroyablement rebutante. C'est plus que "juste une chose de Java" - le montant des restrictions générales et des considérations nécessaires ( les indices de FAQ à plusieurs) semblait moins que commode. En revanche, le déploiement à Heroku a été un rêve.

Conclusion

J'espère que cela répond à vos questions (s'il vous plaît 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 possède en fait une offre PaaS, Elastic Beanstalk , 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

Question

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 website 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, Engine Yard et bluebox ?

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







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/




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 passer à 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, Auto Scaling Groups - et CodeCommit, CodeBuild et CodePipeline si vous voulez tout faire) mais vous pouvez certainement passer un bon 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 du logiciel 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 voulez être capable de lancer 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.

now.sh , qui utilise AWS en arrière- now.sh , est un exemple de service. Il rend les déploiements et les clusters aussi simples que sur Heroku (avec le SSL automatique, le DNS, les déploiements gracieux, la configuration de cluster super facile et la gestion).

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.




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 à vos besoins .

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» - 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 avoir même contribué à plus d'inscriptions (toute 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.




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.






Related