Tout d'abord, AWS et Heroku sont des choses différentes. AWS offre d'Infrastructure as a Service (IaaS) alors que Heroku offrir une Plate-forme 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 sur le dessus de celui-ci; PaaS vous donne un environnement où vous venez de pousser code et d'une configuration de base et d'obtenir une application en cours d'exécution. IaaS vous donne plus de puissance et de flexibilité, le coût d'avoir à construire plus de vous-même.
Pour obtenir votre code en cours d'exécution sur AWS et en regardant un peu comme un Heroku de déploiement, vous aurez envie de certaines instances EC2 - vous aurez besoin d'un programme d'équilibrage de charge / couche de mise en cache est installé (par exemple, Vernis), vous aurez envie d'instances en cours d'exécution quelque chose comme Passager et nginx pour servir votre code, vous aurez envie de déployer et de configurer un cluster de base de données de l'instance de quelque chose comme PostgreSQL. Vous aurez besoin d'un système de déploiement avec quelque chose comme Capistrano, et quelque chose à faire du journal de l'agrégation.
Ce n'est pas une quantité insignifiante de travailler à mettre en place et à maintenir. Avec Heroku, l'effort nécessaire pour arriver à ce genre de scène est peut-être un peu de lignes de code de l'application et un git push.
Si vous êtes ici, et vous souhaitez mettre à l'échelle. Grand. Vous êtes à l'aide de Marionnettes pour votre EC2 déploiement, à droite? Alors maintenant, vous configurez votre Capistrano fichiers à tourner vers le haut/vers le bas les instances nécessaires; vous re-jig votre Marionnette config que le Vernis est conscient de web-travailleur instances et sera automatiquement piscine entre eux. Ou vous heroku scale web:+5.
J'espère que ça vous donne une idée de la comparaison entre les deux. Maintenant pour répondre à vos points précis:
Vitesse
Actuellement Heroku ne fonctionne que sur AWS instances 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 de considération.
Sécurité
J'ai vu beaucoup de l'intérieur entretenu des serveurs de production qui sont en retard sur les mises à jour de sécurité, ou, en général, mal ficelé. Avec Heroku, vous avez quelqu'un d'autre à gérer 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 êtes effectivement de remettre votre code directement sur Heroku. Cela peut être un problème pour vous. Leur article sur la Puissance de l'Isolement des détails de leur isolement technologies (il semble que plusieurs des dynamomètres sont exécutés sur les différents instances EC2). Plusieurs collègues ont exprimé des problèmes avec ces technologies et de la force de leur isolement; je suis hélas pas en mesure de suffisamment de connaissances / expérience pour vraiment me prononcer, mais je Heroku déploiements de considérer que "assez bon". Il peut être un problème pour vous, je ne sais pas.
Mise à l'échelle
J'ai touché sur ce que l'on pourrait le mettre en place dans mon IaaS vs PaaS comparaison ci-dessus. En gros, votre application a un Procfile, ce qui a des lignes de la forme dyno_type: command_to_run, par exemple (chipé par http://devcenter.heroku.com/articles/process-model):
web: bundle exec rails server
worker: bundle exec rake jobs:work
Ce, avec un:
heroku scale web:2 worker:10
vous permettra de disposer de 2 web des dynamomètres et de 10 worker des dynamomètres en cours d'exécution. Sympa, simple, facile. Notez que web est un spécial dyno type, qui a accès au monde extérieur, et est à l'origine de leur belle le trafic web multiplexeur (probablement une sorte de Vernis / nginx combinaison) qui permettra d'acheminer le trafic en conséquence. Vos travailleurs probablement interagir avec un message de la file d'attente pour le trajet similaire, à partir de laquelle ils vont obtenir 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 $/h pour une puissance de l'heure, par rapport à 0,025 $/h pour une AWS instance micro $ou 0,09 $ /h pour une AWS petit exemple.
Heroku est dyno documentation dit que vous avez au sujet de 512 mo de RAM, donc c'est probablement pas trop déraisonnable d'envisager un banc comme un peu comme un micro instance EC2. Est-il en vaut le double du prix? Quelle valeur accordez-vous votre temps? La quantité de temps et les efforts nécessaires pour construire au-dessus d'une offre IaaS pour l'obtenir à cette norme 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 d'un côté, mais si je me connecte à un dyno à partir d'ici (heroku run bash), un examen rapide montre 4 carottes en /proc/cpuinfo et 36 GO de RAM, ce qui m'amène à croire que je suis sur un "High-Mémoire Double Instance Extra-Large". Le Heroku dyno documentation dit chaque dyno reçoit 512 mo de RAM, donc je suis potentiellement partage avec jusqu'à 71 autres dynamomètres. (Je n'ai pas assez de données sur la homogeny de Heroku AWS cas, si votre kilométrage peut varier))
Comment font-ils pour se démarquer de leurs concurrents?
Cela, je crains que je ne peux pas vraiment vous aider. Le seul concurrent que j'ai jamais vraiment regardé a Google App Engine - à l'époque, j'étais à la recherche pour déployer des applications Java, et le montant de restrictions sur utilisable des cadres et des technologies a été incroyablement rebutant. C'est plus que "juste un Java chose" - le montant de restrictions générales et les considérations nécessaires (la FAQ conseils à plusieurs) semblait moins de pratique. En revanche, le déploiement de Heroku a été un rêve.
Conclusion
J'espère que cela répond à vos questions (veuillez commenter si il y a des lacunes / d'autres zones que vous souhaitez traiter). Je pense que je devrais offrir à ma position personnelle. J'aime Heroku pour "quick déploiements". Quand je suis en démarrage d'une application, et je veux un bon marché d'hébergement (le Heroku niveau gratuit est génial, essentiellement si vous avez seulement besoin d'un web de dyno et 5 MO de PostgreSQL, il est libre d'héberger une application), Heroku est de ma position. Pour les "Serious Déploiement de Production" avec plusieurs clients payants, avec un niveau de service-contrat, avec le temps consacré à dépenser sur ops, et cetera, je n'arrive pas à me décharger que beaucoup de contrôle de Heroku, puis AWS ou de nos propres serveurs ont été la plate-forme d'hébergement de choix.
En fin de compte, c'est à propos de ce qui fonctionne le mieux pour vous. Vous dites que vous êtes "un programmeur débutant" - c'est peut-être que l'utilisation Heroku vous permet de vous concentrer sur l'écriture de Ruby, et ne pas avoir à passer du temps à l'obtention de toutes les autres infrastructures autour de votre code de construire. Je serais certainement essayer.
Remarque, AWS n'ont en réalité une offre PaaS, Elastic Beanstalk, qui prend en charge Ruby, Node.js, PHP, Python, .NET et Java. Je pense que généralement la plupart des gens, quand ils voient "AWS", de sauter à des choses comme EC2 et S3 et EBS, qui sont certainement des offres IaaS
