web-dev-qa-db-ja.com

Heroku対EngineYard:どちらがお金の価値がありますか?

私はこれをGoogleで調べましたが、どちらのサービスにも取り組む前に、もっと意見を求めていました。誰かがどちらか(または両方)のサービスを経験したことがありますか?どちらかについて際立っていた利点または欠点はありますか?関心のある特定の領域は次のとおりです。

  1. 安全保障
  2. 安定
  3. スケーラビリティ。
  4. 価格
56
funkymunky

Engine Yardのフルサービススタックではなく、EC2ホスティングについて話していると思いますか?

私はHerokuと一緒に作業していて、大好きです。価格的には、Herokuが私にとって明らかな勝者です。帯域幅のコストはHerokuによって抽象化され、これは大きな勝利です。

セキュリティの面では、クラウドの一般的な批評の1つであるとは言いがたいです。どちらのサービスで実行されているスタックについても、十分な洞察がありません。

Herokuは、アプリケーションインスタンスを監視してシームレスに管理するためのテクノロジーに多大な投資を行ってきました。問題が発生し、インスタンスが削除され、新しいインスタンスが開始されました。素晴らしいもの。

スケーラビリティに関しては、どちらもAmazonにバックアップされており、EC2とEBSを活用しているため、生の容量に関してはおそらく同じです。

32
Toby Hede

ファンキー、

Engine Yardで働いていたので、Engine Yard Cloudサービス(AWSで実行中)について説明します。私はあなたに他の選択肢についてあなた自身の研究を任せます。

  1. セキュリティ各Engine Yard Cloudアカウントは、舞台裏で独自の完全なAmazonアカウントです。つまり、アプリケーションを実行するための専用のハードウェア強制仮想マシンを手に入れることができます。したがって、人々のC Gems、Ruby、パッセンジャー、Linuxなどでゼロデイバッファーオーバーフローなどを悪用する攻撃者は、単一のアカウントにしかアクセスできません。データパスに共有インフラストラクチャはありません。スタックのすべての要素のセキュリティ脆弱性レポートを監視し、再デプロイすると自動的に新しいパッチを取得します。インスタンスへの完全なSSHアクセスを取得し、SolrやSphinxなどのパッケージやイメージ操作などのパッケージをインストールする必要がある場合の通常のサーバー環境を取得します。

私の考えでは、ハードウェアレベルの仮想マシンはAmazonの成功の基礎の1つであり、仮想マシンが成熟する前にこのようなものが実現しなかった理由です(ただし、私は以前はVMwareの人だったため、これがリアルタイムで発生するのを見て偏見があります)

  1. 安定性私たちは、Ruby/Railsコンポーネントで信頼できるものとできないものについて多くの経験を持っています。現在、「展開しない」リストには、フェレット、ジャガーノート、awstatsがあります。それ以外の場合は、データパスに共有インフラストラクチャがないため、AWSアップタイムを継承します。 AWSの稼働時間はかなり良かったのですが、それで原子力発電所を稼働させることはまだしません。デプロイの信頼性は最近さまざまです。Amazonは容量使用率に少し近づいているようです。そのため、場合によっては容量追加リクエストが失敗し、再発行する必要があります。

  2. スケーラビリティ。 Engine Yardクラウドで実行されているいくつかの大きなアプリケーションがあります。 Playmeshは昨年11月にiphoneアプリで第1位を獲得し、それをうまく処理するために容量を増やしました。一定の負荷(非常にシンプルなアプリ)で1か月あたり85M/Reqを処理できる小さなインスタンス(4モルグレル)でもベンチマークしました。大量のディスクI/Oが必要な場合は、より大きなインスタンスで実行することをお勧めします。Amazonは、より大きなインスタンスサイズに優れたI/Oスループットを提供します。いずれにしても、容量の追加または削除は、文字通りボタンをクリックするだけです。

  3. 価格1か月間フルインスタンスで小さなインスタンス(4モングリル)を実行すると、EYクラウドでは$ 79、1時間あたり0.11ドル(裸のAmazonでは8.5セント)になります。これにはデータベース管理が含まれますが、ストレージと帯域幅には少額の費用がかかります-Engine Yard CloudはこれをAWSのコストで渡します。妥当な量のトラフィックに到達したら、私たちはきっと素晴らしい取引になると確信しています。

あなたが考慮したいかもしれない他のいくつかの基準を追加しましょう...

  1. サポート->コミュニティ/フォーラムのサポートを無料でご利用いただけますが、チケット付きのサポートオプションもあります。プレミアムサポートオプションでは、アプリが24時間365日監視され、アプリがダウンしたときに通知され、サポートされている場合はトラブルシューティングを行いますスタックは問題です。

  2. コミュニティ->これを気にかける人もいれば、気にかけない人もいますが、Engine Yardは2人のフルタイムRails貢献者、3人のJRubyチーム、次世代のRuby VM、Rubiniusをスポンサーしています。私たちは、RailsおよびRubyがWebアプリケーションを開発するための最良のプラットフォームとなるよう支援することをお約束します。

  3. 自動化->デモを見て動作を確認する必要がありますが、見事です。また、コマンドラインでgitをデプロイしているベータ版です。ナレッジベースをチェックして、実際の動作を確認してください。

