Heroku vs EngineYard: lequel vaut le plus l’argent?

J’ai cherché sur Google, mais je voulais plus d’opinions avant de m’engager dans l’un ou l’autre service. Quelqu’un at-il eu de l’expérience avec l’un des services (ou peut-être les deux)? Y a-t-il des avantages ou des inconvénients qui se distinguent l’un de l’autre? Les domaines d’intérêt particuliers sont:

  1. Sécurité
  2. La stabilité
  3. Évolutivité
  4. Prix

Je suppose que vous parlez de l’hébergement EC2 de Engine Yard, plutôt que de sa stack complète?

Je travaille avec Heroku et je l’aime. Sur le prix, Heroku est le gagnant évident pour moi. Les coûts de bande passante sont extraits par Heroku, ce qui représente un gros gain.

Sur le plan de la sécurité, c’est un peu difficile à dire – ce qui est l’une des critiques les plus courantes du cloud. Vous n’avez pas beaucoup d’informations sur la stack qui s’exécute 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. Quelque chose ne va pas et l’instance est supprimée et une nouvelle est lancée. Des trucs merveilleux

En ce qui concerne l’évolutivité, tous deux s’appuient sur Amazon et exploitent EC2 et EBS, ce qui est probablement très similaire en termes de capacité brute.

Froussard,

Je travaillais pour Engine Yard, alors laissez-moi vous donner les informations sur notre service Engine Yard Cloud (exécuté sur AWS). Je vous laisse faire vos propres recherches sur vos autres options.

  1. Sécurité Chaque compte Engine Yard Cloud est son propre compte Amazon en coulisse, ce qui signifie que vous disposez de machines virtuelles intégrales, exécutées par le matériel, qui vous sont dédiées pour exécuter votre application. Ainsi, les attaquants exploitant un buffer overflow zéro jour, etc., dans les C gems, Ruby, passagers, linux, etc., n’ont access qu’à un seul compte. Il n’y a pas d’infrastructure partagée dans le chemin de données. Nous surveillons les rapports de vulnérabilité de sécurité pour tous les éléments de notre stack et vous obtenez automatiquement de nouveaux correctifs lorsque vous redéployez. Vous obtenez un access SSH complet à vos instances et bénéficiez d’un environnement de serveur normal lorsque vous devez installer des packages tels que Solr ou Sphinx ou la manipulation d’images, etc.

Dans mon esprit, les machines virtuelles au niveau matériel sont l’un des fondements du succès d’Amazon et pourquoi rien de tel n’a précédé la maturation des machines virtuelles (mais je suis partial parce que j’étais un gars de VMware et que cela se passait en temps réel) )

  1. Stabilité Nous avons beaucoup d’expérience avec ce qui peut être fiable et ce qui ne l’est pas dans les composants Ruby / Rails. Actuellement, notre liste “ne pas déployer” comprend furet, juggernaut et awstats. Sinon, nous héritons de la disponibilité d’AWS car nous ne disposons pas d’infrastructure partagée dans le chemin de données. La disponibilité d’AWS a été très bonne, mais je n’essaierais pas encore de faire fonctionner une centrale nucléaire. La fiabilité du déploiement a été mélangée récemment – Amazon semble être un peu plus proche de l’utilisation de la capacité, de sorte qu’à certaines occasions, une demande d’ajout de capacité échouera et devra être republiée.

  2. Évolutivité Nous avons de grandes applications en cours d’exécution sur le Cloud Engine Yard. Playmesh avait l’application iphone numéro 1 en novembre dernier et a augmenté sa capacité à bien le gérer. Nous avons même évalué une petite instance (4 métis) capable de gérer 85M / Req par mois à charge constante (application très simple). Nous recommandons aux utilisateurs de s’exécuter sur des instances plus importantes s’ils souhaitent avoir beaucoup d’E / S sur disque, alors qu’Amazon fournit un meilleur débit d’E / S à des tailles d’instance plus importantes. Dans tous les cas, l’ajout ou la suppression de capacité est littéralement un clic sur un bouton.

  3. Prix ​​Exécuter une petite instance (4 métis) à temps plein pendant un mois vous coûtera 79 $ sur EY Cloud ou 0,11 par heure (contre 8,5 cents sur Amazon nue). Cela inclut la gestion de la firebase database, mais vous payez une petite sum pour le stockage et la bande passante, que Engine Yard Cloud transmet au coût AWS. Nous sums persuadés qu’une fois que vous aurez atteint un volume de trafic raisonnable, nous serons en plein accord.

