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

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.

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.

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

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 .

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.

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

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!

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.

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.

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)

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/

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.

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é.

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

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

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.