MBaaS定義に関する整理

クラウドとは何か?IaaS/PaaS/SaaSとは何か?

atoll projectでは2013/4にOCDETと連名で事業継続性と運用弾力性に配慮したクラウドリファレンスアーキテクチャV1.0を公開しています。本リファレンスアーキテクチャでは広く標準として認知されているNISTによるクラウド定義を狭義のクラウド定義として基軸に据え、atoll projectも付属のクラウドセキュリティガイドライン活用ガイド(案)策定に参加した、経済産業省クラウドサービスの利用のための情報セキュリティマネジメントガイドライン改訂版(案)や、ENISAクラウドコンピューティン情報セキュリティに関わる利点、リスクおよび推奨事項(リンクはIPAによる和訳)の採用する広義のクラウド定義を参考に、最小限のクラウド定義として2.2において


"共有化されたコンピュータリソース(サーバ,ストレージ,アプリケーション等)について,利用者の要求に応じて適宜・適切に配分し,ネットワークを通じて提供することを可能とし相互運用性と可搬性が担保されている情報処理形態。"

との定義を採用しています。 続く2.3においてレイヤー分解した定義を行っていますが、その考え方はリファレンスアーキテクチャと同時に公開した事業継続性と運用弾力性に配慮したクラウドリファレンスアーキテクチャチュートリアルV1.0で解説している通り、相互運用性と可搬性を確保するためのインターフェース標準の確立であり、広く利用されているインターフェース標準であるOSI参照モデルにクラウドサービスの階層構造を引き当てた整理に基づいてます。

NIST定義に基づいて考えるとサービス層においてIaaS、PaaS、SaaSは入れ子構造になってしまいます。



チュートリアルに収録した解説文を再掲すると、

"IssSは、オンデマンドセルフサービスを実現するダッシュボードやAPIをアプリケーョン層にあたるSaaSとして装備している必要があることになり、ダッシュボードやAPIを動作させるアプリケーションプラットフォームをサービス層にあたるPaaSとして装備している必要がある"
この問題を回避するためにatoll/OCDETモデルではIaaS/PaaS/SaaSの識別をOSI参照モデルに準じたインターフェース界面として取り扱い、個々のサービスにおける入れ子構造がアーキテクチャデザイン上の問題を引き起こさないように整理しています。



MBaaSとは何か?

昨今話題となっているMobile Backend as a Service=MBaaSの初出をたどると2009のForrester Research Holger Kisker氏のBlog Postにたどり着きます。この記事で同氏は、Collaboration untaps the full Cloud potential(コラボレーションがクラウドのポテンシャルを引き出す)として、Salesforce.comのサービス構造を念頭に、

Business Process-as-a-Service (BaaS) 
Knowledge-as-a-Service (KaaS) 
Software-as-a-Service (SaaS) 
Platform-as-a-Service (PaaS) 
Infrastructure-as-a-Service (IaaS)

というレイヤー分解を提案しています。しかし、IaaS/PaaS/SaaSのレイヤー分解は本質的にユースケースやアクター構成に対して中立ですからNIST定義拡張の方向性としては筋が良いとは言いにくい部分があります。実際、この分類は現在では忘れられてしまっているといってよいでしょう。

今日的な意味でのBaaS/MBaaSの初出は調査の及ぶ限りではReadWireのDan Rowinski氏による2011夏のParese紹介記事

Parse Offers "Backend as a Service" to Mobile Developers

と銘打ったものが挙げられます。冬に入って同氏がPareseが$5.5Millionの調達に成功したとのフォロー記事を公開したところで注目されはじめ、翌2012の初めにAppceleratorによるCocoafish買収と話題が続いたところに2012春のForrester ResearchのMichael Facemire氏(2009とは別のアナリストである点に留意の事)が類似するサービスを提供している各社の共通点を整理してMBaaSの定義を試み、


A cloud-based storage facility for your data.
Automatic RESTful API generation providing read/write access to that data.
Over-the-wire-optimized ways to access this data (generally JSON today).
User management facilities for authenticating access to your data.

クラウドベースのストレージを備え
RESTful API生成でき
JSONなどによるデータアクセス最適化を実装し
ユーザー管理機能を持ち、
ユーザーの利用分析機能が提供されている

と整理して議論の土台が形作られました。ただし、Michael Facemire氏による定義でもMBaaSはIaaS/PaaSの上に構築される独立した層であるとされていてアーキテクチャ的に筋がよくありません。

とはいえ、2009とちがって2012の場合は前年末にPareseが$5.5Mの調達に成功し、Cocoafishがエグジットに成功ていた点から市場が動く理由があるタイミングであり、秋にM&MがBackend as a Service (BaaS) Market worth $7.7 Billion by 2017(BaaS市場は2017に$7.7B=7700億円規模となる)という予測が公開されるに至ってMBaaSはBuzz Wordとして浮上しています。

本質的にMBaaSはモバイルアプリケーション事業者にとって必須のビジネスコンポーネントスイートであってクラウドのレイヤーモデルに従って表現するならPaaSに過ぎません。MBaaSというBuzz Wordが流行した原因は、かつて日本で見られたi-Modeに代表される移動体通信事業者の提供する公式コンテンツプラットフォーム上でサービスされたいわゆる公式コンテンツ事業者がコンテンツ開発単価低減を狙って各々構築(のちに外販も)していたコンテンツ配信プラットフォームの延長線上に位置づけられるべきものです。

また、クラウドエコシステムの観点からはPayPalなどの決済プラットフォーム事業者やSalesforceなどのCRMソリューション事業者、IaaS/PaaS事業者などの提供するサービスの相互接続が容易になると成長機会を失うリスクを抱えた業態と表現することもできます。

MBaaS事業者が長期的に成功するためには通信事業者やIaaS/PaaS事業者、決済事業者に対して中立で機能(収益性)的にも競争力のあるなビジネスコンポーネントスイートをモバイルアプリケーション/コンテンツ事業者に迅速に供給し続け、ウィンドウが閉じる前に規模の経済を確立する必要があるでしょう。(当たり前の結論で申し訳ない)
Load disqus comments

0 コメント