web-dev-qa-db-ja.com

AWSが存在するときになぜ人々はHerokuを使用するのですか? HerokuとAWSの違いは何ですか?

私はHerokuを使って私のアプリをデプロイすることを計画している初心者のRoRプログラマーです。私の他のアドバイザーの友人からの言葉は、Herokuは本当に簡単で使いやすいと言っています。唯一の問題は、Herokuが何をするのか私にはまだわからないということです...

私は彼らの ウェブサイト そして一言で言えば、Herokuがスケー​​リングを手助けすることは何をしているのでしょうか。 Herokuはどのように役立ちますか。

  1. スピード - 私が調査したところによると、米国/アジアを拠点とするユーザーをターゲットにしている場合は、米国東海岸にAWSを展開するのが最速です。

  2. セキュリティ - それらはどれくらい安全ですか?

  3. スケーリング - 実際にはどのように機能しますか?

  4. 費用対効果 - 拡張が容易なdynoのようなものがあります。

  5. 彼らはどのように彼らの競争相手に対抗しますか?例えば、 Engine Yard および bluebox ?のようになります。

説明するために素人の英語の用語を使用してください...私は初心者プログラマです。

1045
Bryan

AWS/Herokuは、どちらも小規模な趣味のプロジェクトでは無料です(まず始めに)。

アーキテクチャをあまりカスタマイズせずにすぐにアプリを起動したい場合は、 Heroku を選択します。

アーキテクチャーに集中し、異なるWebサーバーを使用できるようにしたい場合は、 _ aws _ を選択してください。 AWSは選択したサービス/製品に基づいて時間がかかりますが、それだけの価値があります。 AWSには多くのプラグインサービスと製品も付属しています。


ヘロク

  • サービスとしてのプラットフォーム(PAAS)
  • 良い文書
  • 組み込みのツールとアーキテクチャがあります。
  • アプリを設計しながらアーキテクチャ上の制限された制御。
  • 配置は大事にされます(GitHubによる自動またはgitコマンドまたはCLIによる手動)。
  • 時間がかかりません。

_ aws _

  • サービスとしてのインフラ(IAAS)
  • 多用途 - EC2、LAMBDA、EMRなどの多くの製品があります。
  • OS、ソフトウェアのバージョンなどを選択するなど、アーキテクチャをより細かく制御するために専用インスタンスを使用できます。バックエンドレイヤは複数あります。
  • Elastic Beanstalkは、HerokuのPAASに似た機能です。
  • 自動展開を使用することも、独自に展開することもできます。
190
SuperNova

まず最初に、AWSとHerokuは異なるものです。 AWSは、Infrastructure as a Service( IaaS )を提供しますが、HerokuはPlatform as a Service( PaaS )を提供します。

違いは何ですか?おおよそ、IaaSは、その上に物を構築するために必要なコンポーネントを提供します。 PaaSは、コードといくつかの基本的な構成をプッシュし、実行中のアプリケーションを取得するだけの環境を提供します。 IaaSを使用すると、より多くのパワーと柔軟性を提供できますが、より多くのビルドとメンテナンスが必要になります。

AWSでコードを実行し、Herokuデプロイのように見えるようにするには、いくつかのEC2インスタンスが必要です-ロードバランサー/キャッシングレイヤーをインストールする必要があります(例 Varnish )、 Passenger および nginx のようなものを実行するインスタンスがコードを提供するようにしたい場合は、クラスター化されたデータベースインスタンスをデプロイおよび構成します PostgreSQL のようなもの。 Capistrano のようなデプロイメントシステムと、ログ集約を行うものが必要になります。

これは、セットアップして維持するのに取るに足らない量の作業ではありません。 Herokuでは、そのような段階に到達するために必要な作業は、アプリケーションコードの数行とgit Pushである可能性があります。