Permettez-moi d’append quelques autres critères que vous pourriez vouloir considérer …

  1. Support -> vous bénéficiez de la prise en charge gratuite de la communauté / du forum, mais nous avons également une option de support payant, l’option de support premium permet de surveiller votre application 24×7 et nous vous avertirons en cas de problème. stack c’est un problème.

  2. Communauté -> Certaines personnes se soucient de cela, certaines personnes ne le font pas, mais Engine Yard sponsorise 2 consortingbuteurs à temps plein, une équipe de trois personnes JRuby et la prochaine génération de Ruby VM, Rubinius. Nous nous engageons à faire de Rails et Ruby la meilleure plateforme pour développer des applications Web.

  3. Automation -> il suffit de regarder la démo pour la voir en action, mais c’est chouette. Nous sums également en version bêta avec la ligne de commande git deploys, consultez la base de connaissances pour la voir en action.

Ce sont des approches complètement différentes.

Heroku est une solution Ruba PaaS, similaire au moteur d’application Google. Il vous permet de dimensionner une application sans compétences d’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 access à des boîtes et vous fournit des outils pour vous simplifier la vie. Comme elle est moins abstraite, elle vous offre plus de flexibilité, mais nécessite également de plus grandes compétences d’administration système de votre part.

C’est un sujet assez ancien, avec des réponses plutôt anciennes, alors j’ai pensé qu’une réponse plus récente pourrait aider certaines personnes.

J’ai beaucoup d’expérience dans l’utilisation de Heroku et de Engine Yard pour certains services Web assez volumineux et complexes. Ma société 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 plate-forme a ses propres capacités uniques.

Votre question est un peu difficile à répondre simplement parce que la plupart des critères qui vous intéressent ne sont pas les caractéristiques différenciantes de chaque plate-forme. Je répondrai de toute façon à ces points, mais je parlerai également de la philosophie générale de chaque plate-forme et des différences de support technique que je pense être plus utiles dans votre décision.

La sécurité, la stabilité et l’évolutivité sont un lavage. Les deux services sont aussi sécurisés et stables que toute instance Amazon EC2. L’évolutivité est également réaliste. Alors que Heroku vous limite à quelques centaines de petites instances (512k) (ou maintenant des “doubles” petites), Engine Yard vous permettra d’utiliser Extra Large avec des tonnes de CPU et de mémoire, mais dans le monde réel fin. Avec Heroku, vous pourriez avoir besoin de lancer un petit nombre de petits serveurs peu coûteux pour gérer votre charge, ou bien, avec Engine Yard, vous utiliseriez une poignée de gros serveurs plus chers. Pour les demandes Web, peu importe.

Le prix est un facteur que je peux aborder un peu mieux. Tout d’abord, si vous ne faites que bricoler, Heroku est gratuit. Ne confondez pas cela avec le sens que vous pourriez vraiment exécuter un vrai site Web sur leur niveau gratuit. Vous ne pouvez pas Engine Yard vous permet de passer des heures libres à jouer, mais parlons d’applications réelles. Heroku simplifie la tarification en vous facturant des «dynos» (ces petits serveurs Web que j’ai mentionnés) et un plan de firebase database PostgreSQL. Leurs prix incluent le stockage, la sauvegarde, la bande passante, etc. Il est donc très facile de calculer ce qui coûte. Engine Yard fait la différence et vous devrez utiliser sa calculasortingce pour déterminer les coûts – mais tout est fait pour vous avant de décider de lancer une nouvelle «instance».

Je trouve que les plans de firebase database d’Heroku sont très coûteux (comparés aux coûts de l’instance EC2). Ils font définitivement leur profit ici. Ce qui semblait bon marché pour les dynos a maintenant besoin d’une firebase database de 200 $ à 400 $ / mois (pour commencer à atteindre le niveau de performance raisonnable, vous pourriez avoir plus de 800 $). Je déteste également la manière dont ils cachent / masquent les spécifications de la firebase database – vous devrez déduire les capacités en allant sur les données de taille d’instance d’Amazon et en examinant la «mémoire» utilisée par Heroku pour le «cache».

La firebase database de Engine Yard est simplement une instance de serveur quelconque. Ils utilisent le même balisage 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 embrouiller votre décision.

En fin de compte, j’aime bien 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 packages Unix, SSH, etc. D’autre part, Herkou fonctionne très bien dans des situations où vous pouvez extraire votre application du matériel et entrer dans cet essaim de dynos. Il est très facile et rapide de lancer des dizaines de minutes en quelques minutes. Comme je l’ai mentionné, nous exécutons AirBop sur la plate-forme Heroku et nous avons automatisé la création / destruction de notre instance avec HireFire – ce qui fonctionne très bien pour nous car notre charge varie considérablement et de manière inattendue.

Une autre chose à considérer est le support technique. D’après mon expérience, le support gratuit / inclus de Heroku est presque inutile, alors que Engine Yard est très bon. EY avait l’habitude de facturer le support de base, mais a commencé avec tous ses plans (en plus, une option prioritaire 24/7 est disponible). J’ai trouvé qu’ils savent vraiment de quoi ils parlent aussi.

J’espère que ça aide!

