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-east
eteu-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' web
exécution de 2 dynos et 10 worker
dynos. Nice, simple, facile. Notez que web
c'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/cpuinfo
et 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