クラウド機能よりもApp Engineを選択する場合
申し訳ありませんが、これは素朴な質問ですが、グーグルのスタッフからたくさんの講演を見ましたが、なぜ地球上でCFの代わりにAEを使用するのか理解できませんか？
正しく理解できれば、これらのサービスの両方のコンセプトは「マイクロサービスアーキテクチャ」を構築することです。
- cFとAEの両方がステートレスです
- 両方とも限られた期間に実行することを想定しています
- どちらもdbsや他のgcp apiとやり取りできます。
ただし、AEは独自のサーバーにラップする必要があります。基本的に、CFと同じ機能に加えて、多くの複雑さを利用します。だから、いつCFの代わりにそれを使うべきですか？
クラウド機能（CF）とGoogle App Engine（GAE）は、ジョブごとに異なるツールです。通常、ジョブに適切なツールを使用することをお勧めします。
ペンチmightを使用して釘を打つことは可能ですが、ハンマーを使用するほど便利ではありません。同様に、CFmightを使用して複雑なアプリを構築することも可能ですが、GAEを使用して構築する方が間違いなく便利です。
CFには、GAEと比較していくつかの欠点があります（もちろん、より複雑なアプリケーションを構築するという点で）。
- それらは
Node.JS、Python、Goに限定されています。 GAEは、他のいくつかの一般的なプログラミング言語をサポートしています - 本当に軽量に設計されていますstandalone機能の一部であり、そのようなコンポーネントを使用して複雑なアプリケーションをすばやく構築しようとすると、「厄介」になります。はい、個々のリクエストの相互関係コンテキストも同様にGAEで復元する必要があります。CFで利用できないより便利な手段を使用することでGAEのみが恩恵を受けます。たとえば、他のコメントで説明されているユーザーセッション管理
- GAEアプリには、個々のリクエストを超えて存続するアプリコンテキストがありますが、CFにはありません。このようなコンテキストにより、GAEアプリでは特定のGoogleサービスへのアクセスがより効率的/高性能になります（または単純に可能になります）。たとえば、memcached。
- gAEアプリのアプリコンテキストの可用性は、CFで動作できない他のサービスのより効率的でパフォーマンスの高いクライアントライブラリをサポートできます。たとえば、
ndbクライアントライブラリ（標準env GAE pythonアプリ）でのみ使用可能）を使用してデータストアにアクセスすると、汎用データストアクライアントライブラリを使用するよりも効率的/パフォーマンスが向上します。 - GAEは、「小売」価格のCF（各呼び出しが個別に請求される）と比較して、「卸売」価格（特定のインスタンスが処理するリクエストの数に関係なく、インスタンス時間に基づく）であるため、より費用効果が高くなります。
- 応答時間mightは、通常、リクエストを処理するアプリインスタンスが既に実行されているため、CFよりGAEアプリの方が短くなります。したがって、
- gAEアプリコンテキストをロード/復元する必要はありません。既に利用可能であり、CFはそれをロード/復元する必要があります。
- 処理コードは（ほとんどの場合）既にロードされていますが、CFのコードはまだロードする必要があります。これについては定かではありませんが、基本的な実装に依存すると思います。
App Engineは、相互に関連する（または関連しない）さまざまな方法で動作する多数の機能を備えたアプリケーションに適しています。一方、クラウド機能は、特定のイベントに応答して特定のアクションを実行する単一の目的の機能です。
App Engineでは、言語の選択肢が多数あり、管理オプションも増えていますが、これらの領域ではクラウド機能が制限されています。
App EngineでCloud Functionsを簡単に複製できますが、多数の個別のCould Functionsを使用して大規模なApp Engineアプリケーションを複製するのは複雑です。たとえば、SpotifyのバックエンドはApp Engineベースです。
別の言い方をすると、非常に大規模なアプリケーションの場合、App Engineのようなより複雑なシステムから始めると、コードベースの複雑さが軽減されるか、少なくとも管理や理解が容易になります。
最終的に、これらは両方ともGoogleの同様の基盤インフラストラクチャで実行され、どちらが手元のタスクで機能するかを決定するのはユーザー次第です。さらに、1つのプロジェクトで両方の要素を混合することを妨げるものは何もありません。