だからあなたはこれまでのところ、あなたはスケールアップしたい。すばらしいです。 EC2デプロイメントに Puppet を使用していますよね?そこで、必要に応じてインスタンスをスピンアップ/スピンダウンするようにCapistranoファイルを構成します。 Puppetの設定を変更して、VarnishがWebワーカーインスタンスを認識し、それらの間で自動的にプールされるようにします。または、heroku scale web:+5

うまくいけば、2つの比較を理解できると思います。次に、特定のポイントに対処します。

速度

現在、Herokuはus-eastおよびeu-westのAWSインスタンスでのみ実行されます。あなたにとって、これはとにかく欲しいもののように聞こえます。他の人にとっては、潜在的にもっと考慮すべきことです。

セキュリティ

私は、セキュリティの更新が遅れているか、または一般的に不十分にまとめられている多くの内部的に維持された運用サーバーを見てきました。 Herokuを使用すると、他の誰かがそのようなことを管理します。これは、見方によっては祝福または呪いです。

デプロイすると、コードを効果的にHerokuに直接渡すことになります。これはあなたにとって問題かもしれません。 Dyno Isolation に関する彼らの記事では、それらの分離技術について詳しく説明しています(複数のdynoが個々のEC2インスタンスで実行されているようです)。数人の同僚がこれらの技術とその分離の強さに関する問題を表明しています。残念ながら、実際にコメントするのに十分な知識/経験があるわけではありませんが、現在のHerokuの展開では「十分に良い」と考えています。それはあなたにとって問題かもしれません、私は知りません。

スケーリング

