| 観点 | Amazon EC2 | Google App Engine |
| 実行環境のバリエーション | 豊富(Linux、Windows、OpenSolaris...) で、利用者の馴染んでいる環境を選んで使える | Python限定 |
| OSイメージのメンテが必要。単なるバージョンアップから、セキュリティホール対応まできちんと対応する必要がある (今でもかなりの数のイメージが乱立しているが、これからどのように制御して行くのだろう。ユーザ任せ?) | 単一実行環境なので、バージョンアップやセキュリティ対策の見通しはよく、メンテナンスコストは集中化できると思われる | |
| OSイメージのコスト | OSイメージのコストは掛からない | |
| 実行環境の能力 | 低レベルのサービス(ファイルIOなど)を使える。何でもあり。 | 高レベルAPIに限られる。自由度低い |
| 仮想化環境の上、OS毎の特性も異なると思われるので、安定化や特に性能面のSLA制御は大変だろうと思われる | 挙動のバリエーションが限られるので見通しはよく、安定化させやすい。性能見積もりなども究極的には楽になるはず | |
| 実行環境モデル | バッチ処理や計算処理など、Webサービス以外にも使える | Webサービスに特化 |
| OSが生で見えていて判りやすい分、どうしても単一ノードに特化したサービス実装になりがち。単一ノード以上にスケールアウトさせるには道具立て(Hadoopなど)が必要。 | フレームワークに則って作れば（究極的には）スケールしやすい。逆に言うとスケールしやすいものしか作れない | |
| 性能についても（有償で課金しているから良いようなものの）制御しづらい | 負荷プランニングし易い | |
| 移行 | 他のホスティングサービスからの乗り換えが容易 | APをほぼ新規に書き起こすことが前提。 特に、ISV/LAMPなどに依存する場合には、直接的な移行は難しい。 |
| アプリケーション | 一般的なISV(Oracleとか)を使える | 性質上、一般的なOS上のISVは動作しない |
| ISVメンテが必要。OSイメージとの組み合わせ爆発が起きないか？ | メンテナンスは不要 |
結局のところ、
- Amazon EC2 はユーザの利便性を気にしている。使ってもらってナンボ。
- Google App Engineは、システムのシンプルさや既存システムとの整合性・流用性に重点を置いている。ユーザの利便性ははっきり言って二の次、三の次。
もうちょっと言うと（AmazonとGoogleのスタンス、ビジネスモデルの違いを考えれば当たり前ですが）、
- Amazon EC2は近々の利益を考えている
端的にはマシンパワーを売るビジネスモデルで、客への訴求性の代償として管理コストを支払っている
- Google App Engineはそれ自身で利益を上げるつもりが（あまり）ない
余ったマシンタイムで面白いサービスが出てきて、結果的に広告露出が増えればよいと割り切っていて、マシンパワーを売ろうとは思っていない。なので投資（管理コスト）も少なめで、ユーザ数に比例しない範囲に留めたい。今後出来るという有償サービスも多分おまけのサービスでしょう。
ここで、両陣営の大きな違いになるのが、管理コストの問題じゃないかと思います。EC2は便利で敷居が低く移行しやすい作りですが、それが先々システムの複雑さや見通しの悪さの原因となるような気がしています。うまいこと押さえ込めればいいのですが、この手の話はすぐに増殖するので、行きはよいよい帰りは怖いということになり兼ねません。
また、EC2上で稼動するOS/ISVインスタンス（FedoraやCentOSはともかく、WindowsやOracle）に対して、ベンダーがどのくらいの値札を付けてくるのかも気になります（Windows EC2については未発表のようですが）。ベンダは、立場上あんまり安売りもできない（パッケージが売れなくなっちゃう）けれども、あんまりご無体な値札も付けられないので、何かと引き換えで値引きとか、ぎりぎりのところで色々交渉が行われているものと推測します。駆け引きの結果、EC2の費用構造がどのあたりに落ち着くのかは、大変興味深いところでしょう。
マイクロソフトのスティーブ・バルマーが「皆GAEは良いというけど、実際に使っている人は見たことがない」と言ったそうですが、上のような意味では、Googleとしては「ウチは程々に使ってもらえればいいんだよ」なのかもしれません（まったく見向きもされないのも困るでしょうけど）
何となくの予感として、Amazonモデルは持続的技術、GAEは破壊的技術だというのはGoogleに贔屓し過ぎかな。
0 件のコメント:
コメントを投稿