Pourquoi les gens utilisent-ils Heroku quand AWS est présent? Qu'est-ce qui distingue Heroku d'AWS?
Je suis un programmeur RoR débutant qui envisage de déployer mon application à l'aide de Heroku. Selon des informations communiquées par mes autres amis conseillers, 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 consulté leur site Web et en un mot, ce que Heroku fait, c'est aider à la mise à l'échelle mais ... pourquoi est-ce important? Comment Heroku aide-t-il avec:
Rapidité: mes recherches ont révélé 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.
Sécurité - sont-ils en sécurité?
Mise à l'échelle - Comment cela fonctionne-t-il réellement?
Rentabilité - Il existe quelque chose comme un dyno qui le rend facile à faire évoluer.
Comment se comportent-ils face à 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.
AWS/Heroku sont gratuits pour les petits projets de loisir (pour commencer).
Si vous voulez démarrer une application tout de suite, sans trop personnaliser l’architecture, choisissez Heroku .
Si vous souhaitez vous concentrer sur l’architecture et pouvoir utiliser différents serveurs Web, choisissezAWS. 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 plug-in.
Heroku
- Plate-forme en tant que service (PAAS)
- Bonne documentation
- A des outils et une architecture intégrés.
- Contrôle limité sur 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).
- Ne prend pas de temps.
AWS
- Infrastructure en tant que service (IAAS)
- Polyvalent - propose de nombreux produits tels que EC2, LAMBDA, EMR, etc.
- Peut utiliser une instance dédiée pour plus de contrôle sur l'architecture, telle que le choix du système d'exploitation, 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.
AWS et Heroku sont deux choses différentes. AWS propose une infrastructure en tant que service ( IaaS ), tandis que Heroku propose une plate-forme en tant que service ( PaaS ).
Quelle est la différence? Très approximativement, IaaS vous fournit les composants dont vous avez besoin pour construire des choses par-dessus. PaaS vous offre un environnement dans lequel vous ne faites que transmettre du code, une configuration de base et une application en cours d'exécution. IaaS peut vous donner plus de puissance et de flexibilité, au prix de la construction et de la maintenance que vous aurez vous-même.
Pour que votre code fonctionne sur AWS et ressemble un peu à un déploiement Heroku, vous aurez besoin de quelques instances EC2 - vous aurez besoin d'une couche d'équilibrage de la charge/de mise en cache installée sur celles-ci (par exemple, Varnish ). Souhaitez que des instances exécutant quelque chose comme Passenger et nginx pour servir votre code, vous aurez envie de déployer et de 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 qui fait l'agrégation de journaux.
Ce n’est pas une somme insignifiante de travail à installer et à entretenir. Avec Heroku, l’effort requis pour atteindre ce type d’étape consiste peut-être en quelques lignes de code d’application et en un git Push.
Donc, vous êtes si loin et vous souhaitez passer à la vitesse supérieure. Génial. Vous utilisez Puppet pour votre déploiement EC2, n'est-ce pas? Alors maintenant, vous configurez vos fichiers Capistrano pour une rotation des instances haut/bas en fonction des besoins; vous modifiez votre configuration de marionnettes afin que Varnish connaisse les instances de WebWorker et les regroupe automatiquement. Ou vous heroku 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 s'exécute que sur les instances AWS dans us-east et eu-west. Pour vous, cela ressemble de toute façon à ce que vous voulez. 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 tout simplement mal assemblés. Avec Heroku, vous avez quelqu'un d'autre qui gère ce genre de chose, qui est une bénédiction ou une malédiction selon la façon dont vous le regardez!
Lorsque vous déployez, vous remettez 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 soient exécutés sur des instances individuelles d’EC2). Plusieurs collègues ont exprimé des problèmes avec ces technologies et la force de leur isolement; Je ne suis hélas pas en situation de connaissances/d'expérience suffisantes pour faire de véritables commentaires, mais mes déploiements actuels à Heroku considèrent cela comme "assez bon". Cela peut être un problème pour vous, je ne sais pas.
Mise à l'échelle
J'ai évoqué comment on pourrait implémenter cela 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, donc par exemple (cribbed from 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
vous aurez 2 web dynos et 10 worker dynos en cours d'exécution. Nice, simple, facile. Notez que web est un type de dyno spécial, qui a accès au monde extérieur et est derrière leur multiplexeur de trafic Web Nice (probablement une sorte de combinaison Varnish/nginx) qui acheminera le trafic en conséquence. Vos employés interagissent probablement avec une file 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, il coûte 0,05 USD/heure pour une heure donnée, comparé à 0,025 USD/heure pour une instance micro AWS ou à 0,09 USD/heure pour une petite instance AWS.
Heroku documentation de dyno indique que vous avez environ 512 Mo de RAM, il n'est donc probablement pas trop de considérer un dyno comme un peu comme une micro-instance EC2. Vaut-il le double du prix? Combien évaluez-vous votre temps? Le temps et les efforts nécessaires pour développer une offre IaaS conforme à cette norme 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 d'ici (heroku run bash), un aperçu rapide montre 4 cœurs dans /proc/cpuinfo et 36 Go de RAM - cela me mène de croire que je suis sur un "instance très grande de mémoire à très grande capacité" . Le Heroku documentation dyno indique que chaque dyno reçoit 512 Mo de RAM, donc je partage potentiellement avec un maximum de 71 autres dynos (je ne dispose pas de suffisamment de données sur l'homogénéité des instances AWS de Heroku, de sorte que votre kilométrage peut varier))
Comment se comportent-ils face à leurs concurrents?
Ceci, j'ai bien peur de ne pas pouvoir vous aider. Le seul concurrent que j'ai jamais examiné était Google App Engine - à l'époque, je cherchais à déployer des applications Java, et le nombre de restrictions d'utilisation cadres et technologies était incroyablement rebutant. C’est plus que "juste un Java chose" - la quantité de restrictions générales et de considérations nécessaires ( la FAQ astuces sur plusieurs) ne semblait pas très pratique. En revanche, déployer à Heroku a été un rêve.
Conclusion
J'espère que cela répond à vos questions (veuillez préciser s'il y a des lacunes/d'autres domaines que vous souhaiteriez aborder). Je pense que je devrais offrir ma position personnelle. J'aime Heroku pour ses "déploiements rapides". Lorsque je lance une application et que je veux un hébergement bon marché (le niveau gratuit de 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érieuse" avec plusieurs clients payants, avec un accord de niveau de service, avec du temps à consacrer aux opérations, et cetera, je ne peux pas me résoudre à transférer autant de contrôle à Heroku, puis 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 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 que vous n'ayez pas à perdre du temps à mettre en place toutes les autres infrastructures autour de votre code. Je voudrais certainement essayer.
Remarque: AWS propose effectivement 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 à EC2, S3 et EBS, qui sont sans aucun doute des offres IaaS.
Comme l'a dit Kristian Glass, il n'y a pas de comparaison possible entre IaaS ( AWS ) et PaaS ( Heroku , EngineYard ).
PaaS aide essentiellement les développeurs à accélérer le développement d'applications, économisant ainsi de l'argent et, surtout, à innover leurs applications et leur activité plutôt que de configurer des configurations et de gérer des éléments tels que des serveurs et des bases de données. Le processus de déploiement d’applications, comme l’agilité, la haute disponibilité, la surveillance, l’échelle/détartrage, le besoin limité d’expertise, le déploiement aisé, ainsi que les coûts et le temps de développement, est une autre caractéristique qui incite à utiliser PaaS.
Mais il y a toujours un côté sombre à la PaaS qui constitue un obstacle à l’adoption de la 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 du jour et de l'âge
En dehors de ce qui précède, vous devriez avoir assez de compétences pour vous maîtriser IaaS:
- Acquisition du 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
- App surveillance
- La haute disponibilité
- Blanc de charge/Routage Http
- Stratégies de sauvegarde de service
- La collaboration d'équipe
- Reconstruire la production
Si vous avez une petite entreprise, PaaS sera la meilleure option pour vous:
- Payez comme vous allez
- Faible coût de démarrage
- Laisser la plomberie à un expert
- PaaS gère la mise à l'échelle/le détartrage automatique, l'équilibrage de la charge, la récupération après sinistre
- PaaS gère toutes les exigences de sécurité
- PaaS gère la fiabilité et la haute disponibilité
- Paas gère de nombreux modules tiers pour vous
Ce sera un choix totalement individuel en fonction des besoins. Vous pouvez avoir des détails sur mon PPT Hébergement d'applications Rails .
Il existe de nombreuses manières différentes d’examiner cette décision en fonction d’objectifs de développement, d’informatique et d’entreprise, alors ne vous sentez pas triste si cela vous semble insupportable. Mais aussi - ne pensez pas trop à l'évolutivité.
Pensez à vos exigences .
J'ai conçu des sites Web qui traitaient plus de 8 millions d'utilisateurs uniques par jour et diffusaient des téraoctets de vidéos par semaine sur des infrastructures à partir de 250 000 USD de matériel d'équipement, sans l'aide d'un énorme personnel informatique de plusieurs millions de dollars.
Mais j'ai aussi des sites Web plus petits conçus pour générer entre 10 000 et 20 000 dollars par an, ne nécessitant pas un trafic, une base de données ou un traitement très élevés, et je les ai gérés sans compromis sur un compte d'hébergement générique à 10 $/mois.
À l'avenir, le déploiement ressemblera davantage à Heroku qu'à AWS, uniquement en raison des progrès réalisés. Il n’ya aucune valeur dans le virage informatique des infrastructures Internet évolutives qui ne soit de plus en plus automatisable, et cela n’a rien à voir avec la valeur du produit ou du service que vous offrez.
En outre, 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 aucun effet négatif sur leur succès - les actualités pourrait même avoir contribué à plus d'inscriptions (toute presse est bonne presse).
Si vous disposez d'un service générant plus de 100 000 offres uniques par jour et rencontrant des problèmes de dimensionnement, je me ferai un plaisir de vous l'enlever, quels que soient le langage, la base de données, la plate-forme ou l'infrastructure sur laquelle vous travaillez!
L’évolutivité est un problème d’implémentation qui peut être résolu: l’absence de clients est un problème existentiel.
En fait, vous pouvez utiliser les deux. Vous pouvez développer une application avec les serveurs Amazon ec2. Ensuite, poussez (avec git) vers heroku gratuitement pendant un certain temps (utilisez heroku free tier pour le servir au public) et testez-le ainsi. C'est très rentable par rapport à la location d'un serveur, mais vous devrez parler avec une heroku api plus restrictive, à laquelle 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
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 rapide examen et comparaison:
Heroku
- Une commande pour déployer tous les types de projets: Ruby on Rails, Nodejs
- Autant de clics pour intégrer des plugins et des tiers: il est très facile de commencer avec quelque chose.
- Ne pas avoir la mise à l'échelle automatique; cela signifie que vous devez augmenter/réduire manuellement
- Le coût est coûteux, en particulier lorsque le système nécessite plus de ressources
- Instance gratuite disponible
- L'instance gratuite s'endort si elle est inactive.
- Centre de données: États-Unis et Union européenne uniquement
- POUVEZ plonger dans/accéder au niveau de la machine en utilisant
Heroku run bash(Merci, MJafar Mash pour le conseil) mais c'est un peu limité! Vous n'avez pas un accès complet! - Pas besoin d'en savoir plus sur DevOps
AWS - EC2
- Cela ressemble à une machine avec un système d'exploitation pré-configuration (ou pas), de sorte que vous devez installer un logiciel, une bibliothèque pour que votre site Web/service soit mis 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'équilibrage de charge sont les services pris en charge. Il vous suffit d'apprendre à 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 vous payerez généralement quelques dollars par mois (si vous utilisez toujours T2.micro)
- Votre instance gratuite ne s'endormira pas, disponible 24h/24 et 7j/7 (car vous pouvez payer pour cela :))
- Centre de données: dans le monde entier. Choisissez la région qui vous convient le mieux.
- Plongez au niveau de la machine. Pour que vous puissiez en profiter
- Quelques connaissances sur DevOps, mais ça va, Stackoverflow y est utile!
AWS Elastic Beanstalk une alternative à Heroku, mais moins chère
Elastic Beanstalk a été annoncé comme une version bêta publique à partir de 2010; cela nous aide plus facilement à travailler avec le déploiement. Pour plus de détails s'il vous plaît aller ici
Beanstalk est gratuit, le coût que vous payerez 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 remplacer Heroku et être moins cher!
Résumé
- Heroku: Facile au début, LIBRE instance, mais cher plus tard
- AWS: Pas facile, heures gratuites disponibles, genre de moins cher, Beanstalk devrait être concerné à utiliser
Donc, dans mon système actuel, j'utilise Heroku pour la mise en scène et Beanstalk pour la production!
Cela représente un pourcentage important de la migration de nos employés de Heroku vers AWS. Les deux avantages présentent des avantages, mais Heroku devient désordonné après un certain temps ... dès lors que vous avez besoin d'un certain niveau de complexité qui n'est plus facile à gérer avec les limites de Heroku.
Cela dit, il existe de plus en plus d’options pour bénéficier de la facilité d’utilisation de Heroku et de la flexibilité d’AWS en utilisant AWS avec d’excellents frameworks/outils.
Ce qui est drôle, c'est que Heroku utilise réellement AWS sur le backend. Il supprime tous les frais généraux et gère l’architecture sur EC2 pour vous. (Acquis par un ingénieur en chef d'une grande entreprise lors d'une entrevue)
Amazon Web Services (AWS) propose de nombreux services, du protocole IaaS au PaaS, avec une durabilité et une disponibilité garanties de 99,9999999% des données et de l'infrastructure. AWS propose une automatisation d'infrastructure ainsi que plusieurs outils permettant aux développeurs de gérer leur processus de déploiement d'applications.
Par ailleurs, Heroku est juste PaaS qui offre des services pour gérer votre plate-forme sur leur cloud. Qu'il s'agisse d'infrastructure ou de sécurité, AWS ne se trouve nulle part ailleurs.
Bien! Mon observateur, Heroku, est célèbre pour les développeurs en herbe et nouvellement nés, alors qu'AWS est un développeur avancé. DigitalOcean est également un acteur majeur sur ce terrain. Cloudways a beaucoup facilité la création d'une pile de lampes en un clic sur DigitalOcean et AWS. Avoir tous les mises à jour de services et de packages en un clic est de loin préférable à tout faire manuellement.
Vous pouvez vérifier complètement ici: https://www.cloudways.com/blog/Host-php-on-aws-cloud/
Parfois, je me demande pourquoi les gens comparent AWS à Heroku. AWS est un IAAS (infrastructure en tant que service), il indique clairement à quel point le système est robuste et calculateur. Heroku, par contre, n’est qu’un SAAS, c’est une fraction des services AWS. Alors, pourquoi lutter avec la configuration d’AWS lorsque vous pouvez expédier votre premier produit avec Prime 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 problèmes liés à l'envoi de votre application à un serveur en direct en moins de rien.
Néanmoins, vous voudrez peut-être déployer votre application à l’aide des didacticiels des deux parties et comparer
Heroku est comme un sous-ensemble de AWS. Il ne s'agit que d'une plate-forme en tant que service, tandis qu'AWS peut être implémenté de manière quelconque et à tout niveau.
La mise en œuvre dépend de l'exigence métier. Si cela convient, utilisez-le en conséquence.
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 de choisir AMI en choisissant des options de renforcement, etc., vous pouvez utiliser AWS. Si vous voulez faire des choses au niveau de la surface sans avoir ces nettigrities, vous pouvez aller avec heroku.
Même si AWS et Heroku sont des plates-formes cloud, elles sont différentes, car AWS est IaaS et Heroku est PaaS.