Quelle est votre expérience de l'utilisation de Ruby on Rails sur Heroku dans un environnement de production ?
En dehors de la question du coûteux HTTPS, voyez-vous un inconvénient dans la façon dont il gère les processus, la mémoire et le stockage ?
Les gens de Heroku sont plutôt sympathiques et je suis sûr qu'ils sont prêts à répondre à mes questions, mais j'aimerais avoir des avis du côté des clients.
J'ai deux systèmes en production sur Heroku (1 Dyno, 6 Dynos respectivement), et je suis sur le point de lancer un projet assez important utilisant la plateforme.
Je l'aime absolument.
Je veux me concentrer sur la valeur que j'apporte dans la chaîne - une application soigneusement conçue, avec une expérience utilisateur et une assistance de qualité.
La véritable valeur de Heroku est que tous les frais d'administration sont supprimés. J'ai déjà travaillé avec un hébergement VPS (Slicehost, Linode) et j'ai constaté que le réglage d'une seule pile d'applications peut être vraiment très compliqué sans une ressource sysadmin dédiée. Une fois que vous commencez à entrer dans le domaine des serveurs multiples, vous pouvez vous retrouver embourbé dans l'administration du système et non dans le développement et le support des applications.
Heroku fournit une pile qui comprend un proxy inverse et un cache http en plus de la gestion des processus de l'application Rails ... la mise en place de tout cela dans un environnement VPS serait une entreprise sérieuse et coûteuse.
Si une ressource sysadmin coûte 100 $/heure et qu'un banc d'essai coûte 36 $/mois, il est possible de lancer des bancs d'essai sur votre application avant que le rapport coût-bénéfice ne commence à changer.
Les prix du stockage viennent également d'être modifiés : vous disposez désormais de 20 Go de ressources partagées pour la base de données pour 15 dollars par mois, ce qui change vraiment la donne pour de nombreuses petites applications.
La mémoire n'est plus un souci ... un banc d'essai semble avoir automatiquement assez de mémoire pour fonctionner. C'est logique : Thin, Mongrel, Passenger chargent tous l'instance de l'application Rails en mémoire, ce qui rend les besoins en mémoire assez prévisibles (en dehors des fuites de mémoire, bien sûr). Avec Heroku, s'il y a un problème avec une instance, elle est simplement arrêtée et une nouvelle instance est démarrée - tout cela se passe de manière transparente.
L'autre grande victoire pour moi est que le mécanisme de routage de Heroku garantit une réponse presque linéaire... si une demande prend 100 ms à traiter, votre réponse sera essentiellement de 10 demandes par seconde. Le maillage de routage de Heroku garantit que vos processus ne sont pas surchargés dans des limites de charge raisonnables (si vous êtes vraiment assailli, vous devrez ajouter des ressources, mais les charges en rafale à court terme semblent être très bien gérées).
Sur mon projet actuel, j'ai testé les performances de chaque fonctionnalité majeure au fur et à mesure de sa construction afin d'avoir une idée des performances globales du système, et la pile elle-même est assez facile à utiliser - les requêtes non réglées de lecture intensive dans mon application ont des temps de réponse inférieurs à 50 ms (dyno unique, base de données partagée).
Je n'ai pas encore rencontré de goulot d'étranglement dans la plate-forme elle-même.
Tout ceci étant dit, l'hypothèse sous-jacente avec Heroku est que vous avez une application rails "vanille" - base de données, application CRUD, etc. etc. Certaines choses ne sont tout simplement pas possibles sur Heroku.
Il y a un certain point dans l'échelle où l'exploitation de vos propres serveurs (en particulier en dehors d'une pile virtualisée) devient beaucoup plus rentable (le passage récent de GitHub d'EngineYard à RackSpace souligne ce point).
Comme mentionné par @theIV, la meilleure chose à faire est d'essayer et de voir. Il est très facile de configurer une application, et il n'y a aucun changement d'architecture requis (à part le fait de ne pas utiliser le système de fichiers local (ce qui n'est pas un problème pour moi car je pousse toujours les fichiers générés par l'utilisateur vers Amazon S3). Le module complémentaire de base NewRelic RPM est gratuit, ce qui vous permet d'avoir un aperçu instantané des performances de votre application.
Au cours des trois derniers mois, j'ai déployé une application sur Heroku qui a atteint le stade de la bêta privée et nous prévoyons un lancement complet très bientôt. (Je dirai que, dans l'ensemble, je suis satisfait de la facilité d'administration et de déploiement offerte par Heroku, mais qu'il y a certainement quelques imperfections.
Je vais d'abord parler des avantages. J'ai l'expérience de l'exécution de mes propres applications Rails sur des clusters Thin en reverse-proxie dans Nginx sur mon propre VPS depuis un certain temps. C'est un peu difficile à mettre en place, mais en général rien qu'un développeur intelligent ne puisse gérer avec un peu d'apprentissage et de pratique. Comme je n'avais pas le temps de passer par cette étape de mise en place, mais que j'avais aussi vraiment besoin d'un environnement de production performant, j'ai été enthousiasmé par la solution sophistiquée qu'offre Heroku. La facilité de déploiement et la flexibilité de son système m'ont permis d'économiser plus d'heures qu'il n'en faut pour réaliser un retour sur investissement, puisque j'ai pu me concentrer largement sur le développement d'applications. Le déploiement est aussi simple qu'un git-push, et la mise à l'échelle des dynos se fait en quelques clics de souris.
Les plaintes que j'ai à formuler sont toutefois un peu préoccupantes. Je veux réitérer ce que le IV a mentionné au sujet de Heroku qui a retiré l'add-on Zerigo. Ils l'ont fait sans aucun avertissement, et cela s'est produit à un moment où j'avais besoin d'apporter un changement à certains de mes enregistrements DNS. Pour la défense de Heroku, je dirai que dans un ticket de support agité ou deux plus tard (si cela a accéléré la situation) ils ont restauré l'accès à l'add-on. Mais à ce moment-là, j'avais déjà quitté le navire avec notre DNS et migré nos serveurs de noms dans un compte Zerigo (payant) à part entière.
Ce n'est pas le seul problème que j'ai rencontré avec Heroku jusqu'à présent. Il y a un mois ou deux et pendant une période de deux semaines, j'ai connu des déploiements vraiment peu fiables. Je recevais des erreurs sporadiques de Taps qui bloquaient le déploiement. (Taps est la migration de base de données Rubygem développée par Heroku). Après un ticket de support et quelques jours, le problème a été résolu et il semble qu'une version incorrecte de taps ait été déployée sur certains dynos. Avec un peu de chance, ce problème n'a pas fait échouer les déploiements sur Prod. mais cette expérience a sapé ma confiance dans la fiabilité de Heroku.
Jusqu'à présent, le support de Heroku a été très utile, mais parfois pas aussi réactif qu'on pourrait le souhaiter pour un hébergeur d'un site de production. Ceci est exacerbé par le fait qu'ils ne proposent actuellement qu'une assistance par e-mail, et qu'il n'y a pas de ligne téléphonique d'urgence. Je crois avoir lu ou entendu quelque part qu'ils prévoient de mettre en place une ligne téléphonique d'assistance, mais qui sait quand cela se produira. (Ils semblent être quelque peu lents à convertir leurs add-ons "à venir" en add-ons que vous pouvez réellement utiliser).
Je veux revenir sur mon opinion et souligner que Heroku a été une bonne expérience en général, mais que leur système n'est pas encore aussi fluide qu'il devrait l'être. On a vraiment l'impression qu'ils n'ont pas les ressources humaines dont ils ont besoin pour être en mesure de soutenir leur activité aussi complètement qu'ils le devraient, mais je suis optimiste qu'ils vont s'améliorer sur ce point.
Heroku m'a incité à rechercher un hébergeur en nuage pour mes sites personnels. Je n'ai pas d'argent, j'ai donc choisi Rackspace Cloud et je vais devoir trouver le temps de tout configurer pour pouvoir migrer mes sites personnels depuis mon hébergeur VPS actuel (RootBSD, que je recommande vivement si vous cherchez un VPS). En fait, je pense que lorsque je serai suffisamment à l'aise avec ma configuration sur Rackspace Cloud, et probablement aussi lorsque mon entreprise sera en mesure d'embaucher un administrateur à plein temps, je pourrais très bien nous faire migrer notre application de Heroku à Rackspace Cloud pour 2 raisons : 1) Quand nous en serons au point où nous aurons un grand nombre de dynos, Rackspace aura probablement un meilleur retour sur investissement, et 2) Ils ont une ligne téléphonique de support ; j'ai appelé une fois jusqu'à présent et j'ai été immédiatement répondu et soutenu par une voix amicale !
Cependant, jusqu'à ce que nous atteignions le point où j'ai le temps de m'occuper de l'administration de notre propre serveur, Heroku m'épargnera ce casse-tête (surtout en ce qui concerne la sécurité du serveur) !
Je supervise le développement d'un service web fonctionnant sur Heroku depuis environ 7 mois maintenant.
Les plus gros reproches :
1) Ne joue pas bien avec les médias statiques, vous oblige à compter sur un service comme S3 et cela peut être un problème. Par exemple, mon application fait beaucoup de travail de traitement d'images, et rien n'est pire que de devoir faire du trafic entre S3 avec de grandes images encore et encore. Très lent.
2) Délai de 30 secondes pour les demandes. Je le comprends, mais j'aimerais avoir certaines exceptions à cette règle qui n'existe pas.
3) Quand Heroku tombe en panne, il tombe durement. Il ne devient pas plus lent, il ne bégaie pas. Il meurt simplement. Et il meurt durement. Ce qui est mauvais. Pourquoi pas de basculement ?
4) Dynos + New Relic devient très vite hors de prix. Payer presque 400 dollars pour 4 dynos et 2 travailleurs et quelques addons. Vous vous rapprochez du territoire où un VPS multi-core est une meilleure option.
En dehors de ce qui précède, tout est plutôt bien.
Ce que j'aime avec Heroku, c'est que vous avez presque tout ce dont vous avez besoin sans aucun frais de configuration. La seule chose qui me manque actuellement est une base de données orientée documents comme Mongo DB.
J'aime beaucoup l'architecture de mise en cache facile à utiliser fournie par leur proxy Varnish. La mise en cache des requêtes est on ne peut plus simple. Récemment, j'ai dû construire un service qui consomme les données d'un serveur lent et les transforme en JSON qui est ensuite utilisé pour alimenter une application JQTouch sur un iPhone. Comme il n'était pas nécessaire de stocker les données dans une base de données, j'ai simplement utilisé les en-têtes HTTP pour définir des dates d'expiration appropriées et j'étais prêt à partir. Je ne sais pas combien de temps il m'aurait fallu pour mettre en place une infrastructure similaire. Mais cela m'aurait certainement pris du temps.
Mais je pense que le plus étonnant, c'est qu'il vous suffit de pousser votre dépôt pour que tout fonctionne.
Étant donné que chaque application, site Web, blog et garderie pour chiens présente des différences, je pense que votre meilleure chance est de l'essayer. Le prix est assez bon marché pour que vous ne puissiez pas vraiment aller mal pendant un mois ou deux.
Nous avons deux sites web relativement petits qui fonctionnent sur Heroku et ils sont très bien. Je n'ai pas encore remarqué de problèmes, à part la suppression récente de l'accès à votre module complémentaire Zerigo pour gérer les DNS (dont on nous a assuré qu'il serait rétabli sous peu).
Si vos dynos et votre base de données ne suffisent pas à gérer votre charge, alors vous devrez peut-être déménager, mais je pense que ça vaut le coup d'essayer.
Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.
