Heroku vs EngineYard: lequel vaut le plus?
J'ai recherché cela sur Google, mais je voulais plus d'opinions avant de m'engager dans l'un ou l'autre service. Quelqu'un a-t-il de l'expérience avec l'un des services (ou les deux)? Y a-t-il des avantages ou des inconvénients qui se sont démarqués dans l'un ou l'autre? Les domaines d'intérêt particuliers sont:
- Sécurité
- Stabilité
- Évolutivité.
- Prix
Je suppose que vous parlez de l'hébergement EC2 de Engine Yard, plutôt que de leur pile de services complets?
Je travaille avec Heroku et j'adore ça. Sur le prix, Heroku est clairement le gagnant pour moi. Les coûts de bande passante sont extraits par 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 du cloud. Vous n'avez pas beaucoup d'informations sur la pile 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 a démarré. Des trucs merveilleux.
En ce qui concerne l'évolutivité, les deux sont soutenus sur Amazon et exploitent EC2 et l'EBS, donc probablement la même chose en termes de capacité brute.
Froussard,
J'avais l'habitude de travailler pour Engine Yard, alors laissez-moi vous donner les informations sur notre service Engine Yard Cloud (fonctionnant sur AWS). Je vous laisse faire vos propres recherches sur vos autres options.
- Sécurité Chaque compte Engine Yard Cloud est son propre compte complet d'Amazon dans les coulisses, ce qui signifie que vous obtenez des machines virtuelles entièrement renforcées par le matériel qui vous sont dédiées pour exécuter votre application. Ainsi, les attaquants exploitant un débordement de tampon de jour zéro, etc. dans les Gemmes C, Ruby, Passenger, Linux, etc. des gens n'ont accès 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 pile et vous obtenez automatiquement de nouveaux correctifs lorsque vous redéployez. Vous obtenez un accès SSH complet à vos instances et obtenez 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 ne s'est produit avant la maturité des machines virtuelles (mais je suis biaisé parce que j'étais un gars VMware, et j'ai vu cela se produire en temps réel )
Stabilité Nous avons beaucoup d'expérience avec ce qui peut être fiable et ce qui ne peut pas l'être dans les composants Ruby/Rails. Actuellement sur notre liste "ne pas déployer" sont furet, mastodonte et awstats. Sinon, nous héritons de la disponibilité d'AWS car nous n'avons pas d'infrastructure partagée dans le chemin de 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 l'instant. La fiabilité du déploiement a été mitigée récemment - Amazon semble être un peu plus proche du vent sur l'utilisation de la capacité, donc à certaines occasions, une demande d'ajout de capacité échouera et devra être émise à nouveau.
Évolutivité. Nous avons de grandes applications fonctionnant sur le cloud Engine Yard. Playmesh avait l'application iphone numéro 1 en novembre dernier et augmentait sa capacité à bien la gérer. Nous avons comparé même une petite instance (4 mongrels) capable de gérer 85M/Reqs par mois à charge constante (application très simple). Nous recommandons que les utilisateurs s'exécutent sur des instances plus grandes s'ils souhaitent beaucoup d'E/S disque, Amazon offre un meilleur débit d'E/S pour 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.
Prix L'exécution d'une petite instance (4 mongrels) à temps plein 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 une petite somme pour le stockage et la bande passante - que Engine Yard Cloud transmet au coût AWS. Nous sommes assez confiants qu'une fois que vous atteignez une quantité raisonnable de trafic, nous sommes un tueur à gages.
Permettez-moi d'ajouter quelques autres critères que vous voudrez peut-être considérer ...
Support -> vous bénéficiez d'un support communautaire/forum gratuit, mais nous avons également une option de support payante, l'option de support premium permet de surveiller votre application 24h/24 et 7j/7 et nous vous avertirons lorsque votre application tombera en panne et la dépannerons pour vous si elle est prise en charge pile c'est un problème.
Communauté -> Certaines personnes s'en soucient, d'autres non, mais Engine Yard sponsorise 2 contributeurs à plein temps Rails, une équipe JRuby de trois personnes et la prochaine génération Ruby VM, 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 la voir en action, mais c'est bien. Nous sommes é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 PaaS Ruby, similaire au moteur d'application Google. Elle vous permet de faire évoluer une application sans aucune compétence d'administration système, tant que votre application s'intègre dans l'écosystème qu'elles fournissent.
Engine Yard est un service plus traditionnel, vous donnant accès à des box et vous fournissant des outils pour vous faciliter la vie. Comme il s'agit moins d'une abstraction, il vous offre plus de flexibilité, mais nécessite également de plus grandes compétences d'administrateur système de votre part.
C'est un fil assez ancien, avec des réponses assez anciennes, donc j'ai pensé qu'une réponse plus à jour pourrait aider certaines personnes.
J'ai un peu d'expérience en utilisant à la fois Heroku et Engine Yard pour certains services Web plutôt grands 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 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 à ces points de toute façon, mais je vais également aborder la philosophie générale de chaque plate-forme et les différences de support technique qui, je pense, sont 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 n'importe quelle instance Amazon EC2. L'évolutivité est également réaliste. Alors que Heroku vous limite à quelques centaines de petites (512k) instances (ou maintenant des "petites" petites), Engine Yard vous permettra 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 dans le fin. Avec Heroku, vous devrez peut-être générer un essaim de petits serveurs bon marché pour gérer votre charge, ou avec Engine Yard, vous utiliseriez une poignée de serveurs plus gros et plus chers. Pour les demandes 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 bricolez, Heroku est gratuit. Ne confondez pas cela avec le sens que vous pourriez vraiment exécuter un vrai site Web sur leur niveau gratuit. Tu ne peux pas. Engine Yard vous offre également une multitude d'heures gratuites pour jouer, mais parlons des applications du monde réel. Heroku adoucit les prix, vous facturant des "dynos" (les petits serveurs Web que j'ai mentionnés) 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 les choses coûtent. Engine Yard sépare les choses et vous devrez utiliser leur calculatrice pour déterminer ce que cela coûtera - mais tout est présenté pour vous avant de décider 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 constituent certainement leur profit ici. Ce qui semblait bon marché pour dynos a maintenant besoin d'une base de données de 200 $ à 400 $/mois (pour commencer à atteindre le niveau de performance raisonnable, vous pouvez regarder plus comme 800 $ et plus). Je déteste également la façon dont ils masquent/masquent les spécifications de la base de données - vous devrez en déduire les capacités en accédant aux données de taille d'instance d'Amazon et en examinant la `` mémoire '' que Heroku utilise pour le `` cache ''.
La base de données de Engine Yard est simplement l'instance de serveur que vous souhaitez qu'elle soit. Ils clouent sur le même balisage EC2 que pour les instances Web. Aucun gougeage 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.
Au final, 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, packages Unix, SSH, etc. D'un autre côté, Herkou fonctionne très bien dans les situations où vous pouvez faire abstraction de votre application du matériel et entrer dans cet essaim de dynos. Ils permettent de lancer très rapidement et facilement des dizaines en quelques minutes. Comme je l'ai mentionné, nous exécuter AirBop sur la plate-forme Heroku et automatiser la création/destruction d'instances 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 facturait le support de base, mais a commencé à l'inclure dans tous ses plans (en plus, une option prioritaire 24/7 est disponible). J'ai constaté qu'ils savent vraiment de quoi ils parlent également.
J'espère que cela aide!
J'ai vérifié Bitnami, Heroku et Engine Yard et j'ai effectué des tests sérieux contre heroku et Engine Yard et Engine Yard était de loin le gagnant. Heroku fait des trucs vraiment étranges comme plafonner les processus à 250 Mo et leur réponse est que vous devez gérer votre propre mémoire. Je voyais de graves pics de performances sur Heroku et il semble que parfois 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.) De plus, Heroku met les processus en veille s'ils ne sont pas en cours. utilisé et il y a un problème de démarrage étrange même avec plusieurs dynos. De plus, l'inconvénient supplémentaire que je n'ai pas pu 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 le regarder crier sans pics de performance géniaux, je dois dire que 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 meilleures, surtout si vous passez à la pile JRuby. J'ai essayé de créer quelque chose sur Bitnami mais d'après ce dont je me souviens, c'était assez 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 chose.
Je lance des applications critiques Rails et Sinatra sur Heroku et Engine Yard et PHP apps sur Engine Yard Cloud, et mon commentaire porte sur # 2, stabilité. Engine Yard gagne, haut la main. La raison en est le personnel de support. Si votre application doit absolument fonctionner et que vous avez besoin d'aide pour la faire fonctionner, alors Engine Yard est là pour vous aider, surtout si vous investissez dans un support premium. absolument fantastique Heroku est bien quand il fonctionne, mais quand cela ne fonctionne pas, leur personnel de soutien est loin d'être aussi utile.
Voici un exemple d'il y a quelques mois où j'avais besoin de déployer une application interne critique dans les deux jours suivant la demande de l'application par mon personnel:
J'ai beaucoup d'applications exécutées sur Heroku, et aucune d'entre elles n'a jamais eu le mystérieux problème d'opérations 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. Une autre garantie de cela est que le même code fonctionne parfaitement depuis que je l'ai déplacé vers Engine Yard alors que je ne pouvais pas obtenir d'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 dans mon application avec NewRelic. Grand merci.
La façon dont je le vois, payer pour le support premium de Engine Yard coûte BEAUCOUP moins que d'embaucher du personnel d'exploitation Web. Et je reçois un soutien extrêmement compétent, d'un réseau de personnes qui ont toujours des experts à consulter quand ils ne savent pas. Permettez-moi de répéter: le personnel de soutien 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'était pas vraiment la question, mais je l'utilise comme une excuse pour parler à nouveau du personnel de soutien. Je n'avais jamais été frappé par une attaque DDoS, et je ne savais même pas pourquoi mes serveurs fonctionnaient mal. Ils l'ont diagnostiqué et m'ont aidé à commencer l'atténuation. Ils m'ont aidé à mettre en place certains filtres ad-hoc dans HAProxy et nginx pour bloquer l'attaque pendant un certain temps, et cela m'a permis de disposer de suffisamment de temps pour configurer l'atténuation DDoS.
... puis il y a le temps où l'ensemble du centre de données Amazon US-East-1 a implosé et certains sites se sont déconnectés pendant jours . Engine Yard à l'époque ne proposait qu'un 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 heure de grande écoute ce soir-là (nous sommes un SaaS pour les boîtes de nuit) et nous aurions probablement perdu beaucoup de clients parce que c'était un jeudi soir. Grande soirée pour nous. Beaucoup de gens qui exécutaient des applications sur Heroku ce jour-là n'étaient que SOL, mais nous étions prêts à fonctionner en Californie grâce à l'aide de Engine Yard.
Il y a eu d'autres moments où ils ont sauvé notre entreprise de certains Doom. Sans blague. Je pourrais continuer à raconter des histoires. Mais vous avez l'idée. Le personnel de support de Engine Yard est la raison pour laquelle je déploie toutes les nouvelles applications stratégiques sur Engine Yard Cloud.