66
Michael Mullany

それらは完全に異なるアプローチです。

HerokuはRuby PaaSソリューションで、google app engineに似ています。アプリケーションが提供するエコシステムに適合している限り、システム管理スキルがなくてもアプリケーションをスケーリングできます。

Engine Yardは、従来のサービスであり、ボックスへのアクセスを提供し、生活を楽にするツールを提供します。抽象化されていないため、柔軟性が向上しますが、システム管理者のスキルも必要になります。

27
Paul McMahon

これはかなり古いスレッドで、かなり古い応答なので、より最新の応答が一部の人々を助けるかもしれないと思いました。

HerokuとEngine Yardの両方をかなり大規模で複雑なWebサービスに使用した経験はかなりあります。私の会社では、Android)でAndromo App Makerを実行するためにEngine Yardを使用し、AndroidでAirBop Push Messaging Serviceを実行するためにHerokuを使用しています。各プラットフォームには独自の機能があります。

関心のある基準のほとんどが各プラットフォームの差別化機能ではないため、質問に答えるのは少し難しいです。とにかく、これらの点についてお答えしますが、各プラットフォームの一般的な哲学と、テクニカルサポートの違いについても触れておきます。

セキュリティ、安定性、およびスケーラビリティは洗浄です。どちらのサービスも、Amazon EC2インスタンスと同様に安全で安定しています。スケーラビリティも現実的には同じです。 Herokuでは数百の小さな(512k)インスタンス(または「ダブル」スモール)に制限されていますが、Engine Yardでは大量のCPUとメモリを備えたエクストララージを使用できますが、実際にはほぼ同じです。終わり。 Herokuを使用すると、負荷を処理するために安価な小さなサーバーの群れを生成する必要がある場合があります。または、Engine Yardを使用すると、より高価な大規模サーバーをいくつか使用します。 Webリクエストの場合、それはおそらくそれほど重要ではありません。

価格は私がもう少しよく対処できる要因です。まず、いじくり回しているだけなら、Herokuは無料です。それを、実際のウェブサイトを無料枠で実際に実行できるという意味と混同しないでください。できません。 Engine Yardは、いじくり回すための無料の時間を提供しますが、実際のアプリケーションについて話しましょう。 Herokuは、価格設定をスムーズにし、「dynos」(私が述べた小さなWebサーバー)とPostgreSQLデータベースプランの料金を請求します。それらの価格には、ストレージ、バックアップ、帯域幅などが含まれているので、物事のコストを暗に計算することは非常に簡単です。 Engine Yardは物事を分解し、それらの計算機を使用して、物事にかかる費用を把握する必要がありますが、新しい「インスタンス」を起動することを決定する前に、すべてが提示されます。

Herokuのデータベースプランは非常に高価です(使用しているEC2インスタンスと比べて)。彼らは間違いなくここで彼らの利益を補います。 dynoにとって安っぽく見えたものは、今では月額$ 200〜$ 400のデータベースが必要です(合理的なパフォーマンスのレベルに到達するには、$ 800以上のように見えるかもしれません)。また、データベースの仕様を非表示/光沢にする方法も嫌いです。Amazonのインスタンスサイズデータに移動し、Herokuが「キャッシュ」に使用している「メモリ」を確認して、機能を推測する必要があります。

Engine Yardのデータベースは、希望するサーバーインスタンスです。 Webインスタンスの場合と同じEC2マークアップを使用します。ここではガウジしない。より透明です。

1つは他よりも安いですか。多分、私はあなたの決定を数ドル汚すことはできません。

結局のところ、私は「ベアメタル」コントロールでEngine Yardが好きです。 Andromoには、Androidアプリをその場で生成し、非常に具体的な要件があるため、これが必要です。EngineYardを使用すると、各サーバー、Unixパッケージ、SSHなどを完全に制御できます。一方、Herkouは、ハードウェアからアプリケーションを抽象化して、dynosの思考の集団に入ることができる状況で非常にうまく機能します。数分で数十を非常に高速かつ簡単に起動できます。前述したように、 HerokuのプラットフォームでAirBopを実行し、HireFireを使用してインスタンスの作成/破棄を自動化しました。これは、負荷が大幅に予期せず変動するため、非常にうまく機能します。

考慮すべきもう1つのことは、テクニカルサポートです。私の経験では、Herokuの無料/組み込みサポートはほとんど役に立たないのに対し、Engine Yardは非常に優れています。 EYは以前は基本的なサポートの料金を請求していましたが、すべてのプランに含まれています(さらに、24時間年中無休の優先オプションが利用可能です)。彼らは彼らが何について話しているかも本当に知っていることがわかりました。

