2009年にGoogle App Engineに出会ったときは、一目惚れした。その約束はこうだった: 誰もがどこにいても24/7可利用なWebアプリケーションを、サーバの構成やデータベースのセットアップ、OSのバージョニング、セキュリティのパッチ、ロードバランシング、スケーリングなどをいっさい気にすることなく作れる。なんとそれは、スケーリングの自動化という約束だった。デベロッパはコードを書くだけで、あとはすべて、App Engineがやってくれるのだ。
2009年の時点ですでに、2015年ごろにはWebのコードの大半が同様のプラットホーム上で動くと思われていた。サーバの構成やオペレーションで苦労したい人が、どこにいるだろうか？ シスアドミンたちは少なくとも、辛（つら）い苦役から開放されるのだ（そしてデベロッパになったり、プラットホーム提供企業に雇われたり、あるいはクビになったりする）。コードは書くけど、それがどこでどのように実行されるのかを気にする必要のない、時代がやってくるのだ。スケーリングのことも、気にしない。サーバの一連の操作手順も覚える必要がない。実装詳細から解放されたデベロッパには、自由で明るい未来が待っている。はずだった。
そんなうまい話にならなかったのは、なぜだろう？
それは、”write once, run anywhere（日本語）”のような空約束ではなかった。App Engineは実際にその約束を守ったし、今でも守っている（最近はさらに便利になってるから、今でも個人的なプロジェクトにはApp Engineを使っている）。たしかに、正しく使うためにはドキュメンテーションを細部までしっかり読まないといけないし、インデクスや共有カウンタの爆発的な増大があり、またときどき、原因不明のメモリリークや待ち時間がある。それでも、Googleにいる友だちはかつてこう言った: “App Engineは素晴らしいよ。どれだけユーザが増えても、遅さはどのユーザも一定だから”。
今ではPaaS(platform-as-a-service)の選手たちも増えた。あの、ダムターミナルならぬダム仮想サーバのプロバイダ、と誰もが思っているAmazonでさえ、Elastic BeanstalkでPaaSを提供している。仕事ではよくHerokuを使うが、ご存知のようにこれもかなりすばらしい。非同期タスクや自動ロードバランシングではApp Engineの方が上だが、gitからのデプロイやPostgreSQLデータベース、そして独自の（よそで相当品が見つからない）APIを山のようにたくさん提供していないところも良い。APIは、Googleのが断然よろしい場合が多い。こうやってHerokuと比較すると、Googleのプラットホームの長短もだいたい分かるだろう。
でも、そのGoogleでさえ、今では2009年ほどPaaSという概念に惚れ込んでいないようだ。2012年には、App Engineの成功に満足しなかったらしいGoogleはGoogle Compute Engine、すなわちAmazon Web Servicesに直接対抗するサービスを立ち上げた。どちらも契約やプロビジョニングを自分でやらなければならないサービスに比べると断然便利だが、しかしそれでも、かなり退化したプロダクトと感じられる。PaaSに比べると開発の容易さや柔軟性、それに開発に要する時間の面で、後退している。一体、何がいけなかったのか？ なぜ、PaaSは世界を征服できなかったのか？
成果は十分にあった。有名なのでは、SnapchatがApp Engineで動いている。Khan Academyもそうだ。GeniusやProduct HuntはHerokuで動いている。この二つのPaaSを利用しているスタートアップや著名企業はとても多い。でも、PaaSの成功がもっと大きかったら、GoogleはCompute Engineに手を染めなかっただろう。PaaSがもっと広く普及していたら、Dockerがホットな話題になることもなかっただろう。PaaSがもっと完全でもっと広く利用されていたら、DevOpsがクローズアップされることも、なかっただろう。
今だにみんなが、AWSやCompute Engineのインスタンスをセットアップし動かすことに夢中なのは、なぜなのか？ なぜ、App EngineとHerokuとElastic Beanstalkは世界を征服しなかったのか？ 細かいレベル（低レベル）のコントロールが、本当にそれほど重要なのか？
ユーザの関心がPaaSからIaaS(仮想コンピューティングサービス)へ移行した理由は、三つあると思う。コストと、APIのロックイン（lock-in, 縛り付け, 封じ込め）と企業文化だ。
App Engineの料金は少しづつ下がり続けているが、でもまだ高いし料金体系が複雑だ。一つのインスタンス、ささやかな仮想マシンを一つ動かすだけで一日に1ドル以上かかるし、そのほかにストレージや帯域（ネット通信）の費用もある。Herokuでも、同じだ。コストパフォーマンスは、自分のサーバを自分で買って自分で動かす方がずっと良い。そうすると頭痛の材料は一挙に増えるし、開発時間も相当長くなるが、しかしそれでも後者を取る、という結論になってしまうのだ。
そして、ロックインという問題。アプリケーションをApp EngineのカスタムAPIをベースに作ったら、以後デベロッパはそれに縛られる。何か気に食わないことがあっても、別のプロバイダに簡単に移行することはできない。App EngineのロックインはそのほかのPaaSほどではないが、でも、あることはある。IaaSにはOpenStackやDockerのようなスタンダードがあるが、PaaSの世界にはない。PaaSのAPIが標準化される、という動きもこれまではなかった（後述）。
第三の、あまりぱっとしないけど実はいちばん頑固かもしれない理由が、企業文化だ。企業は、システムに対する、自分の手中にあるコントロールを、手放そうとしない。複雑な業務に無意味な費用がかかるし、シスアドミンの成長の妨げにもなる。にもかかわらず、コントロールを自分の手元に置きたいのだ。
PaaSが不振になった以上三つの理由は、しかし、どれも一時的だ。コストは、下がり続けている。企業文化は、変化していく。しかも、ゆっくりとではあるが、PaaSサービスの互換性とスタンダードを目指す動きもある（Dockerがその方向に向かう一歩だ、と言ってもよいかもしれない）。
電力も、初期の時代にはすべての工場に発電機があった。それが、最終的にはグリッド（公共配電網）へ移行した。IaaSを電力の利用にたとえるなら、個々の企業が電力をグリッドから取っているが、必要な変圧や三相から単相への変換などは自分でやっているのに似ている。これからは、もっと大きなPaaSの世界がやってくるのではないか、という気もする。単純にサーバのコードが動き続けるだけで、デベロッパはそのサーバの存在すら気にすることがない、という世界。すでにその方向の動きは始まっているが、まだ遅いだけかもしれない。
〔訳注: おひまな方には原文のコメントを読むことをおすすめします。いろんな議論があり、勉強になります。〕
[原文へ]
（翻訳：iwatani(a.k.a. hiwa）
