Pourquoi les gens utilisent-ils Heroku lorsque AWS est présent? Qu’est-ce qui distingue Heroku de AWS?

Je suis un programmeur RoR débutant qui prévoit de déployer mon application avec Heroku. Les mots de mes autres amis conseillers indiquent 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 Web et en un mot, ce que fait Heroku est d’aider à la mise à l’échelle, mais … pourquoi est-ce même important? Comment Heroku aide-t-il avec:

  1. Rapidité – Ma recherche impliquait que le déploiement d’AWS sur la côte est des États-Unis serait le plus rapide si je cible un public basé aux États-Unis et en Asie.

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

  3. Mise à l’échelle – Comment ça marche réellement?

  4. Rentabilité – Il y a quelque chose comme un dyno qui facilite la mise à l’échelle.

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

S’il vous plaît utiliser des termes anglais profanes pour expliquer … Je suis un programmeur débutant.

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

Si vous souhaitez démarrer une application immédiatement, sans trop personnaliser 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 cela en vaut la peine. AWS est également livré avec de nombreux services et produits de plug-in.


Heroku

  • Plate-forme 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 (via les commandes git uniquement).
  • Pas de temps.

AWS

  • Infrastructure en tant que service (IAAS)
  • Polyvalent – a de nombreux produits tels que EC2, LAMBDA, EMR, etc.
  • Peut utiliser une instance dédiée pour mieux contrôler l’architecture, par exemple choisir le système d’exploitation, la version du logiciel, etc. Il existe plusieurs couches backend.
  • Elastic Beanstalk est une fonctionnalité similaire à PAAS de Heroku.
  • Peut utiliser le déploiement automatisé ou lancer le vôtre.

Tout d’abord, AWS et Heroku sont des choses différentes. AWS offre une infrastructure en tant que service ( IaaS ), tandis que Heroku offre une plate-forme en tant que service ( PaaS ).

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

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’une couche d’équilibrage de charge / de cache installée (par exemple, Varnish ). Passenger et nginx pour servir votre code, vous souhaiterez déployer et configurer une instance de firebase database 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 de l’agrégation de journaux.

Ce n’est pas une quantité insignifiante de travail à mettre en place et à maintenir. Avec Heroku, il faut peut-être quelques lignes de code d’application et une git push pour parvenir à ce stade.

Donc, vous êtes si loin, et vous voulez intensifier. Génial. Vous utilisez Puppet pour votre déploiement EC2, non? Alors maintenant, vous configurez vos fichiers Capistrano de manière à ce que les instances montent / descendent selon vos besoins; Vous remettez à zéro votre configuration de marionnettes afin que Varnish soit au courant des instances des travailleurs Web et les met 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 situées aux eu-west et en eu-west . Pour vous, cela ressemble à ce que vous voulez de toute façon. Pour d’autres, c’est potentiellement plus important.

Sécurité

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

Lorsque vous déployez, vous transmettez efficacement votre code à 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 de savoir / d’expérience pour vraiment commenter, mais mes déploiements Heroku actuels le considèrent comme «suffisamment bon». Cela peut être un problème pour vous, je ne sais pas.

Mise à l’échelle

J’ai évoqué la manière dont cela pourrait être mis en œuvre 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 , donc 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 

vous aurez deux dynos web et 10 dynos de worker cours d’exécution. Nice, simple, facile. Notez que le web est un type spécial de dyno, qui a access au monde extérieur, et qui se cache 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 queue 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 est de 0,05 $ l’heure pour une heure de service, comparativement à 0,025 $ l’heure pour une instance de micro AWS ou à 0,09 $ l’heure pour une petite instance AWS.

La documentation dyno d’Heroku indique que vous avez environ 512 Mo de RAM, il n’est donc probablement pas déraisonnable de considérer un dyno comme un micro-instance EC2. Est-ce que ça vaut le double du prix? Combien estimez-vous votre temps? La quantité de temps et d’efforts nécessaires pour créer une offre IaaS afin d’atteindre 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 la configuration et de la maintenance.

(Un peu de côté, 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 36 Go de RAM – cela m’amène à croire que je suis sur un ” Instance High Double Memory Extra Large ” . La documentation du dyno Heroku indique que chaque dyno reçoit 512 Mo de RAM, donc je partage potentiellement jusqu’à 71 autres dynos. (Je n’ai pas assez de données sur l’homogénéité des instances AWS d’Heroku, alors votre kilométrage peut varier))

Comment se comportent-ils face à leurs concurrents?

