BaaS (Backend as a Service) について
正直またXaaSかよ、って感じでしょうが、SaaSとかPaaSとかに比べてまだそれほど流行ってはいないのかもしれないけど、スマフォがこれだけ普及してくると、それに特化した形態としてこのレイヤーでのサービスの切断もあり得る、ということらしいです。
モバイル向けの新クラウド、BaaS（Backend as a Service）とは何か。「Parse」が正式サービス開始 － Publickey
BaaSって何か新しいの？
取り組みとしては、2006年ごろの初期型PaaSや一部のDaaS (Database as a Service) にもアーキテクチャ的に似たのがあったような記憶があります。しかしながら、これらが理念先行型ニーズ模索中だったのに対し、今回のBaaSはすでにアピールするべき確固たる市場（＝スマフォアプリ開発者）があるのがやはり異なります。
ちなみに、この時代(2006-2008年)の中間レイヤのプラットフォームサービスは、UIを切り離して開発者のバックエンドDBに向くか、UIを統合してExcel的なエンドユーザ向けを目指すかで分けられましたが、どちらも茨の道の歴史で死屍累々で、前者はHTTP経由のデータベース以上の何者でもなく、開発者には結局MySQL自前で持つかホスティングで持つかのような話と比べられて、じゃあ慣れたMySQLでいいじゃん、と冷めた目で見られていたような気がしますし、後者は後者で、SaaSから発展したSalesforceなどに競合してもユーザに訴える飛び道具としてのアプリケーションもなく、結局CRMのおもちゃみたいなテンプレートをつけてみたはいいが、実際の業務に適用なんて作ってる当人も現実味を帯びて考えられないような代物だったりして、結局どちらもサービスの利用者を獲得できずに潰れたりどこかに吸収されたりしましたとさ。
まあとにかく、今度はUIは全部スマフォ側でやってくれと割り切れるので幸せです。あとはユーザ管理や認証があればほんとにサーバ側で何かしなきゃいけないなんてことはないので、クライアント側しか書けないアプリ開発者は楽ちんなものですね。
BaaSで何ができるの？
だいたいどのBaaSにも以下のような機能が提供されています。
その他に、スマフォ特化なところで、以下のようなものも揃っています
あとは、本番／開発切り替えとか、APIバージョン管理とか、アクセス解析とか、サービスによっていろいろあります。サーバでカスタムロジックのホスティングもできたりして、PaaSとの垣根の部分が若干低くなってるところもあるようです。
データストア
JSONデータストアはだいたいCouchDB/MongoDB的なドキュメントデータベースがRESTでアクセス可能になっていると想像すれば間違いはないとおもいます。コレクション（BaaSによってクラス、オブジェクトなどと呼び方が異なる）が同じタイプのレコードを管理する単位になり、そのスキーマ情報は自由にUIから定義でき、簡単なバリデーションが組み込まれます。MongoDB的に使うには十分でしょうが、その中でもStackMobなどはRelationshipのデータモデルをサポートしていたりしており、関連性を持ったコレクションデータをより簡単に扱えるようです。
じゃあこれらはMongoDBみたいなのにREST APIくっつけたの*1と全く同じなのか、というと、明確な違いが一つあって、それはユーザ管理とアクセスコントロールが組み込まれているということです。MongoDBにはMongoDBの接続アカウント＋パスワードを持った管理者orサーバプログラムしかアクセスできなかったですが、BaaSにはエンドユーザ管理とその認証およびレコードレベルのアクセスコントロールが組み込まれているので、直接インターネットに晒しても大丈夫です。適切にアクセスコントロールが設定されていれば、誰かが違う人の投稿を書き換えちゃうとか消しちゃうとかできないわけです。
なお、アクセスコントロールの実装というのは、サーバプログラマが一番間違えやすい所の一つではあります。現在のBaaSが達成できているのは非常にシンプルなコントロールですが、それらが全部宣言的にできるということは、かなりのメリットだと思います。特に、UI側の表示による制御のみに依存してサーバプログラム上でのチェックを怠っていたような脆弱なダメスマフォアプリであっても、ちゃんとしたレベルに平準化できるでしょう。
余談ですが、JSONEngineプロジェクトは似たようなところを目指していたように思います。BaaSというにはちょっとまだまだかもしれませんが、開発が止まっているように見えるのでちょっと残念ですね。
ユーザ管理とアクセスコントロール
データストアでアクセスコントロールをする以上、どのユーザがリクエストしているのか認証する必要がありますし、レコードの作成者（所有者）をはっきりさせておく必要もあるため、ユーザ管理の仕組みが組み込まれます。ユーザのアカウント情報は、他のデータストア内のレコードと同様ではありますが、ユーザ管理用の特別なコレクションにJSON形式で保存されます。
アクセスコントロールはレコードレベルで達成されるようになっています。BaaSのデータストア内にそのレコードを作成したアカウントの情報が紐付けられており、その作成者アカウントと現在認証されているユーザアカウントの関係性においてアクセスをコントロールするというものです。より具体的には、そのレコードが保存されているコレクションに対して「作成者のみ/ログイン済みユーザ/すべて（匿名含む）」が「読み／書き」権限を持っている、という表を設定しておくような形になります。BaaSの中にはより細かい条件で制御が可能なものもあるかと思います。
認証とソーシャル連携
認証については、通常のユーザアカウント名＋パスワードのようなものはもちろん、「ソーシャル連携」、つまり「Facebookでログイン」「Twitterでログイン」を簡単に実現してくれる機能が提供される場合が多いです。
残念ながら、現在のBaaSのほとんどが、この「Facebookでログイン」「Twitterでログイン」を正しく実装できていません。具体的に言うと、トークンリプレースという攻撃によって他人になりすますことが簡単にできてしまいます。回避するワークアラウンドはあるのですが、対処されていません。そもそもすべてのBaaSベンダーがこの問題を正しく認識しているかどうか微妙です。まだBaaSサービス自体が大きくないために被害例は出てないのでしょうが、これらが改善されるまでは主要BaaSの「ソーシャル連携」の機能については利用しないほうが良いのではないかと思います。
BaaSによってサーバエンジニアは必要なくなる？
僕はもともとサーバエンジニアのキャリアを積んでいましたが、ここ5-6年ほどはできるだけサーバプログラム書きたくないなーというメンタリティで過ごしてきました。それは単にスケールとか運用とかめんどくさいという理由なのですが、そういう点で、このBaaSについてはとても期待を持っています（ソーシャル連携のところだけが残念…）。そんなことくらいめんどくさがるな、という意見は重々承知ですが、怠惰はエンジニアの美徳ということですのでまあ許してください。
ともあれ、同じような人ってのはそれなりにいるはずで、クライアント専業のエンジニアはもちろんのこと、Webエンジニアでもサーバの運用に疲れてしまった人がPaaSに流れてきている現況をみてると、Webのサーバ側を書くのはもう流行んねーよ、くらいのことを言っても小声ならバチは当たらないんじゃないかなー、と思ってきています。
ただ、僕がエンジニアとして育ってきたころはなんだかんだやっぱりサーバを書かなきゃいけないことは多かったので、こうなってきたのは時代の流れなのでしょう。もちろんそういった「怠惰な」エンジニアがそのまま次の時代に生き残れるなどという保証はないのですが、その時にはむしろ次の先端に向かってクロールしていけるフットワークでいればいいんじゃないですかね。
とりあえず、IaaSがインフラエンジニアを不要にし、PaaSがアプリケーションサーバの運用を不要にしたように、BaaSはWebアプリケーションのサーバ側開発者を不要にします。実際に完全に世の中から不要にできるかどうかはさておき、そこを目指しています。サーバ側しか書けないアプリケーションエンジニアは青ざめていたらいいと思います（嘘）
追記
「ソーシャル連携」のところで触れた、トークンリプレース攻撃（トークン置き換え攻撃）が可能な場合とその対策方法について触れている記事へのリンク。
単なる OAuth 2.0 を認証に使うと、車が通れるほどのどでかいセキュリティー・ホールができる | @_Nat Zone
http://oauth.jp/post/43684110055/oauth-20-implicit-flow
http://oauth.jp/post/43684108710/ios-sdk
要は、FBのSDKとかでGETしたaccess tokenをそのままクライアントからサーバに投げて認証しちゃダメ、ってことなんですが、なんでだめなのかいまいちわかってもらえないケースが多いです。この記事はBaaSについてのものなので詳細は省きますが、興味があれば上記記事をじっくり読んでみてください。
*1:Sleepy.Mongooseとかもありましたね
