Google App Engine Googleのインフラストラクチャなしで他のプラットフォームで動作するPythonコードを書くためのガイドラインはありますか？Google App Engine Pythonのロックインを解除しますか？
他のプラットフォームでGoogle App Engine用に設計されたアプリケーションを実行できるオープンソースフレームワークを作成しようとする試みはありますか。
編集：私は今はGoogle App Engineでアプリケーションを開発する場合、私は後で別のプラットフォームに移行することができるようになります
、またはそれは、ロックです：
明確にするために、質問は本当にです？
アプリは完全に移植するために必要な部品の数があります：
ご覧のとおり、多くの作業が必要ですが、App EngineアプリケーションをGoogle環境外で実行するための基本的な障壁はありません。事実、関心があるならば、あなたは参加を歓迎する以上のものです。私と他の人は、さまざまな部分のソリューションを、自分のアプリケーションをホストするための単一の「OpenEngine」ソリューションに組み合わせる計画を持っています。
+1、優れた詳細な分析、有用なポインタ。 –
要約：現在のソリューションは存在しませんが、多くの人々がそれに向けて取り組んでいます:)。 ありがとうございます。 – Alterlife
09年5月以降、この取り組みに大きな進展はありませんでしたか？ –
ほとんどの場合、コードは移植可能でなければなりません（AppEngineで使用できないモジュールと、どのAppEngine固有のコードが禁止モジュールに対応しているかを示すのに非常に役立ちます）が、AppEngineの全ポイントはGoogleのインフラストラクチャへのアクセスインフラストラクチャを使用しない場合は、AppEngineの制限事項にコードを記述することはあまり意味がありません。
明確にするために、質問は実際には次のとおりです： Google App Engineで今開発した場合、後で別のプラットフォームに移行できますか、それともロックされていますか？ – Alterlife
その場合、Guruにはおそらくあなたの答えがあります。 –
Google App Engineプロジェクトをホストできるapp-dropという実験ホストが見つかりました。これは、Googleのインフラストラクチャの外でアプリエンジンプロジェクトを実行するには、少なくともがであることを意味するはずです。
しかし、これは明らかに生産にはまだ適していません。
私は間違っているかもしれませんが、私の直感は、現時点では、これを生産の代替手段として数えないと私に言います。 –
DjangoのPythonフレームワークを使用してAppEngineアプリケーションを構築することができます（ただし、サポートされているバージョンは最新のDjangoリリースより少し遅れています）。永続性のためにGQL/BigTableを使用する場合は、移植性を失う場所（少なくとも今のところ）があります。これはGoogle独自のデータベースプラットフォームです。ハンク氏によれば、これはAppEngineを実際に使用する最大の理由の1つですが、最大のロックポイントでもあります。ここで
はAppEngineのとGQL/BigTableの中Djangoのサポートへのリンクのカップルです：
AppEngineの上で動作し、高レベルのフレームワークを使用してください。そうすれば、必要に応じてコードを他のサーバーに移植することができます。
djangoはAppengine patchプロジェクトで動作するようにパッチが適用され、移植されており、appengineで最も使用されているFWです。
あなたは限りApp Engineアプリケーションを実行するための並列インフラが懸念しているとして、それは道遠く、まだですrunning a django app on App engine
にステップイントロで、この手順を参照したいことがあります。 App Engine自体は、それが信じられていて、Googleが望んでいたほど普及していません。さらに、組み込みのWebAppフレームワークではdjangoよりも開発が難しいです。
appエンジンアプリケーションを実行するための並列インフラストラクチャを少なくとも見逃すことはほとんどありません。むしろ、djangoやその他の一般的なフレームワークは、アプリエンジンの枠組みの外で動作し、これに関する作業は現在参照されているプロジェクトで進行中であると考えられます。
私がapp-engine-patchで指摘する1つの問題は、Djangoモデルを使用していないことです。代わりにGAEモデルを直接開発者に公開します。それは必ずしも悪いことではありません。 DjangoモデルではGAEで動作しないモデルがいくつかあります。抽象化は非常に漏れやすいでしょう。 しかし、これは、GAEからネイティブに移植するときにモデルを最低限書き直すことを意味します。大規模なプロジェクトでは些細なことではなく、構文の違いによってすべてのクエリに触れることになります。 – esm
私はesmに同意します。基本的なスタックはwsgiapp、cache、datastoreです。 Wsgiappとキャッシュは、bigtable特性が高速になる標準的で永続的なストレージです（mongo、tokyo、memcachedb）。 –
"App Engine自体は、それが信じられていて、Googleが望んでいたほど普及していません。また、組み込みのWebAppフレームワークではdjangoよりも開発が難しいです。 - 私は両方の主張に同意しない。私たちが話しているように、人々はオープンソースのインフラストラクチャに取り組んでいます。たとえば、AppScaleを参照してください。 –
AppDropは、Amazon Web Services/Elastic ComputingへのAppEngineのコンセプトポートで、2008年4月に完成しました.BlackTableの代わりにフラットファイルを使用し、単一のインスタンスで動作するためスケーリングの問題があります。しかし、開発者によれば、彼にはわずか4日しかかかりませんでした。おそらく、これらの制限は他の人によって解決される可能性があります。
これは実際にはポートではなく、dev_appserverの修正版です。 –
WHIFFリソースを使用することで、最近、バニラのUnixからApp Engineへの逆移行が非常に簡単になりました。プラットフォームに依存するものはすべて基本的にリソースとして構成し、異なる構成のリソースを交換/交換します。
http://piopio.appspot.com/W1000_1000.resources
、リソーススワッピング/構成の詳細、例えば
http://aaron.oirt.rutgers.edu/myapp/docs/W1100_1200.wwiki
参照。 （注：リンクは最終的に消えるかもしれませんが、アプリは実験的です）
チェックアウトtyphoonaeベータ版ではありますが、かなり使い勝手が良さそうです。私たちのアプリケーションの1つをこのスタックを実行する社内サーバーに移しました。
AppScaleは、Google App Engineの最も成熟したオープンソース実装です。 2008年以来開発中で、現在Python、Java、Go、PHPの4つの言語すべてをサポートしています。現在、ユーザーは本番環境でアプリケーションを実行しています。
よくある質問は、APIがサポートされているかを説明し、何が欠けている： https://github.com/AppScale/appscale/wiki/FAQs
（免責事項：私はこのプロジェクトに取り組む）
私は自分のサーバー上にSDKをインストールし、いくつかの男について、一度読んで覚えていると、 GAEアプリケーションを提供するために使用されました。私はそのページを覚えていないし、とにかくそれはちょっとした実験だった。 –