Je crains que je ne puisse pas vraiment t’aider. Le seul concurrent que j’ai jamais vraiment vu était Google App Engine – à l’époque, je cherchais à déployer des applications Java, et la quantité de ressortingctions sur les infrastructures et les technologies utilisables était incroyablement rebutante. Ceci est plus que “juste une chose de Java” – la quantité de ressortingctions générales et de considérations nécessaires ( les astuces de la FAQ à plusieurs) semblaient peu pratiques. 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 souhaitez aborder). Je pense que je devrais offrir ma position personnelle. J’aime Heroku pour les “déploiements rapides”. Lorsque je lance 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 seul dyno Web et de 5 Mo de PostgreSQL, il est gratuit pour héberger une application) . Pour le “déploiement de production sérieuse” avec plusieurs clients payants, avec un accord de niveau de service, avec un temps dédié pour les opérations, et cetera, je ne peux pas me résoudre à transférer à Heroku autant de contrôle qu’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, sans avoir à passer du temps à rassembler toutes les autres infrastructures autour de votre code. Je vais 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 généralement que la plupart des gens, lorsqu’ils voient “AWS”, sautent aux choses comme EC2 et S3 et EBS, qui sont certainement des offres IaaS

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

Le 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 leurs activités au lieu 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, tel que l’agilité, la haute disponibilité, la surveillance, l’échelle / le détournement, le besoin d’expertise limité, le déploiement aisé et la réduction des coûts et du développement, constituent d’autres fonctionnalités.

Mais le PaaS a toujours un côté obscur qui entrave 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 régis correctement
  • Prématuré et douteux de nos jours

En plus de ce qui précède, vous devriez avoir suffisamment de compétences pour vous confier IaaS:

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

Si vous avez des petites entresockets, 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 la charge, la récupération après sinistre
  • PaaS gère toutes les exigences de sécurité
  • PaaS gère la fiabilité, haute disponibilité
  • Paas gère pour vous de nombreux modules complémentaires tiers

Ce sera un choix totalement individuel basé sur l’exigence. Vous pouvez avoir des détails sur mes applications PPT Hosting Rails .

Il y a beaucoup de manières différentes de considérer cette décision à partir d’objectives de développement, d’informatique et d’entreprise, alors ne vous sentez pas mal si cela semble insurmontable. Mais aussi, évitez la montée en charge.

Pensez à vos besoins .

J’ai conçu des sites Web qui ont desservi plus de 8 millions de visiteurs uniques par jour et fourni des téraoctets de vidéo par semaine sur des infrastructures à partir de 250 000 dollars de matériel informatique, grâce à un important personnel informatique.

Mais j’ai aussi eu de plus petits sites Web conçus pour générer de 10 à 20 000 dollars par an, sans trafic, sans db ou exigences de traitement, et je les ai exécutés sans compromis sur un compte d’hébergement générique à 10 $ / mois.

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

Gardez également à l’esprit qu’avec un site Web commercial – l’évolutivité est ce que nous appelons souvent un «problème à résoudre» – même si les problèmes d’évolutivité avec des sites comme Facebook et Twitter ont été très médiatisés, leur réussite n’a pas eu d’effet négatif aurait même consortingbué à plus d’inscriptions (toute la presse est bonne presse).

Si vous avez un service qui génère 100 k + uniques par jour et qui a des problèmes de mise à l’échelle, je serais ravi de vous les prendre, peu importe la langue, la firebase database, la plate-forme ou l’infrastructure que vous utilisez!

L’évolutivité est un problème d’implémentation réparable – ne pas avoir 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-le (avec git) sur heroku gratuitement pendant un certain temps (utilisez le niveau gratuit heroku pour le proposer au public) et testez-le ainsi. En comparaison avec la location d’un serveur, c’est très rentable, mais vous devrez parler avec un apk heroku plus ressortingctif, 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

Les réponses existantes sont globalement précises:

  • Heroku est très facile à utiliser et à déployer, il peut être facilement configuré pour un déploiement automatique d’un référentiel (par exemple, GitHub), possède de nombreux modules complémentaires et des frais supplémentaires par instance.

  • AWS propose une gamme plus large de services de première partie à des prix compétitifs, notamment le DNS, l’équilibrage de la charge, le stockage de fichiers à bas prix et des fonctionnalités d’entreprise telles que la définition de règles de sécurité.

Pour le tl; dr, passez à la fin de cet article.

AWS ElasticBeanstalk est une tentative de fournir une plate-forme de déploiement automatique et de mise à l’échelle automatique de type Heroku. Comme il utilise les instances EC2 (qu’il crée automatiquement), les serveurs EB peuvent faire tout ce que toute autre instance EC2 peut faire et c’est peu coûteux à exécuter.

Le déploiement avec EB est très lent. Le déploiement d’une mise à jour peut prendre de 10 à 15 minutes par serveur et le déploiement sur un cluster plus volumineux peut durer une heure, contre quelques secondes pour déployer une mise à jour sur Heroku. Les déploiements sur EB ne sont pas traités de manière particulièrement transparente, ce qui peut imposer des contraintes à 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, Groupes Auto Scaling – et CodeCommit, CodeBuild et CodePipeline si vous voulez tout utiliser). quelques semaines pour la première fois car elle est assez compliquée et légèrement plus délicate que de simplement configurer des choses dans EC2.

