Google App EngineとGoogle Compute Engineの違いは何ですか？
App EngineとCompute Engineの違いは何だろうと思いました。だれでも私に違いを説明できますか。
App Engineはサービスとしてのプラットフォームです。それはあなたがあなたのコードを単にデプロイすることを意味し、そしてプラットフォームはあなたのために他のすべてをします。たとえば、アプリが非常に成功した場合、App Engineは増加したボリュームを処理するために自動的にインスタンスを追加作成します。
Compute Engineは、サービスとしてのインフラストラクチャです。独自の仮想マシンインスタンスを作成して構成する必要があります。それはあなたに多くの柔軟性を与え、一般的にApp Engineよりもはるかに少ないコストです。欠点は、アプリと仮想マシンを自分で管理しなければならないことです。
必要に応じて、App EngineとCompute Engineの両方を混在させることができます。どちらも Google Cloud Platform の他の部分とうまく動作します。
編集（2016年5月）：
もう1つ重要な違いは、App Engine上で実行されているプロジェクトは、要求がない場合はインスタンス数をゼロにすることができることです。柔軟なランタイム（つまり「管理対象VM」）では、少なくとも1つのインスタンスを常に実行する必要があります。
編集（2017年4月）：
クラウド関数（現在ベータ版）は、抽象化という点ではApp Engineよりも上位のレベルです。インスタンスはありません。開発者は、HTTPリクエスト、Cloud Storageの変更など、さまざまなイベントに応答して実行される一口サイズのコードを展開できます。
App Engineとの最大の違いは、機能の価格が100ミリ秒ごとに設定されているのに対し、App Engineのインスタンスは15分間操作がないとシャットダウンされることです。もう1つの利点は、App Engineの呼び出しに新しいインスタンスが必要になる可能性があるのに対し、Cloud Functionsがすぐに実行され、新しいインスタンスのコールドスタートに数秒以上かかることがあることです。
これは、Cloud Functionsが（a）まれな呼び出しに最適なものにします - 何かが起こった場合にインスタンスを稼働させ続ける必要はありません。
基本的な違いは、 Google App Engine（GAE） は サービスとしてのプラットフォーム（PaaS） 一方 Google Compute Engine（GCE） は サービスとしてのインフラストラクチャです（IaaS） 。
アプリケーションをGAEで実行するには、コードを書いてそれをGAEにデプロイするだけです。他の頭痛の種はありません。 GAEは完全にスケーラブルであるため、トラフィックが増加すると自動的にインスタンスが増え、トラフィックが減少するとインスタンスが減少します。実際にを使用しているリソースに対して課金されます。つまり、Instance-Hoursの料金が請求されます。 /、転送データ、Storageetcあなたのアプリが本当に使っていた。しかし制限は、あなたが作成できるのはPython、PHP、Java、NodeJS、.NET、Rubyそして** Goだけです。
一方、GCEは完全なインフラストラクチャをVirtual Machineの形式で提供します。そこに任意のプログラムを書いたりインストールしたりできるので、あなたはそれらのVMの環境とランタイムを完全に制御することができます。実際にGCEはGoogle Data Centersを仮想的に使用する方法です。 GCEでは、スケーラビリティを処理するようにLoad Balancerを使用するようにインフラストラクチャを手動で設定する必要があります。
GAEとGCEは両方とも Google Cloud Platform の一部です。
更新：2014年3月、GoogleはApp Engineの下にManaged Virtual Machineという新しいサービスを発表しました。 Managed VMは、App Engineアプリケーションに、アプリケーションプラットフォーム、CPU、およびメモリオプションよりももう少し柔軟性を提供します。 GCEと同様に、これらのVMでアプリエンジンアプリケーション用のカスタムランタイム環境を作成できます。 App Engineの実際に管理されたVMは、IAASとPAASの間の境界をある程度ぼかします。
簡単に言うと、compute engineはあなたに完全な制御/責任を持つサーバーを提供します。あなたはオペレーティングシステムに直接アクセスすることができます、そして、あなたはあなたが望むすべてのソフトウェアをインストールします、それは通常ウェブサーバー、データベースなどです...
アプリエンジンでは、基盤となるソフトウェアのオペレーティングシステムを管理しません。あなたはコード（Java、PHP、Python、またはGo）をアップロードするだけで出来上がります - それはただ実行されます...
App Engineは、特に未経験者にとって頭痛の種を節約しますが、2つの重大な欠点があります。可能、または1つの特定の方法でのみ可能（ファイルの保存や書き込みなど）。
あるいはそれをさらに単純にするために（時にはGAE StandardとGAE Flexを区別することができないため）。
Compute Engineは、仮想PCに似ています。たとえば、小規模なWebサイトとデータベースを展開します。あなたはインストールされたディスクドライブの制御を含むすべてを管理します。 Webサイトを展開する場合は、DNSの設定などを担当します。
Google App Engine（Standard）は読み取り専用のサンドボックスフォルダーのようなもので、そこから実行するコードをアップロードし、残りの部分について心配する必要はありません（はい：読み取り専用 - あなたのためにインストールされているライブラリの固定セットがあり、あなたは自由にサードパーティのライブラリをデプロイすることはできません。 DNS /サブドメインなどはマッピングがはるかに簡単です。
Google App Engine（Flexible）は、ファイルシステム全体（ロックされたフォルダだけではありません）のようなもので、標準よりも強力な機能を備えています。エンジン、例えば読み取り/書き込み権限があります（ただし、Compute Engineと比較すると少ない）。 GAE規格では、固定セットのライブラリがインストールされているため、サードパーティのライブラリを自由に配置することはできません。 Flexible環境では、カスタムビルド環境（Python 3など）を含め、アプリが依存している任意のライブラリをインストールできます。
GAE Standardは対処が非常に面倒ですが（Googleはそれを単純に聞こえるようにしますが）、プレッシャーを受けると本当にうまくスケーリングします。ロックダウンされた環境との互換性をテストして確認し、使用している他社製ライブラリが他の他社製ライブラリを使用していないことを確認する必要があるため、面倒です。実際の設定には時間がかかりますが、単純な展開では長い目で見ればより多くの価値があります。
App Engine vs Compute Engineに加えて、Google Kubernete Engineとの比較や、小規模から大規模までの幅広いアプリケーションでの経験に基づいたメモも含まれています。その他の点については、Google Cloud PlatformのドキュメントのApp Engine StandardおよびFlexの機能の概要についてのページ を参照してください。App Engine環境の選択 。 App EngineとKubernetesの導入に関するもう1つの比較については、Daz Wilkin App Engine FlexまたはKubernetes Engine による投稿を参照してください。
App Engine Standard
長所
- 直接費やアプリの維持費の点で、トラフィックの少ないアプリには非常に経済的です。
- オートスケーリングは速いです。 App Engineの自動スケーリングは、軽量 のインスタンスクラスF1〜F4 に基づいています。
- バージョン管理と トラフィック分割 は速くて便利です。これらの機能は、App Engine（標準とFlexの両方）にネイティブに組み込まれています。
- 最小限の管理、開発者は自分のアプリにだけ焦点を合わせる必要があります。開発者は、GCEのように信頼性の高い方法でVMを管理したり、GKEのようにクラスターについて学習したりする必要はありません。
- データストアへのアクセスは高速です。 App Engineが最初にリリースされたとき、ランタイムはDatastoreと同じ場所にありました。後のDatastoreはスタンドアロン製品 Cloud Datastore として分割されましたが、App Engine StandardとDatastoreの共存は残ります。
- Memcacheへのアクセスがサポートされています。
- App Engineサンドボックスは非常に安全です。仮想マシンがオペレーティングシステムレベルで引き継がれるのを防ぐために独自の努力をする必要があるGCEまたは他の仮想マシンでの開発と比較して、App Engine Standardサンドボックスはデフォルトで比較的安全です。
短所
- 一般的に他の環境よりも制約が少ないインスタンスは小さいです。これは迅速な自動スケーリングには適していますが、多くのアプリは、最大96コアのGCEインスタンスサイズなど、より大きなインスタンスから恩恵を受けることができます。
- ネットワーキングはGCEと統合されていません
- App EngineをGoogle Cloud Load Balancerの背後に配置することはできません。サポートされているランタイム：Python 2.7、Java 7と8、Go 1.6-1.9、およびPHP 5.5に制限されています。 Javaでは、サーブレットのサポートはいくつかありますが、完全なJ2EE標準はありません。
App Engine Flex
長所
- カスタムランタイムを使用できます
- GCEネットワーキングとのネイティブ統合
- バージョンとトラフィック管理は標準と同じように便利です
- インスタンスサイズが大きいほど、大規模で複雑なアプリケーション、特に大量のメモリを使用できるJavaアプリケーションに適しています。
短所
- ネットワーク統合は完璧ではありません - 内部ロードバランサーやShared Virtual Private Cloudとの統合はありません
- 管理対象Memcacheへのアクセスは一般に利用できません
Google Kubernetes Engine
長所
- コンテナーとのネイティブ統合により、カスタム・ランタイムおよびクラスター構成に対するより優れた制御が可能になります。
- 不変のランタイム環境 や以前のバージョンにロールバックする簡単な機能など、仮想マシンを操作する多くのベストプラクティスを体現しています
- 一貫性のある繰り返し可能なデプロイメントフレームワークを提供します。
- クラウドとオンプレミス間の移植性に関するオープンスタンダード、特にKubernetesに基づいています。
- バージョン管理はDockerコンテナと Googleコンテナレジストリ で実現できます。
短所
- トラフィックの分割と管理は日曜大工で、おそらくIstioとEnvoyを利用している
- 管理オーバーヘッド
- ポッド、デプロイ、サービス、イングレス、ネームスペースなどのKubernetesの概念に慣れるまでにしばらく時間がかかる
- 現在ベータ版の Private Clusters を使用しない限り、パブリックIPを公開する必要があるが、その必要性を排除するが、それでもkubectlコマンドが存在する場所へのアクセスを提供する必要があるから実行。
- モニタリング統合が完璧ではない
- L3内部ロードバランシングはKubernetes Engine上でネイティブにサポートされていますが、L7内部ロードバランシングは日曜大工で、おそらくEnvoyを活用しています
Compute Engine
長所
- 立ち上げが簡単 - KubernetesやApp Engineを立ち上げる必要はなく、以前の経験から知っていることは何でも再利用できます。これがおそらくCompute Engineを直接使用する主な理由です。
- 完全な制御 - 多くのCompute Engine機能を直接利用して、最新のものを最新のものにインストールして、最新のEdgeを維持することができます。
- パブリックIPは必要ありません。パブリックIPに公開されているものがあると、従来のソフトウェアの中にはロックするのが難しすぎるものもあります。
- Dockerコンテナーを実行するためにContainer-Optimized OSを活用することができます。
短所
- Cloud Launcherを含むさまざまな場所からソリューションを再利用することはできますが、信頼性とセキュリティのために適切に実行するのは困難な場合があります。
- より多くの管理オーバーヘッド。 Compute Engineには多くの管理ツールがありますが、App EngineやKubernetes Engineの監視ツールのように、アプリケーションのデプロイ方法を必ずしも理解しているとは限りません。
- 自動スケーリングはGCEインスタンスに基づいており、App Engineより遅くなる可能性があります。
- 傾向は、スノーフレークGCEインスタンスにソフトウェアをインストールすることです。
App Engineを使用すると、開発者はGoogle Compute Engineのコアを制御したり、Google Compute Engineのデータ処理アプリケーションにWeb向けのフロントエンドを提供したりできます。
一方、Compute Engineは仮想マシンの直接かつ完全なオペレーティングシステム管理を提供します。アプリを表示するには、リソースが必要になるでしょう。GoogleCloud Storageは、資産やデータを保存するのに理想的です。あなたは世界中でホスティングすることで速いデータアクセスを得ます。信頼性は99.95％の稼働時間で保証されています。また、Googleはデータをバックアップおよび復元する機能も提供しています。
Google Cloud Storageを使用して資産を管理、保存、取得、表示、削除することができます。また、Cloud Storageに保存されているフラットデータシートをすばやく読み書きすることもできます。 Google Cloudのラインナップの次はBigQueryです。 BigQueryを使用すると、膨大な量のデータを分析できます。数秒以内に何百万ものレコードについて話しています。アクセスは、わかりやすいUI、Representational State Transfer、またはRESTインターフェイスを介して処理されます。
データストレージは、ご想像のとおり、問題ではなく、数百TBにまで拡張されています。 BigQueryは、Java、.NET、Python、Go、Ruby、PHP、Javascriptなどの多数のクライアントライブラリからアクセスできます。 NoSQLと呼ばれるSQLのような構文が利用可能であり、これらはこれらのクライアントライブラリを通して、またはウェブユーザーインターフェースを通してアクセスすることができます。最後に、Google Cloudプラットフォームのデータベースオプション、Cloud SQLとCloud Datastoreについて説明しましょう。
大きな違いがあります。 Cloud SQLはリレーショナルデータベース、主にMySQLを対象としていますが、Cloud DatastoreはnoSQLを使用する非リレーショナルデータベースを対象としています。 Cloud SQLでは、データベースインスタンスごとに100 GBのストレージと16 GBのRAMを使用して、アメリカ、ヨーロッパ、またはアジアでホストすることを選択できます。
Cloud Datastoreは、1か月あたり最大50 Kの読み取り/書き込み命令と、1か月あたり1 GBのデータを無料で入手できます。あなたがこれらのクォータを超えるなら、しかし、料金があります。 App Engineは、APIバックエンドを作成するためのCloud Endpoints、データ分析および傾向予測のためのGoogle Prediction API、多言語出力のためのGoogle Translate APIなど、Googleクラウドプラットフォームの他のあまり知られていない、よりターゲットを絞ったメンバーと連携できます。
App Engineを使用してかなりの量の作業を行うことができますが、他のGoogle Cloudプラットフォームサービスを使用して簡単かつ効率的に機能することを考慮すると、急増する可能性があります。
すでに説明したように、Google Compute Engine（GCE）はサービスとしてのインフラストラクチャ（IaaS）であり、Google App Engine（GAE）はサービスとしてのプラットフォーム（PaaS）です。次の図をチェックして、違いをよりよく理解することができます（ here から取り出して説明します） -
Google Compute Engine
GCEはGoogle Cloud Platform（GCP）から提供される重要なサービスです。ほとんどのGCPサービスは管理層の下のGCEインスタンス（VM）を使用するためです（どちらが使用しないかは不明）。これにはApp Engine、Cloud Functions、Kubernetes Engine（以前のContainer Engine）、Cloud SQLなどが含まれます。GCEインスタンスはそこで最もカスタマイズ可能な単位であるため、アプリケーションが他のGCPサービスで実行できない場合にのみ使用します。ほとんどの場合、GCEを使用してOn-PremアプリケーションをGCPに転送します。最小限の変更で済みます。後で、彼らは自分のアプリの別々のコンポーネントに他のGCPサービスを使用することを選択できます。
Google App Engine
GAEはGCPによって提供される最初のサービスです（Googleがクラウドビジネスに参入するずっと前から）。 0から無制限のインスタンスまで自動スケールします（その下にGCEを使用します）。 2種類の標準環境とフレキシブル環境があります。
Standard Environmentは本当に高速で、誰もあなたのアプリを使用していないときは0インスタンスまでスケールアップ、数秒でスケールアップおよびスケールダウンし、キャッシュ、認証などのために専用のGoogleサービスとライブラリを持っています。サンドボックス内で実行されるためです。特定のプログラミング言語に対してのみマネージランタイムを使用する必要があります。最近追加されたのはNode.js（8.x）とPython 3.xです。古いランタイムは、Go、PHP、Python 2.7、Javaなどで利用可能です。
Flexible Environmentは、dockerコンテナを使用するためカスタムランタイムを使用できるため、よりオープンです。したがって、提供されているランタイムでランタイムが利用できない場合でも、実行環境用に独自のdockerfileをいつでも作成できます。それに関する警告は、誰もあなたのアプリを使用していなくても、少なくとも1つのインスタンスが実行されていることを必要とし、さらにスケールアップとスケールダウンは数分を必要とします。
GAEの柔軟性をKubernetes Engineと混同しないでください。後者は実際のKubernetesを使用し、より多くのカスタマイズと機能を提供します。 GAE Flexは、ステートレスコンテナが必要で、アプリケーションがHTTPまたはHTTPSプロトコルのみに依存している場合に便利です。他のプロトコルでは、Kubernetes Engine（GKE）またはGCEが唯一の選択肢です。より良い説明のために 私の他の答え をチェックしてください。
私は理にかなった方法でそれを説明します。
PaaS（Compute Engine）：自分でやる、またはITチームを抱えていて、クラウド上のコンピュータをレンタルしたいだけの場合特定のOS（例えばLinux）、あなたはCompute Engineに行きます。あなたは自分ですべてをやらなければなりません。
SaaS（App Engine）：あなたが（例えば）Pythonプログラマーで、Linuxがインストールされている事前設定済みのコンピューターをクラウド上でレンタルしたい場合他の外部サービスと統合するために必要なモジュールといくつかのプラグインを備えた稼働中のWebサーバーと最新のpython 3、あなたはApp Engineのために行きます。
Microservice（Cloud Functions）：特定の仕事をするAPI（関数）をたくさん書きたい場合は、Google Cloud Functionsを利用してください。あなたはそれらの特定の機能に集中するだけで、残りの仕事はあなたの機能をマイクロサービスとして公開するためにあなたのために行われます。
あなたが深くなるにつれて、あなたはいくらかの柔軟性を失います、しかしあなたは不必要な技術的側面について心配しません。あなたはもう少し支払いもしますが、サポートサービスの時間とコストを節約します（ITパート）：他の誰か（google）があなたのためにそれをやっています。