让我来列举一下个人认为最强大的PaaS平台——Google App Engine的优点
2019.12.27追記
この記事は4年前に書いたものをメンテしていて、これまでたくさん読まれたようですが、平成時代のものだと思えてきました。最近、アプリのバックエンドに使い始めたFirebaseのほうが今の時代にあったPaaSだと思います。Google App Engineは2nd generationからはIaaSよりになっていると思うので、高速に開発することを求めるPaaSならFirebaseでしょうということで、この記事は飛ばしてFirebaseの紹介記事を適宜探してお読みください。
在云计算的早期，Google App Engine（GAE）曾经有一定的存在感。但随着PaaS不受欢迎，以及IaaS时代的全面到来（以Amazon Web Services为代表），GAE的影响力已经大大减弱。
当のGoogle自体も明らかにIaaSサービスのComputeEngine（GCE）に力を入れているようです。日本のGAEユーザーが熱望したアジアデータセンターはGCEにはあっさり来たのに、GAEには来ないままです。ちなみに最近、GAEに新しいデータセンターが追加されたと思ったら、米東南部のサウスカロライナ州でした。
GAE大好き人間としては、改めてGAEの良さを知ってもらい、再びGAE熱を高めていきたい。そしてGAEアジアデータセンター開設の追い風とすべく、GAEの良さを熱く語ってみたい(台湾、東京とアジアのデータセンターは来ました)。ちなみにHerokuとかParseとか、Firebaseとか他のPaaSは使ったことないので、比較はできません。AWSを使っている観点からになります。
顺便说一下，GAE有两种类型，即标准版和灵活版，但在这里我们只涉及标准版。此外，标准版有两种形式，即基于第一代和基于gVisor的第二代。在这里，我们主要讨论第一代。
云原生平台即服务（PaaS）的发展再次加速
IBM、Microsoft和Oracle努力奋斗 – 供应商锁定
AWS努力推出各种PaaS – 太棒了！太厉害了！
这是怎么回事？
#IT业界中的七个奇迹 – 秋山泉（@iakiyama）2015年10月9日
こんなツイートがありましたが、AWSはマネージド・サービス=PaaS的サービスをどんどん投入してきてますね。IaaSは既存システムとの互換性が高いものの、IaaSばかりでシステムを組んでも、クラウドの良さは活かせません。コスト面からも見ても、障害対策等のインフラ運用面から見てもPaaSをうまく活用したほうが、効果的です。
ちなみにロックインの指摘はよくありますが、結局開発体制次第のような気はしますね。内製開発で、内部構造を常に変えていけるような体制なら、心配することはないと思います。外注しているような場合は、そもそもメーカーさん（SIerさん）に頼んだ時点でロックインなので、ロックインを気にしてもしょうがないかと思います。
注意点としては、GAEは1年前の廃止告知（Deprecated）で、機能・サービスの廃止をする可能性があります。ただ実際にはそんなにすぐに廃止するわけではなくて、例えばBlobstoreのFile APIではDeprecatedから廃止まで2年かけています。
GAE的优点
好的，接下来我会列举一些关于GAE的优点。
瞬间规模扩大
该图片摘自 https://speakerdeck.com/googlecloudjapan/deep-dive-into-google-cloud-technology。
仕事では、やむなくAWSを使っているのですが、ここが圧倒的に違いますね。Dockerのコンテナーがだいぶ流行ってきて、仕事でも使い始めましたが、Dockerが出てくる前からコンテナー技術を社内で使いまくってきたと言われているGoogle。GAEのコンテナーは、PythonやGo環境であれば、１秒足らずで増やすことができます。上記リンクの資料では40msecとなっていますね
秒間リクエストがピークとそれ以外で４倍以上差があるサービスの運用に使ったことがありますが、負荷があがってくるとコンテナーがさくさく増えて、負荷が下がるとまた戻ります。オンデマンドで、スケールアウト・スケールインするので、コスト効果はかなり高いです。
AWSもオートスケーリングの設定が可能ですが、仮想マシンを上げるので、１分とかそれぐらいはどうしてもスケールアウトにかかってしまいます。運用してたサービスでもありましたが、Twitterで急にバズってリクエストが突然増えたとしても、インスタンスがちゃんと増えて対応できます。
我认为，在接收来自普通用户的请求并且需要处理经常变动的部分时，使用它非常有效。
バージョン = 「Blue-Green」デプロイメント
画像は https://speakerdeck.com/naoya/korekarafalseweb-kuraudosisutemu より引用
「Blue-Green」デプロイメントって、かっこいいですよね。新しい環境をデプロイして、問題なければLBとかでごっそり入れ替える。それを特別な設定なしにできるようになっているのがGAEのすごいところです。
GAEの必須の設定ファイルに、versionという項目があって、そこを変更してデプロイすればいいだけです。違うバージョンでデプロイした場合には、すぐにそれが有効になるわけではなく、管理コンソールの画面もしくは、コマンドで切り替えができます。
例えば、下のような app.yaml の場合、デフォルトのアプリは myapp.appspot.com でアクセスできますが、新しいバージョンをつけたものは alpha-001.myapp.appspot.com のようなドメインでアクセスできます。
application: myapp
version: alpha-001
runtime: python27
api_version: 1
threadsafe: true
なので、新しいバージョンを付けてデプロイし、e2eテストとかでその動作を確認。その上でバージョンを切り替えれば、Blue-Greenデプロイメントのできあがりなのです。逆に、ロールバックもバージョンを戻すだけで一瞬でできます。
顺便一提，因为我自己没有使用过，所以无法确认是否推荐，但据说不仅可以完全切换，还可以根据指定比例将请求分配到不同版本，类似于A/B测试。
权限管理交给Google账户。
サイトやツールを作るときにログインや管理者機能を付けることがあると思うのですが、それをGAE上のアプリでGoogleアカウントでやる場合は、GAEの設定ファイルに書くだけですみます。
下はGAE/Goの場合の例ですが、この場合 /admin/ 配下のパスにはGCPプロジェクトの管理コンソールで指定した管理者以外の人はアクセスできません。あとはこのパスの配下にREST APIでも生やして、JSのクライアントを書けば簡単にCRUD機能を実装できて、しかも管理者以外は触れないようにできます。
- url: /admin/.*
script: _go_app
login: admin
secure: always
さっくり、ツールを作りたいようなときに便利です。login: required を設定しつつもそれをGSuiteのユーザーに限定することも可能です。
例えば、iOSのAppStoreのレビューをSlackに通知するツールを作る際に、Rest APIを用意して、そこのアクセス制御はGoogleアカウント連携に任せて楽をしてます。
https://github.com/yosukesuzuki/goisky-tools
CDN边缘缓存功能
こちらのエントリーに詳しく書いてあるので、割愛しますがCDNが簡単に利用できるってことですね。
http://qiita.com/sinmetal/items/37c105a098174fb6bf77
GAE的问题是延迟，但是如果能够有效利用边缘缓存，就可以减轻延迟问题。
前に某放送局の方の話を勉強会で聞きましたが、音楽番組のライブと連携するウェブアプリ（アプリ本体のJSやHTMLのほうで、データはGCEから配信だった気がする）の配信を、edge cacheを活用してやったところ、お小遣い程度の超低コストで配信できたと言ってました。
GAEでは1万ファイルまでであれば、静的ファイルをアップロードすることが可能です。例えば以下のリンク先でサンプルを作っていますが、HUGOでファイルを生成してedge cacheを使って高速でスケーラブルで低コストな静的ファイル配信サーバーとして使うということも可能です。AWSのS3の静的ファイルホスティングと同じようなことですね。
https://github.com/yosukesuzuki/hugo-gae
图像传输
GAEのBlobstoreもしくはGoogle Cloud Storageに入れた画像に対して、画像のリサイズや正方形の切り取りが簡単にできてかつGoogleの画像配信CDNから配信されるという機能が用意されています。
在Python的情况下，图像的URL。
from google.appengine.api.images import get_serving_url
image_url = get_serving_url(obj.blob_key.key()
可以通过以下方法获取到类似的URL。
如果在此URL后面加上长边图像尺寸=s320，它将返回调整大小后的图像。
例えば、スマホのクライアントは画面サイズや解像度がまちまちなので、クライアント側でサイズを決めて、適切なものを呼ぶといった使い方が可能です。
然而，需要注意的是，一旦使用此功能，图片将变为公开可见。
任务队列
AWS Lambda 现在支持 Python 了，这真是太棒了！但实际上，Google App Engine（GAE）早就具备了相同的功能。
TaskqueはAWSのSQSとLambdaが合体したようなやつで、キューに処理を放り込んでおけば、失敗した時のリトライも含めて勝手にやっておいてくれます。詳しくはないですが、Celeryみたいなやつだと思います。
数据存储
メンテナンスフリーのKVSとしては非常に優秀だと思います。かつクエリーできるKVSみたいな感じでしょうか。クエリーはそこまで早くはないですが、何百万件入っても速度の劣化はありません。
GAEは当初、Datastoreが障害になることが多かったようですが、High-Replicationというタイプが出てからは障害はほとんどありません。クエリーの遅さは、アクセスが多いようなところはMemcacheに予め放り込んでおくような対策もできます。
インフラ担当者がいらない ＝＝ 運用コストがほぼゼロ
何かシステムを作ろうと思った時に、インフラ、サーバーサイド、フロントとエンジニアが複数人必要になるパターンがありますが、GAEを使えばインフラエンジニアはいりません。スタートアップや小さいアプリ、当たるか当たらないかわからないようなサービスの立ち上げ時にはかなりいいと思います。アプリケーション領域に集中できます。
通常のインスタンスをAWSで立てると、たいてい何らかのメンテナンスは必要になってしまいます。例えばインスタンスの再起動が必要になるとか。そこについてPaaSのいいところというか、インフラまわりはまったく何もしなくていいです。ステートレスなアプリケーションしか作れないですし、ステートを持つためのDatastoreも全くメンテナンスがいりません。
很遗憾
延迟
※東京リージョンが使えるようになっていますので、こちらは米国リージョンを使うときの話になります。
GAEにはAppStatというプロファイリング機能が用意されていて、それも素敵なのですが、AppStatで見てサーバー側で20msecぐらいでレスポンス返したとしても、日本からだと行き帰りでどうしても200msecは乗ってしまいます。
如果能够使用手机应用程序或其他类似方式进行异步处理，我认为这将能够减轻压力，但与AWS 东京区域相比，这是一个明显的劣势。由于这些是应用程序和设计无法解决的问题，所以我们需要亚洲数据中心，尤其是在台湾等地，以降低延迟。
2016年4月3日补充
谷歌云平台（GCP）宣布将在东京设立数据中心。虽然我们不知道AppEngine具体何时将到来，但我们可以期待一下。
2016年11月1日添加
GCP东京地区的介绍已经出来了，连AppEngine也来了！！！没想到它们会同时出现。
Datastoreの互換性
Datastoreはメンテナンス不要で、特に細かい設定しなくてもモデル定義していけばすぐ使えるので、とても便利です。ただ、どうしても既存のフレームワークがそのまま動きません。PythonのDjangoならDjangaeというAppEngine実装があって、なかなか良さそうですが、そのままとは言えません。
既存のフレームワークをそのまま使えないと、アプリのポータビリティーの面からマイナスです。GAEに乗っかることでアプリケーションに集中できて生産性が高まりますが、一方で世の中にあるアプリケーションやフレームワークの資産がそのまま使えないのは生産性を下げてしまう部分もあります。
此外，其他的感想
Googleのクラウドは特殊なシステム
只需要一种选择：
在对比Google的云服务的BigQuery和Redshift时发现，AWS只是现有系统基础设施的替代，而Google的云服务则是针对特殊系统。Redshift是一个大型的PostgreSQL，在普通数据库操作方面表现得很好。虽然BigQuery存在不能执行DELETE和UPDATE的约束，但处理速度在任何SQL查询方面都相当快。
关于GAE的其他功能也有其独特之处。一旦完全适应了这些系统，它们反而非常方便。但可能正是因为在其他地方难以应用所以不太受欢迎。
是否要迁移到ManagedVMs（似乎不会）
总体来看，根据与相关人士的交流，AppEngine似乎并不打算停止使用，但也没有投入太多的精力。AppEngine似乎希望将容器迁移到ManagedVMs上运行。然而，这样做会降低容器的启动速度，这是一个遗憾的地方，希望AppEngine能够改进这一点。
※2016年12月18日更新
ManagedVMs已更名为Flexible Environment。我不确定是否真的想将其作为GAE的主力。以用户群体来看，我觉得更多的人会选择使用GKE而不是这个。
2018年7月31日补充：
ManagedVMs最终未能受到欢迎，并转向一种名为gVisor的新容器方案，同时计划支持新语言。据说，已经开始在gVisor上运行Java8和Node环境。
2018年12月28日新增
基于gVisor的App Engine被称为第二代。不再有类似于电池包含的感觉，取而代之的是几乎没有平台限制的可在平台上运行的库等。由于这款产品刚刚发布，尚不能完全评估其性能，不过看起来Google App Engine本身将朝第二代发展。