うまくいけば、それが役立ちます!

7
Colin Adams

私はBitnami、Heroku、およびEngine Yardをチェックアウトし、herokuおよびEngine Yardに対していくつかの深刻なテストを実行しましたが、Engine Yardが圧倒的に勝っていました。 Herokuは、プロセスを250 MBに制限するなど、非常に奇妙なことをいくつか行っています。その答えは、自分のメモリを管理する必要があるということです。 herokuのパフォーマンスに深刻なスパイクが見られました。複数のWeb dynoが実行されていると、プロセスがハングして1分間ほど再起動しない場合があります(これは発生するはずではありません)。使用され、複数のdynoがある場合でも、奇妙な起動の問題があります。さらに、herokuのログファイルにアクセスできず、何が起こっているのかを理解できなかったという追加の不便さもあります。まったく同じコードをEngine Yardにデプロイし、パフォーマンスのファンキーなスパイクなしでそれが悲鳴を上げるのを見たとき、私はEngine Yardが圧倒的に勝っており、システムのセットアップを取得したらデプロイするのが最も簡単だと言わざるを得ません。 Web dynoの追加を開始すると、エンジンヤードの方がherokuよりも実際にコストが安くなり、パフォーマンスは特にJRubyスタックに切り替えた場合の方がはるかに優れています。 Bitnamiで何かをセットアップしようとしましたが、覚えている限りでは、操作するのが少し難しいようでした。パフォーマンスやスケーラビリティを気にせず、単純なWebアプリを展開したいだけの場合、herokuは優れたソリューションだと思います。そのようなことには、Engine Yardよりもおそらく使いやすいでしょう。

5
Adam Freeman

私はミッションクリティカルRailsおよびSinatraアプリをHerokuとEngine Yardの両方で実行し、PHPアプリをEngine Yard Cloudで実行しています。私のコメントは#2についてですが、安定性。EngineYardが勝利を収めます。理由はサポートスタッフにあります。アプリが完全に機能する必要があり、それを実現するために支援が必要な場合、特にプレミアムサポートに投資する場合、Engine Yardが役立ちます。 Herokuは機能するときはきちんと機能しますが、機能しないときは、サポートスタッフがそれほど役に立ちません。

スタッフからアプリのリクエストを受け取ってから数日以内にミッションクリティカルな内部アプリをデプロイする必要があった数か月前の例を次に示します。

タイムアウトしてはならないアプリからの断続的なタイムアウト(「R12リクエストタイムアウト」エラーではない)

Herokuで実行しているアプリはたくさんありますが、それらのアプリで私が抱えていた不思議なWeb操作の問題を経験したことはありません。私がやっていることを知っていることと、開発者のエラーではなかったことを保証するために。さらに安心できるのは、Herokuの助けが得られなかったときにEngine Yardに移動してから、まったく同じコードが完全に実行されていることです。アプリの起動が必要になった数日後にようやく応答し、NewRelicを使用してアプリのパフォーマンスの問題をトラブルシューティングできると告げました。まことにありがとうございます。

私の見方では、Engine Yardのプレミアムサポートに支払う費用は、Web運用担当者を雇うよりも大幅に低くなります。そして、私は、専門家が常に知らないときに相談する専門家を持っている人々のネットワークから、非常に有能なサポートを得ています。繰り返しますが、Engine Yardのサポートスタッフは信じられないほど素晴らしいです。

ある時点でSaaSアプリがDDoS攻撃に見舞われたため、セキュリティについて少しコメントできると思います。たぶんそれは問題が真実ではないかもしれませんが、私はそれを次のように使用していますサポートスタッフについて再度話す口実。私はDDoS攻撃に遭遇したことがなく、サーバーが誤動作している理由すら知りませんでした。彼らはそれを診断し、緩和策を開始するのに役立ちました。 HAProxyとnginxのいくつかのアドホックフィルターがしばらくの間攻撃をブロックし、DDoS緩和策をセットアップするのに十分な時間がかかりました。

...そして、Amazon US-East-1データセンター全体が爆破し、一部のサイトが日間オフラインになったときがあります。当時のEngine Yardは、そのデータセンターでのホスティングのみを提供していました。彼らは数分以内にUS-West-1への展開オプションを有効にし、影響を受けるすべての顧客の移動を支援しました。彼らの助けがなければ、私たちはその夜のプライムタイムに間に合わなかったでしょう(私たちはSaaSです))。木曜日の夜、私たちにとっては大きな夜です。その日にHerokuでアプリを実行していた多くの人々はSOLでしたが、Engine Yardのおかげでカリフォルニアですぐに稼働していました。

彼らが私たちの会社を特定の運命から救った時が他にもありました。冗談抜き。私は物語を語り続けることができました。しかし、あなたはアイデアを得ます。 Engine Yardのサポートスタッフが、新しいミッションクリティカルなすべてのアプリをEngine Yard Cloudに展開する理由です。

2
Ryan Porter