上記のIaaSとPaaSの比較でこれを実装する方法について触れました。おおよそ、アプリケーションにはProcfileがあり、これにはdyno_type: command_to_runという形式の行があります。たとえば( http://devcenter.heroku.com/articles/process-modelから引用) ):

web:    bundle exec Rails server
worker: bundle exec rake jobs:work

これで、:

heroku scale web:2 worker:10

2つのweb dynoと10のworker dynoが実行されます。ニース、シンプル、簡単。 webは特別なdynoタイプであり、外部にアクセスでき、それに応じてトラフィックをルーティングするNice Web Traffic Multiplexer(おそらくある種のVarnishとnginxの組み合わせ)の背後にあります。おそらく、ワーカーは同様のルーティングのためにメッセージキューと対話し、そこから環境内のURLを介して場所を取得します。

コスト効率

多くの人々がこれについて多くの異なる意見を持っています。現在、Any Microインスタンスでは0.025ドル/時間、AWS Smallインスタンスでは0.09ドル/時間であるのに対し、dyno時間では1時間あたり0.05ドルです。

Herokuの dynoドキュメンテーション には、約512MBのRAMがあるため、恐らくtooではなく、dynoをEC2マイクロインスタンスに少し似ています。価格の2倍の価値はありますか?時間をどれだけ大切にしていますか?この標準を実現するためにIaaSオファリングの上に構築するのに必要な時間と労力は、決して安くはありません。本当にこの質問に答えることはできませんが、セットアップとメンテナンスの「隠れたコスト」を過小評価しないでください。

(ちょっとしたことですが、ここからダイノに接続すると(heroku run bash)、大まかな外観に/proc/cpuinfoの4つのコアと36GBのRAMが表示されます-これは私を導きます私は 「ハイメモリダブルエクストララージインスタンス」 を使用していると信じています。Heroku dynoドキュメンテーション は、各dynoが512MBのRAMを受け取り、そのため、最大71個の他のdynoと共有する可能性があります(HerokuのAWSインスタンスの同質性に関する十分なデータがないため、マイレージが異なる場合があります)

彼らはどのように彼らの競争相手に対抗しますか?

これ、私は本当にあなたを助けることができないと思う。私が実際に見た唯一の競争相手は Google App Engine でした-当時私はJavaアプリケーションをデプロイしようとしていて、 使用可能なフレームワークとテクノロジー の制限が信じられないほど不快です。これは「単なるJavaのこと」ではありません。一般的な制限と必要な考慮事項( FAQ ヒントのいくつか)の量は便利ではないように思われました。対照的に、Herokuへのデプロイは夢でした。

結論

これがあなたの質問に答えることを願っています(ギャップ/対処したい他の領域がある場合はコメントしてください)。私は自分の立場を提供すべきだと感じています。 Herokuは「迅速な展開」が大好きです。アプリケーションを起動していて、安価なホスティングが必要な場合(Herokuの無料利用枠は最高です-基本的に1つのWeb dynoと5MBのPostgreSQLのみが必要な場合は、アプリケーションを無料でホストできます)、Herokuが私の頼れるポジションです。複数の有償顧客、サービスレベル契約、運用などに専念する「本番稼働展開」の場合、Herokuにそのような制御をオフロードして、AWSまたは私たち自身のサーバーがホスティングプラットフォームとして選ばれています。

最終的に、それはあなたにとって最適なものについてです。あなたは「初心者プログラマー」だと言います-Herokuを使用することでRubyの作成に集中でき、コードに関連する他のすべてのインフラストラクチャを構築するのに時間を費やす必要がなくなるかもしれません。ぜひ試してみてください。


AWSには、Ruby、Node.js、PHP、Python、.NET、およびJavaをサポートするPaaSオファリング Elastic Beanstalk が実際にあります。一般に、ほとんどの人は「AWS」を見ると、間違いなくIaaSオファリングであるEC2、S3、EBSなどにジャンプします

2025
Kristian Glass

Kristian Glass Saidによると、IaaS( _ aws _ )とPaaS( HerokuEngineYard )の比較はありません。

PaaSは基本的に開発者がアプリの開発をスピードアップするのを助け、それによって構成を設定し、サーバーやデータベースのようなものを管理する代わりに、お金を節約しそして最も重要に彼らのアプリケーションとビジネスを革新します。 PaaSを使用するために購入するその他の機能としては、敏捷性、高可用性、監視、スケール/スケール縮小、専門知識の必要性の制限、展開の容易さ、コストと開発時間の短縮などがあります。

しかし、それでもPaaSには、PaaSの採用を妨げる障壁があります。

  • サーバーとデータベースに対する制御が少ない
  • 適切に管理されていない場合、コストは非常に高くなります
  • 現在の日と年齢では時期尚早で疑わしい

上記とは別に、あなたはIaaSを管理するのに十分なスキルを持っている必要があります。

  • ハードウェア取得
  • オペレーティング・システム
  • サーバーソフトウェア
  • サーバーサイドスクリプト環境
  • Webサーバー
  • データベース管理システム(Mysql、Redisなど)
  • 実動サーバーを構成する
  • テストと配置のためのツール
  • 監視アプリ
  • 高可用性
  • ロードバランシング/ HTTPルーティング
  • サービスバックアップポリシー
  • チームコラボレーション
  • 生産を再構築する

あなたが小規模事業を営んでいるなら、PaaSはあなたにとって最良の選択肢となるでしょう。

  • あなたが行くように支払う
  • 低い開始費用
  • 配管工事を専門家に任せる
  • PaaSは、自動スケーリング/スケール除去、負荷分散、災害復旧を処理します。
  • PaaSはすべてのセキュリティ要件を管理します
  • PaaSは信頼性、高可用性を管理します
  • Paasはあなたのために多くのサードパーティ製アドオンを管理します

それは要件に基づいて完全に個々の選択になります。あなたは私のPPT Hosting Rails Appsについての詳細を知ることができます

63
Pravin Mishra

開発、IT、およびビジネス目標からこの決定を検討するにはさまざまな方法がありますので、それが圧倒的に思われる場合でも悪く感じないでください。しかしまた - スケーラビリティをあきらめないでください。

あなたの 要件 について考えてください。

私は1日に8Mを超えるユニークなサービスを提供するWebサイトを設計し、1週間にテラバイトのビデオをインフラストラクチャ上に構築し、25万ドルの資本金で開始しました。

しかし、私は、年間10〜20万ドルを生み出すように設計され、トラフィック、データベース、処理の要件がそれほど高くない小規模なWebサイトもありました。

将来的には、デプロイメントはAWSよりHerokuに似たものになるでしょう。それは単に進歩のためです。 ITインフラストラクチャの規模拡大に伴う自動化が進んでいるわけではありませんが、ITやサービスの価値とは関係がありません。

また、FacebookやTwitterなどのサイトでのスケーラビリティの問題は非常に注目されていましたが、成功への悪影響はほとんどありませんでした - ニュース 寄付をした人がいるかもしれません もっとサインアップしてください(すべての報道はいい報道です)。

あなたが1日に100k +のユニークを生成し、スケーリングの問題を抱えているサービスを持っているなら、私はあなたがどんな言語、db、プラットフォーム、またはインフラストラクチャーであってもあなたのためにあなたの手からそれを取り除けてうれしい!

スケーラビリティは修正可能な実装上の問題です - 顧客を持たないことは実存的な問題です。

31
BricoleurDev

実際には両方を使用することができます - あなたはAmazonサーバーec2でアプリを開発することができます。それからそれを(gitで)しばらく無料でherokuにプッシュし(heroku free tierを使用して一般に提供する)、そのようにテストします。それはサーバを借りるのに比べて非常に費用対効果が高いです、しかしあなたはあなたが考えるべきである何かであるより制限的なheroku apiと話さなければならないでしょう。出典:この方法は私のオンラインクラスの1つに採用されました。「Coursera/StanfordのStartup engineering from Balaji S. Srinivasan and Vijay S. Pande

Added a scheme so my explanation will be easier to understand

31
sivi

既存の答えは概して正確です。

  • Herokuは非常に使いやすくデプロイしやすく、リポジトリ(例えばGitHub)の自動デプロイのために簡単に設定でき、たくさんのサードパーティアドオンを持ち、インスタンスごとにより多くの料金を請求します。

  • AWSには、DNS、ロードバランシング、安価なファイルストレージなど、競争力のある価格のファーストパーティサービスが幅広くあり、セキュリティポリシーを定義できるなどのエンタープライズ機能があります。

tl; dr の場合、この記事の最後までスキップしてください。

AWS ElasticBeanstalkは、Heroku風の自動スケーリングと簡単なデプロイプラットフォームを提供する試みです。 EC2インスタンス(自動的に作成される)を使用するので、EBサーバーは他のEC2インスタンスが実行できるすべてのことを実行でき、実行するのは安価です。

EBでの展開は非常に遅いです。 Herokuにアップデートをデプロイするのにほんの数秒であるのに対し、アップデートをデプロイするのはサーバあたり10〜15分かかり、より大きなクラスタにデプロイするのは1時間のうちの最も長い時間を要することがあります。 EBへの展開も特にシームレスに処理されないため、アプリケーション設計に制約が課される可能性があります。

ElasticBeanstalkが舞台裏で使用するすべてのサービスを使用して独自のオーダーメイドシステムを構築することができます(ただし、CodeDeploy、Elastic Load Balancer、Auto Scaling Groups、およびCodeCommit、CodeBuild、CodePipelineを使用する場合)。 EC2で設定するよりもかなり複雑で、わずかにトリッキーなので、数週間で初めて設定します。

AWS Lightsailは、競争力のある価格のホスティングオプションを提供しますが、展開や拡張には役立ちません - 実際には、EC2製品の単なるラッパーにすぎません(ただし、それ以上の費用がかかります)。これは初期設定時にbashスクリプトを自動的に実行することを可能にします。これはいい感じですが、EC2インスタンスを設定するだけのコスト(プログラム的にも行うことができる)と比較すると高価です。

比較についてのいくつかの考え(回り道はしていますが、質問に答えてみるために):

  1. セキュリティパッチ(および場合によってはOSのアップデート)を使用して、インストールしたすべてのものを最新の状態に保つなど、システム管理の作業量を過小評価しないでください。

  2. 自動展開、自動スケーリング、およびSSLのプロビジョニングと設定がどれほどのメリットであるかを過小評価しないでください。

    Gitリポジトリを更新したときの自動デプロイは、Herokuでは簡単です。これはほぼ瞬時に実行されるため、エンドユーザーに障害が発生することはなく、テスト/継続的インテグレーションに合格した場合にのみ更新するように設定できるので、壊れたコードをデプロイしてもサイトを壊すことはありません。

    自動デプロイにElasticBeanstalkを使用することもできますが、最初の1週間の設定に費やす準備ができています - ElasticBeanstalkがデプロイまたはビルドロジックを処理する方法で作業するには、アセットのデプロイおよびビルド方法を変更する必要があります。デプロイを処理するためにアプリに追加します。

    EBを停止することなくシームレスにデプロイするには、複数のインスタンスを実行する必要があります。サービスが低下しないように、EBは各サーバーに個別に更新をロールアウトします。それへのすべての要求が処理され終わるまでそれから古いサービス(それはそれを削除します)。

    興味深いことに、EBを使用して複数のサーバーを実行することによるホスティングコストは、特にアドオンのコストを含めると、1つのHerokuインスタンスよりも安価になります。

特に質問されていないが、他の答えによって提起されている他のいくつかの問題:

  1. 生産と開発に別のプロバイダを使用するのは悪い考えです。

    私は人々がこれを示唆していることを心に抱いています。理想的には、コードは可能な限り移植性のある任意の妥当なプラットフォーム上で正常に動作するはずですが、各ホスト上のソフトウェアのバージョンは大きく異なり、ステージングでコードが実行されるという理由だけではありません(メジャーNode.js /など) Ruby/Python/PHP/Perlのバージョンは、コードに互換性がないようにする方法で異なることがあります(多くの場合、まともなテストカバレッジがあってもキャッチされない可能性があります)。

    Herokuのようなものをプロトタイピング、小規模プロジェクト、およびマイクロサイトに活用することをお勧めします。そのため、構成やメンテナンスに多くの時間を費やすことなく、物事を迅速に構築および展開できます。

    この決定を行う際には、本番と本番前インスタンスの両方を実行するコストを考慮に入れてください。環境全体を複製するコスト(データストア/アドオンなどのサードパーティサービス、SSLのインストールおよび設定など)を忘れないでください。 。

  2. AWSを使用している場合、BitnamiのようなベンダーからのAWSの事前設定済みインスタンスには注意してください - それらはセキュリティの悪夢です。彼らは説明でそれを言及せずにデフォルトで多くの悪名高い脆弱なアプリケーションを公開することができます。

    代わりに、UbuntuやDebian(RPMサポートが必要な場合はCentOS)など、よくサポートされている主流のディストリビューションを使用することを検討してください。

    注:Amazonが提供するAmazon LinuxというディストリビューションにはRPMが使用されていますが、EC2に固有のものであり、サードパーティやオープンソースソフトウェアによるサポートはあまりありません。

  3. また、AWS(またはLightsail)上にEC2インスタンスを設定し、その上に flynn または dokku のように設定することもできます。その場合、複数のサイトを簡単にデプロイできます。たくさんのサービスを手に入れたり、新しいものを簡単に作成できるようにしたいと考えています。しかし、それを設定するのはHerokuを使用するだけでは自動化できず、設定と保守に多くの時間を費やすことになります(AmazonクラスタリングとDocker Swarmを使用してデプロイする方が設定よりも簡単です)。 YMMV).

私が取り組んでいるプロジェクトのニーズに応じて、AWS ECインスタンス(単独およびクラスター)、Elastic Beanstalk、Lightsail、およびHerokuを同時に使用しました。

サービスの設定に時間を費やすのは嫌ですが、Herokuの請求書をすべてに使用した場合、年間で数千ドルになるでしょう。AWSは、コストのほんの一部を解決します。

tl; dr

お金が問題にならないのなら、私はほとんどすべての作業にHerokuを使用することになります。ただし、Herokuが提供していない柔軟性と高度なサービスが必要なもっと複雑なプロジェクトにはAWSを使用したいと思います。

私にとって理想的なシナリオは、ElasticBeanstalkがHerokuのように機能した場合、つまり設定が簡単で、配置メカニズムが迅速で優れている場合です。

ほぼこれであるサービスの例は now.sh です。これは実際には背後でAWSを使用しますが、Herokuの場合と同じくらい簡単にデプロイとクラスタリングを行います(自動SSL、DNSあり)。 、優雅な展開、非常に簡単なクラスタの設定と管理).