AWS Lightsail offre une option d’hébergement à un prix compétitif, mais ne permet pas le déploiement ou la mise à l’échelle – il ne s’agit en réalité que d’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 intéressant, mais coûteux comparé au coût de la configuration d’une instance EC2 (que vous pouvez également faire par programmation).

Quelques reflections sur la comparaison (pour essayer de répondre aux questions, mais de manière 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 l’importance du déploiement automatique, de la mise à l’échelle automatique et de la configuration et de la configuration SSL.

    Le déploiement automatique lorsque vous mettez à jour votre repository Git est sans effort avec Heroku. Il est quasiment instantané, gracieux, il n’y a donc pas de pannes pour les utilisateurs finaux et peut être configuré pour se mettre à jour uniquement si les tests / Intégration continue réussissent pour que vous ne cassiez pas votre site si vous déployez du code cassé.

    Vous pouvez également utiliser ElasticBeanstalk pour un déploiement automatique, mais préparez-vous à passer une semaine à le configurer pour la première fois. Vous devrez peut-être modifier la façon dont ElasticBeanstalk gère les déploiements ou construire la logique. dans votre application pour gérer les déploiements.

    Soyez attentif à l’estimation des coûts 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 l’ancien service jusqu’à ce que toutes les demandes lui soient faites en cours de traitement (puis il le supprime).

    Il est intéressant de noter que le coût d’hébergement de plusieurs serveurs avec EB peut être meilleur marché qu’une seule instance d’Heroku, en particulier lorsque 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 fournisseur différent pour la production et le développement est une mauvaise idée.

    Je crains que les gens ne le suggèrent. Si, idéalement, le code devrait fonctionner correctement sur toute plate-forme raisonnable, il est aussi portable que possible. Les versions des logiciels sur chaque hôte varieront considérablement et le simple fait que le code s’exécute ne signifie pas qu’il s’exécutera en production (p. Ex. Les versions Ruby / Python / PHP / Perl peuvent différer de manière à rendre le code incompatible, souvent de manière silencieuse et susceptible de ne pas être détectée même si vous disposez d’une couverture de test correcte.

    Une bonne idée est de tirer parti de produits tels que Heroku pour le prototypage, les projets plus petits et les microsites. Vous pouvez ainsi créer et déployer vos produits rapidement, sans avoir à consacrer beaucoup de temps à 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 réplication de l’environnement complet (services tiers tels que magasins de données / ajouts, installation et configuration de SSL, etc.) .

  2. Si vous utilisez AWS, méfiez-vous des instances préconfigurées par AWS provenant de fournisseurs tels que Bitnami – elles constituent un cauchemar en matière de sécurité. Ils peuvent exposer beaucoup d’applications notoirement vulnérables par défaut sans en faire mention dans la description.

    Envisagez plutôt d’utiliser simplement une dissortingbution standard bien supscope, telle qu’Ubuntu ou Debian (ou CentOS si vous avez besoin du support RPM).

    Remarque: Amazon offre sa propre dissortingbution appelée Amazon Linux, qui utilise RPM, mais elle est spécifique à EC2 et moins bien prise en charge par les logiciels tiers / open source.

  3. Vous pouvez également configurer une instance EC2 sur AWS (ou Lightsail) et la configurer avec quelque chose comme flynn ou dokku – sur lequel vous pourrez ensuite déployer facilement plusieurs sites, ce qui peut être utile si vous maintenez beaucoup de services ou souhaitez être capable de lancer facilement de nouvelles choses. Cependant, le configurer n’est pas aussi simple à utiliser qu’Heroku et vous pouvez finir par le configurer et le maintenir (au point que le déploiement à l’aide d’Amazon clustering et de Docker Swarm est plus simple que leur configuration). 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 plusieurs milliers par an si je l’utilisais pour tout et qu’AWS réduisait les coûts.

tl; dr

Si l’argent n’était jamais un problème, j’utiliserais Heroku pour presque tout, car cela représente un gain de temps considérable – 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 qu’Heroku n’offre pas.

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

Voici un exemple de service qui est presque celui-ci : now.sh , qui utilise en fait AWS en arrière-plan, mais facilite les déploiements et la mise en grappe sur Heroku (avec SSL automatique, DNS, déploiements harmonieux , configuration de cluster très simple et la gestion).

Je l’ai beaucoup utilisé pour les déploiements d’applications Node.js et Docker, le principal inconvénient étant que les instances sont partagées (ce qui se reflète dans leur moindre coût) et qu’il n’ya actuellement aucune option pour acheter des instances dédiées. Toutefois, leur outil de déploiement open source ‘now’ peut également être utilisé pour être déployé sur des instances dédiées sur AWS, ainsi que sur Google Cloud et Azure.

Eh bien, les gens posent généralement cette question: Heroku ou AWS au moment de commencer à déployer quelque chose.

Mon expérience d’utilisation des deux Heroku & AWS, voici mon examen rapide et ma comparaison:

Heroku

  • Une commande à déployer quels que soient vos types de projets: Ruby on Rails, Nodejs
  • Tant de clics pour intégrer des plugins et des tiers: il est très facile de commencer avec quelque chose.
  • Ne pas avoir de mise à l’échelle automatique; cela signifie que vous devez monter / descendre manuellement
  • Le coût est cher, surtout lorsque le système a besoin de plus de ressources
  • Instance gratuite disponible
  • L’instance libre s’endort si elle est inactive.
  • Centre de données: États-Unis et UE uniquement
  • POUVEZ vous 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 access complet!
  • Pas besoin d’en savoir trop sur DevOps

AWS – EC2

  • Cela ressemble à une machine avec pré-OS de configuration (ou non), vous devez donc 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)
  • Mise à l’échelle automatique et é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 de T2.micro, mais généralement, vous paierez quelques dollars chaque mois (si vous utilisez toujours T2.micro)
  • Votre instance gratuite ne s’endort pas, disponible 24/7 (parce que 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. Donc vous pouvez en profiter
  • Quelques connaissances sur DevOps, mais ça va, Stackoverflow est utile là-bas!

AWS Elastic Beanstalk une alternative à Heroku, mais moins chère

  • Elastic Beanstalk a été annoncé en tant que 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 que cela peut être le remplacement de Heroku et moins cher!

Résumé

  • Heroku: Facile au début, exemple GRATUIT , mais coûteux plus tard
  • AWS: Pas facile, des heures gratuites disponibles, un peu moins chère , 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!

Il s’agit d’un pourcentage important de nos activités de migration de personnes de Heroku vers AWS. Il y a des avantages à la fois, mais Heroku devient désordonné après un certain temps… une fois que vous avez besoin d’un certain niveau de complexité, il n’est plus facile de le 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 d’excellents frameworks / outils.

Ce qui est drôle, c’est que Heroku utilise AWS sur le backend. Il supprime tous les frais généraux et gère l’architecture sur EC2 pour vous. (Vous avez cette connaissance d’un ingénieur principal d’une grande entreprise lors d’une entrevue)

Amazon Web Services (AWS) offre de nombreux services de IaaS à PaaS avec une durabilité garantie de 99,9999999 et la disponibilité des données et de l’infrastructure. AWS propose l’automatisation de l’infrastructure ainsi que plusieurs outils permettant aux développeurs de canaliser 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 cloud. Il n’est nulle part avec AWS que ce soit l’infrastructure ou la sécurité.

Bien! I observateur Heroku est célèbre dans les développeurs en herbe et les nouveaux-nés tandis qu’AWS a avancé un personnage de développeur. DigitalOcean est également un acteur majeur sur ce terrain. Cloudways a beaucoup facilité la création d’une stack de stacks en un clic sur DigitalOcean et AWS. Avoir tous les services et paquets 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/

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

Heroku est gratuit, simple et facile à déployer presque tous les types de stacks sur le Web. Heroku est spécialement conçu pour contourner tous les soucis liés à l’expédition de votre application sur un serveur en temps réel.

Néanmoins, vous souhaiterez peut-être déployer votre application en utilisant l’un des didacticiels des deux parties et comparer

AWS DOCS et Heroku Docs

Eh bien Heroku utilise AWS en arrière-plan, tout dépend du type de solution dont vous avez besoin. Si vous êtes un utilisateur de Linux et de développeurs, vous ne craignez pas de créer vm from scratch comme de sélectionner et de choisir des options de palmarès, vous pouvez utiliser AWS. Si vous voulez faire les choses à la surface sans avoir ces nettigrations, vous pouvez aller avec Heroku.

Even though both AWS and Heroku are cloud platforms, they are different as AWS is IaaS and Heroku is PaaS

I ve read some answers about HEROKU and AWS being so different (the first is Platform as Service and the second is Infra as Service. To put the comparison into perspective, amazon does offer a PaaS solution its named AWS Elastic Beanstalk. For comparison about those , please check the below URL https://dzone.com/articles/heroku-or-amazon-web-services-which-is-best-for-your-startup

well.. its not all that rosy..

first of all: AWS is not rocket science, and if you know your way around deploying “things” at the end of the day its better to use AWS, and cheaper .. instead of any other PaaS which tend to be always more expensive in exchange of doing “things” for you … IMHO AWS is lot better and you have lot more control overall,

especially now when there is rightScale , bitnami, etc … and all those pre made EC2 images for so many different software stacks.