そのため、Google コンピューティング エンジンは昨日発表され、処理能力の価格はアプリ エンジンの標準よりもはるかに優れています。移行がどのようなものになるか、または現在のアプリで新しい Google コンピューティング仮想マシンを使用できるかどうか、誰か知っている人はいますか?
3 に答える
Google IO で、チームは GCE VM が GAE アプリ内から動的にスピンアップされるデモを示しました。このセッションを視聴し、コード サンプルをダウンロードして、2 つのサービス間の相互運用性について理解を深めることをお勧めします。YouTube の Google デベロッパー チャンネルに投稿したセッション
App Engine (AE) と Google Compute Engine (GCE) は異なるツールであるため、仕様と価格モデルが異なります。
GCE を使用すると、実行するサーバーの数、実行する時期、サーバーにインストールするソフトウェア スタックなどを選択できます。非常に強力であり、実行方法を選択できるだけでなく、実行方法も選択する必要があります。それらを実行します。
一方、AE はこれらすべての決定をユーザーに代わって行います: 実行中のスタック、要求に応じたサーバーのオン/オフ、分散永続ストレージなど。
したがって、移行を決定する前に、答えなければならない質問は次のとおりです。スタック全体を実行する自由 (および責任) が必要ですか? それとも、App Engine にスケーラビリティの詳細を任せ、アプリのコーディングに専念させますか?
上記の回答/コメントを読んだ後、GAE アプリを Compute Engine にデプロイする準備が整っていないことが明らかになりました。すべてのマネージド サービス (主に API、データストア、ドキュメント/インデックス検索、memcache、クラウド ストレージ、タスク キュー、cron ジョブなど)、プラットフォームとして提供される App Engine が同じではないことを十分に理解しています。 -コンピューティング エンジンで利用できる場合は、アクセス可能/統合対応のファッション。
現在、5 年前の完全に成長した App Engine アプリがあります。高レベルのカスタマイズ/制御をサポートし、サード パーティのソフトウェア/ミドルウェアをサーバー環境に追加するシナリオを検討していますが、これは App Engine では不可能です。App Engine 以外のすべてのソリューション (Compute Engine、Container Engine など) がある場合、そのような要件を満たすためにアプリケーションを移行する場合、そのような移行のコストはいくらですか?
異なる価格モデルの Compute Engine でのサーバーのプロビジョニングと構成の必要性 [了解しました。問題にはなりません :)]
同じ API を引き続き使用するために、コードの全部または一部を書き直します。データストア、クラウド ストレージ、タスク キュー、Cron ジョブ、ドキュメント検索、Memcache など [ここで確認が必要です。移行ガイドへの参照/リンクがあれば役立ちます!!]
これにより、App Engine から提供されるマネージド サービスや API が失われるリスクはありますか? ドキュメント検索、Memcache、タスク キュー、Cron ジョブが候補のようです。確認してください。
私の読みによると、Big Query、クラウド ストレージ、Pub-Sub API の統合は、このような移行によって大きな影響を受けることはありません (クライアント ライブラリまたは REST API は引き続き役立つはずです!)。確認してください。
一言で言えば、最初は完全に管理したかったので、5 年前には PaaS が正しい選択だったように思えました。ここで、アプリからプラットフォーム管理を差し引いたものと、選択に合わせてカスタマイズ/柔軟なものが必要です。この移行はどれほど複雑になるでしょうか?