Node.jsアプリケーションとDockerイメージのデプロイメントの両方に非常に多く使用しています。主な注意点はインスタンスが共有されていること(低コストに反映されていること)であり、現在専用インスタンスを購入する選択肢はありません。しかし、彼らのオープンソースデプロイメントツール「now」は、Google CloudやAzureと同様にAWS上の専用インスタンスにデプロイするためにも使用できます。

25
Iain Collins

まあ、人々は通常この質問をします。何かをデプロイし始めるときにHerokuまたはAWS。

HerokuとAWSの両方を使用した私の実験は、ここで私の簡単なレビューと比較です。

ヘロク

  • プロジェクトの種類に関わらずデプロイするための1つのコマンド:Ruby on Rails、Nodejs
  • プラグインとサードパーティを統合するためのワンクリック:とても簡単なことから始めるのは簡単です。
  • オートスケーリングはありません。つまり、手動で拡大/縮小する必要があります。
  • 特にシステムがより多くのリソースを必要とする場合、コストは高くつきます
  • 利用可能な無料のインスタンス
  • 空きインスタンスは、アクティブでない場合はスリープ状態になります。
  • データセンター:米国とEUのみ
  • Heroku run bashを使用してマシンレベルへのアクセス/アクセスをすることはできますが(MJafar Mashさん、助言をありがとう)、限られた種類のものです!フルアクセスがありません。
  • DevOpsについて知りすぎる必要はありません

