保持したいかなりのコードが既に動作していることを考えると、GAE に代わるものはありますか。つまり、パイソンを掘っています。ただし、私のユース ケースはリクエスト数が少なく、CPU 使用率が高いタイプのユース ケースであり、App Engine を永遠に使い続けることはできないのではないかと心配しています。アマゾン ウェブ サービスや他の種類のクラウド プロバイダーについて多くの人が話しているのを聞いたことがありますが、これらの他のサービスのほとんどが、アプリが提供するさまざまなサービス (データ クエリ、ユーザー認証、自動スケーリング) をどこで提供しているのかを理解するのに苦労しています。エンジンが提供します。ここでのオプションは何ですか?
13 に答える
AppScale
AppScale は、ユーザーが独自の Google App Engine アプリケーションをデプロイしてホストできるようにするプラットフォームです。Amazon EC2 と Eucalyptus、Xen と KVM で自動的に実行されます。AppScale Systemsによって開発および保守されています。Python、Go、PHP、および Java Google App Engine プラットフォームをサポートしています。
http://github.com/AppScale/appscale
その間...
...もうすぐ 2015 年ですが、コンテナが前進する道だと思われます。GAE の代替手段が出現しています。
Google は、 GCE コンテナーを管理するために開発されたコンテナー スケジューリング ソフトウェアであるKubernetesをリリースしましたが、他のクラスターでも使用できます。
次のような Docker 上の PaaSがいくつか予定されています。
注目すべき興味深いもの。
GAE は独自のクラスにあるため、現時点では (コードの移植性に関して) GAE に代わるものはないと思います。確かに GAE はクラウド コンピューティングですが、私は GAE をクラウド コンピューティングのサブセットと見なしています。Amazon の EC2 もクラウド コンピューティングです (Joyent Accelerators、Slicehost Slices と同様) が、明らかに 2 つの異なる獣でもあります。したがって、現在、ニーズに応じてアーキテクチャを再考する必要がある状況にあります。
GAE の直接的な利点は、インフラストラクチャ (スケーラブルな Web サーバーとデータベース管理) に関連するため、基本的にメンテナンス フリーであることです。GAE は、基礎となるシステムではなく、アプリケーションのみに集中したい開発者向けに調整されています。また、これらの他のクラウド コンピューティング ソリューションも、VM イメージ/テンプレートを提供することで、アプリケーションについて必要なだけ心配することができるようにしようとしています。最終的には、ニーズによって、取るべきアプローチが決まります。
これらすべてを念頭に置いて、ニーズを満たすハイブリッドソリューションと回避策を構築することもできます. たとえば、GAE は、あなたが説明したこの特定のアプリのニーズに直接適しているようには見えません。言い換えれば、GAE は比較的多数のリクエストを提供し、CPU サイクル数は少ない (有料版が異なるかどうかは不明)。
ただし、この課題に取り組む 1 つの方法は、GAE をフロントエンドとして、Amazon AWS (EC2、S3、および SQS) をバックエンドとして含むカスタマイズされたソリューションを構築することです。スタック全体を AWS で構築したほうがよいと言う人もいますが、それには多くの既存のコードの書き直しも必要になる場合があります。さらに、回避策として、以前のstackoverflow の投稿で、GAE でバックグラウンド タスクをシミュレートする方法について説明しています。さらに、HTTP Map/Reduceを調べてワークロードを分散することもできます。
2016 年の時点で、PaaS (サービスとしてのプラットフォーム) とFaaS (サービスとしての機能) を同じサーバーレス コンピューティングカテゴリにまとめたい場合は、FaaS の選択肢がいくつかあります。
独自の
AWS ラムダ
AWS Lambda を使用すると、サーバーをプロビジョニングまたは管理することなくコードを実行できます。消費した計算時間に対してのみ料金が発生します。コードが実行されていないときは料金は発生しません。Lambda を使用すると、ほぼすべてのタイプのアプリケーションまたはバックエンド サービスのコードを実行できます。すべて管理不要です。コードをアップロードするだけで、高可用性を備えたコードの実行とスケーリングに必要なすべてを Lambda が処理します。コードをセットアップして、他の AWS サービスから自動的にトリガーしたり、任意のウェブまたはモバイルアプリから直接呼び出したりできます。
AWS Step Functionsは AWS Lambda を補完します。
AWS Step Functions を使用すると、視覚的なワークフローを使用して、分散アプリケーションとマイクロサービスのコンポーネントを簡単に調整できます。それぞれが別個の機能を実行する個々のコンポーネントからアプリケーションを構築すると、アプリケーションを迅速に拡張および変更できます。Step Functions は、コンポーネントを調整し、アプリケーションの機能をステップ実行するための信頼できる方法です。Step Functions は、アプリケーションのコンポーネントを一連のステップとして整理および視覚化するためのグラフィカル コンソールを提供します。これにより、マルチステップ アプリケーションの構築と実行が簡単になります。Step Functions は、各ステップを自動的にトリガーして追跡し、エラーが発生した場合は再試行するため、アプリケーションは順番に期待どおりに実行されます。Step Functions は各ステップの状態をログに記録するため、問題が発生した場合は、問題をすばやく診断してデバッグできます。
Google クラウド関数
2016年現在、アルファ版です。
Google Cloud Functions は軽量でイベントベースの非同期コンピューティング ソリューションであり、サーバーやランタイム環境を管理する必要なく、クラウド イベントに応答する小さな単一目的の関数を作成できます。Google Cloud Storage および Google Cloud Pub/Sub からのイベントは、Cloud Functions を非同期的にトリガーするか、HTTP 呼び出しを使用して同期実行することができます。
Azure 関数
開発を加速するイベントベースのサーバーレス コンピューティング エクスペリエンス。需要に応じてスケーリングでき、消費したリソースに対してのみ料金が発生します。
開ける
サーバーレス
Serverless Framework を使用すると、自動スケーリング、実行ごとに支払う、イベント駆動型の機能を任意のクラウドにデプロイできます。現在、Amazon Web Service の Lambda をサポートしており、他のクラウド プロバイダーをサポートするように拡張中です。
鉄の機能
IronFunctions は、プライベート、パブリック、またはハイブリッドのあらゆるクラウド向けのオープン ソース サーバーレス コンピューティング プラットフォームです。
FaaS が CaaS (サービスとしてのコンテナー) とどの程度競合するかはまだわかりません。前者の方が軽いようです。どちらもマイクロサービス アーキテクチャに適しているようです。
関数 (FaaS など) は終わりではなく、何年も先に、テストのみの開発などのさらなるサービスの抽象化が見られ、その後に平易な言語のシナリオが続くと予想しています。
Microsoft Windows Azure は検討する価値があるかもしれません。申し訳ありませんが、使用していないため、良いかどうかはわかりません。現時点では CTP であることを覚えておいてください。
AWS Elastic Beanstalkも参照してください。これは、IaaS (つまり EC2) ではなく PaaS として設計されているという点で、GAE 機能とほぼ同等です。
Amazon の Elastic Compute Cloud または EC2 は適切なオプションです。基本的に、サーバー上で Linux VM を実行します。これは、Web インターフェース (電源のオン/オフ) を介して制御できます。もちろん、SSH または通常の設定を介してアクセスできます...そして、制御するのは Linux インストールであるため、次のことができます。もちろん、必要に応じて python を実行します。
クラウドに興味があり、本番用やテスト用に独自のクラウドを作成したい場合は、Eucalyptusを確認する必要があります。EC2 とコード互換性があると言われていますが、オープン ソースです。
CPU を集中的に使用するリクエストに使用される別のサーバーと App Engine を簡単に結合する方法を知りたいです。
TyphoonAEはこれを行おうとしています。テストはしていませんが、まだベータ版ですが、少なくとも活発な開発が行われているようです。
また、Red Hat の Cape Dwarf プロジェクトを使用して、変更なしで Wildfly アプリサーバー (以前の JBoss) 上で GAE アプリを実行することもできます。
ここで確認できます:
クラウド コンピューティングへの移行は急速に進んでいるため、さまざまなプラットフォームをテストするために無駄にしている時間はありません。Java にも興味がある場合は、Jelasticを試すことをお勧めします。
Jelastic の最も優れた点の 1 つは、アプリケーションの機能の変更を除いて、アプリケーションのコードを変更する必要がないことですが、選択したプラットフォームがこれを要求する理由によるものではありません。これを参照すると、実際に時間を無駄にすることはありません。展開プロセスは完璧であり、.war ファイルをさらにどこにでも展開できます。GAE を使用するには、システムのニーズに合わせてアプリを変更する必要があります。Java を使用するようになり、より柔軟なプラットフォームを探し始めた場合に備えて、Jelastic は互換性のある代替手段です。