J’ai vérifié Bitnami, Heroku et Engine Yard et effectué des tests sérieux contre Heroku et Engine Yard et Engine Yard était de loin le gagnant. Heroku fait des trucs vraiment bizarres, comme la limitation des processus à 250 Mo et leur réponse est que vous devez gérer votre propre mémoire. Je voyais des pics de performance sur heroku et il semble parfois que les processus se bloquent et ne redémarrent pas pendant une minute avec plusieurs dynos Web en cours d’exécution (ce qui n’est pas censé se produire). utilisé et il y a un problème de démarrage étrange même avec plusieurs dynos. Plus l’inconvénient que je n’ai pas pu obtenir dans les 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 pics de performance, je dois dire que Engine Yard est de loin le meilleur 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 à append des dynos Web et que les performances sont bien meilleures, surtout si vous passez à la stack JRuby. J’ai essayé d’installer quelque chose sur Bitnami, mais d’après ce dont je me souviens, c’était difficile à travailler. Je pense que Heroku est une bonne solution si vous n’êtes pas préoccupé par les performances ou l’évolutivité et que vous souhaitez simplement déployer une application Web simple, il est probablement plus facile à utiliser que Engine Yard pour ce genre de choses.

J’exécute des applications Rails et Sinatra critiques sur les applications Heroku et Engine Yard et PHP sur le moteur Engine Yard Cloud, et mon commentaire concerne la stabilité. Engine Yard gagne, main dans la main. La raison en est le personnel de soutien. Si votre application doit absolument fonctionner et que vous avez besoin d’aide pour y parvenir, alors Engine Yard est là pour vous aider, surtout si vous investissez dans le support Premium. Ils sont absolument fantastiques. Heroku est chouette quand ça marche, mais quand ça ne marche pas, le personnel de soutien est loin d’être aussi utile.

Voici un exemple d’il ya quelques mois, lorsque j’avais besoin de déployer une application interne critique quelques jours après avoir reçu la demande d’application de mon personnel:

Délais intermittents à partir d’une application qui ne doit jamais expirer (PAS une erreur “R12 Request Timeout”)

J’ai beaucoup d’applications fonctionnant sur Heroku, et aucun d’entre eux n’a jamais eu le mystérieux problème d’opération Web que j’avais avec cette application. Juste pour vous assurer que je sais ce que je fais et que ce n’était pas une erreur de développeur. Cela est d’autant plus rassurant que le même code fonctionne parfaitement depuis que je l’ai transféré dans Engine Yard alors que je ne pouvais pas obtenir l’aide de Heroku. Ils ont finalement répondu quelques jours après le lancement de l’application, me disant que je pouvais résoudre les problèmes de performances de mon application avec NewRelic. Grand merci.

La façon dont je vois les choses, payer pour un support premium de Engine Yard coûte BEAUCOUP moins cher que d’engager des responsables des opérations Web. Et je reçois un soutien extrêmement compétent, provenant d’un réseau de personnes qui ont toujours des experts à consulter quand ils ne le savent pas. Je le répète: le personnel d’appui de Engine Yard est incroyablement fantastique.

Je suppose que je peux commenter un peu la sécurité, car à un moment donné, notre application SaaS a été touchée par une attaque DDoS. Peut-être que ce n’est pas vraiment la question, mais je m’en sers comme une excuse pour parler à nouveau du personnel de soutien. Je n’avais jamais été touché par une attaque DDoS et je ne savais même pas pourquoi mes serveurs fonctionnaient mal. Ils l’ont diagnostiqué et m’ont aidé à prendre des mesures d’atténuation. Ils m’ont aidé à mettre en place des filtres ad hoc dans HAProxy et nginx pour bloquer l’attaque pendant un certain temps, ce qui m’a donné suffisamment de temps pour mettre en place une atténuation DDoS.

… alors il y a le temps où tout le centre de données Amazon US-East-1 a implosé et que certains sites ont été déconnectés pendant des jours . Engine Yard à l’époque ne proposait que l’hébergement dans ce centre de données. En quelques minutes, ils avaient activé l’option de déploiement sur US-West-1 et aidaient tous leurs clients concernés à se déplacer. Sans leur aide, nous n’aurions pas couru à temps pour notre prime time ce soir-là (nous sums un SaaS pour les boîtes de nuit) et nous aurions probablement perdu beaucoup de clients car c’était un jeudi soir. Grande soirée pour nous. Beaucoup de gens qui utilisaient des applications sur Heroku ce jour-là n’étaient que SOL, mais nous étions immédiatement opérationnels en Californie grâce à l’aide de Engine Yard.

Il y a eu d’autres moments où ils ont sauvé notre société de certains malheurs. Sans blague. Je pourrais continuer à raconter des histoires. Mais vous avez l’idée. L’équipe de support de Engine Yard est la raison pour laquelle je déploie toutes les nouvelles applications critiques sur Engine Yard Cloud.