AWS - EC2

  • これは、事前設定OSを搭載した(または搭載していない)マシンのように、ソフトウェア、ライブラリをインストールしてWebサイト/サービスをオンラインにする必要があります。
  • プラグインとライブラリは手動で統合するか、自動化スクリプト(公開スクリプトとあなたが書いたもの)が必要です。
  • 自動スケーリングとロードバランサはサポートされているサービスです。システムの設定と統合の方法を学ぶだけです。
  • 費用はかなり安いです、あなたがそれを使うサービスと時間の数によって異なります
  • T2.microインスタンスには数時間の空き時間がありますが、通常、毎月数ドルを払います(まだT2.microを使用している場合)。
  • あなたの無料のインスタンスは24時間365日利用可能で、スリープ状態になりません(あなたがそれを支払うかもしれないので:)
  • データセンター:世界中。あなたに最適な地域を選択してください。
  • 機械レベルに飛び込みます。だからあなたはそれを楽しむことができます
  • DevOpsに関するある程度の知識はありますが、大丈夫です、Stackoverflowは役に立ちます。

AWS Elastic Beanstalk Herokuの代わりとなるが安価

  • Elastic Beanstalkは2010年からパブリックベータとして発表されました。それは私達が展開を扱うのをより簡単にするのを助けます。詳細は ここ をご覧ください。

  • Beanstalkは無料です、あなたが支払う費用はあなたが使用するサービス&使用時間数のためになります。

  • 私は長い間Elastic Beanstalkを使用していますが、それがHerokuの代替品であり、より安価であると思います。

