J'ai cherché sur Google, mais je voulais plus d'avis avant de m'engager dans l'un ou l'autre service. Quelqu'un a-t-il une expérience de l'un ou l'autre de ces services (ou peut-être des deux) ? Y a-t-il des avantages ou des inconvénients qui ressortent de l'un ou l'autre ? Les domaines d'intérêt particuliers sont les suivants :
Funky,
Je travaillais auparavant pour Engine Yard, alors laissez-moi vous donner des informations sur notre service Engine Yard Cloud (fonctionnant sur AWS). Je vous laisse faire vos propres recherches sur vos autres options.
À mon avis, les machines virtuelles au niveau du matériel sont l'un des fondements du succès d'Amazon et la raison pour laquelle rien de tel n'est apparu avant que les machines virtuelles n'arrivent à maturité (mais je suis partial car j'étais un ancien de VMware et j'ai vu cela se produire en temps réel).
Stabilité Nous avons une grande expérience de ce qui peut être fiable et de ce qui ne peut pas l'être dans les composants Ruby/Rails. Actuellement, ferret, juggernaut et awstats figurent sur notre liste des composants à ne pas déployer. Sinon, nous héritons de l'uptime d'AWS car nous n'avons pas d'infrastructure partagée dans le chemin des données. La disponibilité d'AWS a été plutôt bonne, mais je n'essaierais pas de faire fonctionner une centrale nucléaire avec elle pour le moment. La fiabilité du déploiement a été mitigée récemment - Amazon semble être un peu plus près du vent en ce qui concerne l'utilisation de la capacité, de sorte qu'à certaines occasions, une demande d'ajout de capacité échoue et doit être réémise.
Évolutivité. Nous avons quelques grosses applications fonctionnant sur le cloud Engine Yard. Playmesh était l'application iphone numéro 1 en novembre dernier et a augmenté sa capacité pour bien la gérer. Nous avons évalué que même une petite instance (4 mongrels) était capable de gérer 85 millions de requêtes par mois à charge constante (application très simple). Nous recommandons aux gens d'utiliser des instances plus grandes s'ils veulent beaucoup d'entrées/sorties de disque, Amazon fournit un meilleur débit d'entrées/sorties pour les instances de plus grande taille. Dans tous les cas, l'ajout ou la suppression de capacité se fait littéralement en un clic de bouton.
Prix Faire fonctionner une petite instance (4 bâtonnets) à plein temps pendant un mois vous coûtera 79 $ sur EY Cloud ou 0,11 par heure (contre 8,5 cents sur Amazon nu). Cela inclut la gestion de la base de données, mais vous paierez un petit montant pour le stockage et la bande passante - que Engine Yard Cloud répercute au coût AWS. Nous sommes convaincus qu'une fois que vous aurez atteint une quantité raisonnable de trafic, nous serons une bonne affaire.
Permettez-moi d'ajouter quelques autres critères que vous pourriez considérer...
Assistance -> vous bénéficiez gratuitement de l'assistance de la communauté/du forum, mais nous proposons également une option d'assistance sous forme de tickets. L'option d'assistance premium permet de surveiller votre application 24 heures sur 24, 7 jours sur 7, et nous vous informerons lorsque votre application tombera en panne et nous la dépannerons pour vous si c'est la pile supportée qui pose problème.
Communauté -> Certains s'en soucient, d'autres non, mais Engine Yard sponsorise deux contributeurs Rails à plein temps, une équipe JRuby de trois personnes et la nouvelle VM Ruby, Rubinius. Nous nous engageons à faire de Rails et Ruby la meilleure plateforme de développement d'applications web qui soit.
Automatisation -> il suffit de regarder la démo pour le voir en action, mais c'est chouette. Nous sommes également en version bêta avec les déploiements git en ligne de commande, consultez la base de connaissances pour les voir en action.
Je présume que vous parlez de l'hébergement EC2 d'Engine Yard, plutôt que de leur pile de services complets ?
Je travaille avec Heroku, et je l'adore. En ce qui concerne le prix, Heroku est le grand gagnant pour moi. Les coûts de bande passante sont abstraits grâce à Heroku, ce qui est une grande victoire.
Sur le plan de la sécurité, c'est un peu difficile à dire, ce qui est l'une des critiques les plus courantes à l'égard du cloud. Vous n'avez pas beaucoup d'informations sur la pile qui fonctionne sur l'un ou l'autre service.
Heroku a investi énormément dans la technologie pour surveiller et gérer de manière transparente les instances d'application. Si quelque chose ne va pas, l'instance est abandonnée et une nouvelle est lancée. C'est merveilleux.
En ce qui concerne l'évolutivité, les deux sont adossés à Amazon et exploitent EC2 et EBS, donc probablement la même chose en termes de capacité brute.
Ce sont des approches complètement différentes.
Heroku est une solution PaaS ruby, similaire à google app engine. Elle vous permet de faire évoluer une application sans avoir de compétences en administration système, à condition que votre application s'intègre dans l'écosystème qu'elle fournit.
Engine Yard est un service plus traditionnel, qui vous donne accès à des boîtes et vous fournit des outils pour vous faciliter la vie. Comme il s'agit d'une abstraction, il vous offre une plus grande flexibilité, mais il requiert également de votre part de plus grandes compétences en matière d'administration système.
Il s'agit d'un fil de discussion assez ancien, avec des réponses plutôt anciennes. J'ai donc pensé qu'une réponse plus actuelle pourrait aider certaines personnes.
J'ai une assez bonne expérience de l'utilisation de Heroku et d'Engine Yard pour des services web assez importants et complexes. Mon entreprise utilise Engine Yard pour exécuter Andromo App Maker pour Android et nous utilisons Heroku pour exécuter AirBop Push Messaging Service pour Android. Chaque plateforme possède des capacités qui lui sont propres.
Il est un peu difficile de répondre à votre question, tout simplement parce que la plupart des critères qui vous intéressent ne sont pas les caractéristiques distinctives de chaque plateforme. Je répondrai quand même à ces points, mais j'aborderai aussi la philosophie générale de chaque plateforme et les différences de support technique qui me semblent plus utiles pour votre décision.
La sécurité, la stabilité et l'évolutivité ne sont pas prises en compte. Les deux services sont aussi sûrs et stables que n'importe quelle instance Amazon EC2. L'évolutivité est également identique, de manière réaliste. Alors que Heroku vous limite à quelques centaines de petites (512k) instances (ou maintenant "double" petites), Engine Yard vous permet d'utiliser Extra Large avec des tonnes de CPU et de mémoire, mais dans le monde réel, c'est à peu près la même chose au final. Avec Heroku, vous pourriez avoir besoin de créer un essaim de petits serveurs bon marché pour gérer votre charge, ou avec Engine Yard vous utiliseriez une poignée de plus gros serveurs plus chers. Pour les requêtes web, cela n'a probablement pas beaucoup d'importance.
Le prix est un facteur que je peux aborder un peu mieux. Tout d'abord, si vous ne faites que bricoler, Heroku est gratuit. Mais ne confondez pas cela avec le fait que vous pourriez vraiment faire fonctionner un vrai site Web avec leur niveau gratuit. Ce n'est pas le cas. Engine Yard vous offre également un grand nombre d'heures gratuites pour vous amuser, mais parlons des applications réelles. Heroku aplanit le problème de la tarification, en vous facturant des " dynos " (ces petits serveurs Web dont j'ai parlé) et un plan de base de données PostgreSQL. Leurs prix incluent le stockage, la sauvegarde, la bande passante, etc., il est donc assez facile de faire un calcul mental de ce que coûtent les choses. Engine Yard décompose les choses et vous devrez utiliser leur calculateur pour savoir ce que cela va coûter - mais tout est présenté pour vous avant que vous ne décidiez de lancer une nouvelle "instance".
Je trouve que les plans de base de données de Heroku sont très chers (par rapport à ce que coûte l'instance EC2 qu'ils utilisent). Ils font définitivement leur profit ici. Ce qui semblait bon marché pour les dynos a maintenant besoin d'une base de données de 200 à 400 dollars par mois (pour commencer à atteindre un niveau de performance raisonnable, il faut compter plus de 800 dollars). Je déteste également la façon dont ils cachent les spécifications de la base de données - vous devrez déduire les capacités en allant sur les données de taille d'instance d'Amazon et en regardant la "mémoire" que Heroku utilise pour le "cache".
La base de données d'Engine Yard est simplement l'instance de serveur que vous souhaitez. Ils ajoutent la même majoration EC2 que pour les instances web. Pas d'arnaque ici. C'est plus transparent.
L'un est-il moins cher que l'autre ? Peut-être, mais je ne laisserais pas quelques dollars brouiller votre décision.
En fin de compte, j'aime Engine Yard pour son contrôle "bare metal". Nous en avons besoin pour Andromo, car nous générons et compilons des applications Android à la volée et avons des exigences très spécifiques. Engine Yard nous donne un contrôle total sur chaque serveur, les paquets Unix, SSH, etc. D'autre part, Herkou fonctionne très bien dans les situations où vous pouvez abstraire votre application du matériel et vous lancer dans la réflexion sur l'essaim de dynos. Il est très rapide et facile de lancer des dizaines de dynos en quelques minutes. Comme je l'ai mentionné, nous exécutons AirBop sur la plateforme Heroku et avons automatisé la création/destruction de nos instances avec HireFire - ce qui fonctionne très bien pour nous car notre charge varie considérablement et de manière inattendue.
Un autre élément à prendre en compte est le support technique. D'après mon expérience, le support gratuit/inclus de Heroku est pratiquement inutile, alors que Engine Yard est très bon. EY avait l'habitude de faire payer le support de base mais a commencé à l'inclure dans tous ses plans (en plus, ils ont une option prioritaire disponible 24/7). J'ai constaté qu'ils savent vraiment de quoi ils parlent.
J'espère que cela vous aidera !
J'ai vérifié Bitnami, Heroku et Engine Yard et j'ai fait des tests sérieux contre Heroku et Engine Yard et Engine Yard était de loin le gagnant. Heroku fait des choses vraiment bizarres comme plafonner les processus à 250 Mo et leur réponse est que vous devez gérer votre propre mémoire. Je voyais de sérieux pics de performance sur heroku et il semble que parfois les processus se bloquaient et ne redémarraient pas pendant une minute avec plusieurs dynos web en cours d'exécution (ce qui n'est pas censé arriver). De plus, heroku met les processus en veille s'ils ne sont pas utilisés et il y a un problème de démarrage bizarre même avec plusieurs dynos. Plus l'inconvénient supplémentaire que je ne pouvais pas accéder aux fichiers journaux sur heroku et comprendre ce qui se passe. Après avoir déployé le même code exact sur Engine Yard et l'avoir regardé crier sans aucun pic de performance, je dois dire qu'Engine Yard est de loin le gagnant et le plus facile à déployer une fois que vous avez configuré votre système. Le coût est en fait moins cher sur Engine Yard que sur Heroku une fois que vous commencez à ajouter des dynos web et les performances sont bien, bien meilleures surtout si vous passez à la pile JRuby. J'ai essayé de mettre en place quelque chose sur Bitnami, mais d'après ce dont je me souviens, il était assez difficile de travailler avec. Je pense que Heroku est une bonne solution si vous n'êtes pas préoccupé par les performances ou l'évolutivité et que vous voulez juste déployer une application web simple ; il est probablement plus facile à utiliser que Engine Yard pour ce genre de choses.
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.
