[8月21日更新リスト]
Google App Engineでアプリケーションを構築することのすべての利点と欠点のリストを作成してください
長所:
短所:
既知の問題!!: http://code.google.com/p/googleappengine/issues/list
ハードリミット
開発者ごとのアプリ-10
リクエストごとの時間-30秒
アプリごとのファイル-3,000
HTTP応答サイズ-10 MB
データストアアイテムのサイズ-1 MB
アプリケーションコードサイズ-150 MB
更新 Blobストアで最大50MBのファイルを保存できるようになりました
ProまたはCon?
App Engineのインフラストラクチャにより、数百万件のヒットに対応するアプリケーションを構築する際のシステム管理と開発の課題の多くが解消されます。 Googleは、クラスターへのコードのデプロイ、監視、フェイルオーバー、および必要に応じてアプリケーションインスタンスの起動を処理します。
他のサービスではユーザーがほぼすべての* NIX互換ソフトウェアをインストールおよび構成できますが、App Engineでは、開発者はPythonまたはJavaをプログラミング言語および限定セットとして使用する必要があります現在のAPIでは、BigTable非リレーショナルデータベースからのデータの保存と取得、HTTPリクエストの作成、電子メールの送信、画像の操作、キャッシュが可能です。ほとんどの既存のWebアプリケーションは、リレーショナルデータベース。
長所:
短所:
深刻なビジネス向けではなく、長期的には高価なものだと思います。
(非常に新しい)PRO:GAEはMySQLをサポートするようになりました: https://developers.google.com/cloud-sql/ =
長所:
統合ログ用の組み込みUI
タスクキュー用の組み込みWebインターフェイス
プライマリオブジェクトのリストの組み込みインデックス。
短所:
緩いログは非常に高速
とても高い
とても高い
とても高い
ハッキング不可能。スケーリングする方法でコーディングする必要があるため、スケーリングします。
より長い開発サイクル。ときどき、何かを一緒にハックして、5時間後に破棄したいことがあります。 appengineでは、適切なコードを作成し、拡張性を確保するために多くのことを書く必要があります。 「find。| grep .avi | xargs ffmpeg -compress ....」を実行することはできません:)
プッシュ通知をAPNS(iPhone)に送信するなど、最も単純なタスクを実行しようとすると、時間はかかりません。ただし、将来的にAndroidのみをサポートする場合は問題ありません。
データベースのクリーンアップがひどい。データベースの行を修正するのは、主にひどく遅いため、非常に苦痛ですが、時間の制約内で適切にループするには多くのコードも必要です。
Luceneを「ファイルシステム」で動作するように移植するのは苦痛でした。
あなたが支払うものが遅い。
アプリにトラフィックの急増がある場合は、さらに高価です。多くのフォロワーを持つユーザーがアクションを実行し、フォロワーに通知をプッシュする必要がある場合、私のアプリにはこれらのスパイクがあります。そのため、スパイクを処理するには、10台の非アクティブなサーバーを常にオン($$$$$)に維持する必要があります。
Appengineは、スケーラビリティとボトルネックを修正してサーバーの使用量を削減する代わりに、$$$$を書き込むオプションがあるため、それほど悪くはありません。時にはそれだけの価値があります。
新製品を開始する人への私のアドバイスは、他の製品サーバーをホストしているhetzner.deを使用することです。安価で非常にハッキングが可能です。 hetznerには、appengineの製品の3倍以上のトラフィックを処理するサーバーが1つあります。価格の差は月額100ドル、バージョンは月額2700ドルです!
私はシステム管理者としての経験を持っているので、肝心なのは、自分のROOTサーバーを所有することよりもappengineを選択しないことです。優れた製品を構築するのではなく、新しいことを試したいという退屈なソフトウェアエンジニアにならないでください。
メリット:アプリケーションに対する無制限のスケーラビリティと、需要に応じた拡張性。
短所:一部の国(アルゼンチン)では利用できません。
世界中で利用可能ですが、App EngineのGoogleグループを通じてのみ利用できます。
GAEは、複雑な主キーを持つデータストア、Java.awt。*サポートなど、真剣なビジネスに基本的な機能を提供するという点でまだ成熟していないと思います。これらはほんの一部です。
空きスペースといくつかの「趣味」のWebサイトを構築するために、GAEはJavaの人たちが検討すべき場所ではないと強く感じています。
私は、JSP /サーブレットとMySQLでアプリケーションを構築し、GAEへの移行を考えていますが、いくつかのJavaホスティングからスペースを購入するよりも、移行に「価値のある時間」を費やすことになります。 EATJなどのプロバイダー(マーケティングではなくごめんなさい)。
もう1つの大きな問題は、既存のmySQLデータをGAEに移行することです。bulkuploadは本当に哀れで、クライアントをサポートしていません。
ローカルDBからサーバーDBへのアップロードはサポートされていません。
上記の「すべての短所」でGAEの準備ができたら、この移行を検討できると思います。
賛否両論を評価するとき、自分が代表する市場を明確にすることが重要だと思います。計画されているホッケースティックの成長曲線の急な部分を支援するための費用対効果の高いソリューションを探している開発者は、すでにリストされている短所を大きく評価します。ただし、中小企業の所有者にとって、GAEは神からの送信です。これらの人々はほとんどの場合、ビジネスをより効果的に実行する(つまり、物理的な製品やサービスを販売する)手段として「クラウド」に注目しています。 SMB、GAEの場合、すでにリストされているプロは、ホッケースティックを求めるデベロッパーと比べてはるかに価値がありますが、デベロッパーの測定値の短所は短所です。 GAEチームがSMBポジショニングに関連することを何もしていないので、このような答えはスーパーマンのマントを引っ張って風の中に吐き出すだけだと思います。 SMB space今。そうでない場合(ユーザーベースに関する洞察がない)、それは非常に嘆かわしい失敗です。
短所:すべての拠点は私たちのものです
...深刻な注意事項:
短所:アプリケーションを実行する環境を制御しません。コンポーネントのアウトソーシングと同じ短所があります。おもちゃではなく、ビジネスで(まだ)私見では楽しい。
API for Google proprietaryのようなさまざまなものは、データベースシステムや他の「ロックダウン」などのバックエンドや、コードが結び付けられていることを意味するフレームワークなど、多少なりともシステムにコストの問題を引き起こす可能性がありますGAEから移行します。もちろん、あなたはcouldこれらを抽象化できました。
GAE、AppJetなどが好きです。彼らはすごいかっこいいです。しかし、すべてにその場所があります。言語のモジュール、API、構文/ stdlibバージョンなどを自由に制御できるようにする場合は、サービスプロバイダーに制御を放棄しないでください。
標準の欠如は、アプリが期待できる環境と仕様のために、クラウドの分野で私を心配させます。
常識本当にもの。
あなたは携帯電話回線を所有することを強制されており、あなたの国+キャリアは国際SMSを受信できなければなりません。
(私は携帯電話が嫌いで、お母さんや同僚はSMSを受け取りません)
欠点:他のRDBMSまたはNoSQLデータベースは使用できません....