まとめ

  • Heroku:始めは簡単、 _ free _ インスタンス、しかし後で高価になる
  • AWS:簡単ではない、空き時間がある、 安い のようなもの、Beanstalkを使うことを心配すべき

だから私の現在のシステムでは、ステージングにHeroku、プロダクションにBeanstalkを使っています。

23
Hieu Pham

これは、HerokuからAWSへと移行する当社の事業の大部分を占めています。どちらにも利点がありますが、しばらくするとHerokuでは厄介になります。いったんHerokuの制限で維持するのが簡単ではなくなった特定のレベルの複雑さが必要になると。

そうは言っても、すばらしいフレームワーク/ツールを備えたAWS上にいることによって、Herokuの容易さとAWSの柔軟性を得るための選択肢が増えています。

6
Kendall Miller

まあ!私は、Herokuが新進開発者および新興開発者で有名であるのに対し、AWSは開発者ペルソナの高度な開発者であることに気づいています。 DigitalOceanもこの分野の主要なプレーヤーです。 Cloudwaysは、DigitalOceanとAWSをクリックするだけでランプスタックを簡単に作成できるようにしました。 1回のクリックですべてのサービスとパッケージの更新を行うことは、すべてのことを手動で行うよりもはるかに優れています。

あなたはここで完全にチェックアウトすることができます: https://www.cloudways.com/blog/Host-php-on-aws-cloud/

1
Shahroze Nawaz

面白いことに、Herokuは実際にバックエンドにAWSを使用しています。それはすべてのオーバーヘッドを取り除き、あなたのためにEC2のアーキテクチャ管理をします。 (インタビューの際に大企業の上級エンジニアからその知識を得ました)

1
Saurav Prakash

Amazon Web Services(AWS)は、99.9999999%の信頼性とデータおよびインフラストラクチャの可用性を備えた、IaaSからPaaSまでの多くのサービスを提供しています。 AWSは、開発者がアプリケーション展開プロセスをパイプライン化するためのインフラストラクチャの自動化といくつかのツールを提供しています。

一方、Herokuは、クラウド上でプラットフォームを管理するためのサービスを提供する単なるPaaSです。インフラストラクチャであろうとセキュリティであろうと、AWSとは関係がありません。

0
Prash

時々、私はなぜ人々がAWSをHerokuと比較するのだろうか。 AWSはIAAS(サービスとしてのインフラストラクチャ)であり、システムがいかに堅牢で計算的であるかを明確に示しています。一方、Herokuは単なるSAASであり、基本的にはAWSサービスのほんの一部にすぎません。それでは、Herokuを使って最初の製品をプライムに出荷できるのに、なぜAWSのセットアップに苦労するのでしょう。

Herokuは無料で、簡単で、ほとんどすべての種類のスタックをWebに簡単にデプロイできます。 Herokuは、アプリケーションを短時間でライブサーバーに配布するという面倒な作業をすべて回避するように設計されています。

それにもかかわらず、あなたは両方の当事者からのチュートリアルのいずれかを使用してあなたのアプリケーションを配置したくなるかもしれません

AWS DOCS および Heroku Docs

0
Sammy Joseph

HerokuはAWSのサブセットのようなものです。これはサービスとしてのプラットフォームにすぎませんが、AWSはあらゆるレベルで実装することができます。

実装は、ビジネス要件によって異なります。どちらかに収まる場合は、それに応じて使います。

0
Krunal Barot

HerokuはバックグラウンドでAWSを使用していますが、すべて必要なソリューションの種類によって異なります。 AMIを選んで配置オプションなどを選択するように、最初からvmを作成することについて心配していないのであれば、コアのLinuxおよびDevopsの人であれば、AWSを使用できます。あなたがそれらのざらつきを持たずに地表レベルで物事をやりたいなら、あなたは英雄と一緒に行くことができます。

0
prasoon

AWSとHerokuはどちらもクラウドプラットフォームですが、AWSがIaaSでHerokuがPaaSであるため、違いがあります。

0
Gopinath J