News

従来型のアプリケーションと同等のレベルに近づいているAs-a-Service

作者 Steven Robbins, 翻訳者 James Neoman 投稿日 2008年3月17日午後12時57分

コミュニティ: SOA,; Architecture
トピック: SaaS
タグ: Vendors,; 商用要件,; Enterprisey,; Salesforce.com

Phil Wainewright氏は、SaaSアプリケーションが、ブラウザレベルを越えて、デスクトップ・アプリケーションレベルのサービスを提供するようなクライアントの概念を提起した(source)。アプリケーションがSaaSアプリケーションである所以は、Webから管理、制御できることだというのはまだ変わっていない。業界の有名どころであるAdobe社はAIR(source)で、Microsoft社はSilverlight(source)で、この概念を取り込んた。

しかし、ブラウザの以外のSaaSでは、こういった大きなプレーヤーの独壇場というわけでもない。Philは以下のように述べている。

つい先日2008年の製品リリースを行った(source)オンデマンドCRMベンダであるRightNow Technologies社が、この種のクライアントを最初に開発したベンダの1つだそうです。その製品は、従来、Windowsベースのクライアント・サーバ・アプリケーション以外では実現されていなかったような機能を、Microsoft社の.NETフレームワークを使ってクライアント側で実現しています。

これによって、RightNow Technologies社は、より多くの機能を「as-a-service」形態で提供するというトレンドに乗ったベンダやクライアントの一群に加った。Rackspaceの子会社であるMosso(source)のようなベンダがcloud computingスペースで別の形で提供を初め始めた一方で、CogHead社のCTOであるGreg Olsen氏は、サービスとしての基盤(IaaS)(source)を推し進めている。CohesiveFT社は、最近Elastic Server On-Demandという製品(source)を発表した。CohesiveFT社は自社の製品によって、以下のようなSaaSプラットホームを提供すると主張している。

仮想化されたアプリケーション・スタックを、ISVコンポーネント、オープン・ソース・ソフトウェアコンポーネントや顧客の独自のコードを取り込んだコンポーネント・ライブラリからオンデマンドかつダイナミックに構築することを可能にするSaaSプラットホームです。

そのスタックは、構築した後で、Amazon社のEC2を含む主要な仮想化フォーマットのどれにでも、配備することができるはずである。
SaaSアプリケーション配布企業の一社であるOpSource社は、2004年にまず自分たちのas-a-Service製品であるOpSource On-Demandをリリースした。2008年2月25日には、OpSource社はAVOLENT社のペーパーレス課金と決済ソリューション(source)をオンデマンド提供形態に移行したと発表した。この移行によって、AVOLENT社は大規模な基盤を自社で所有することなく、SaaSアプリケーションを提供することが可能になった。

これらのオンデマンドのアプリケーションを利用することで、顧客は、複数の売掛金勘定システムに支払いを照合するのと同じように、複数の課金システムからの請求を一種類の請求書に統合することができるようになります。AVOLENT社のソフトウェアとOpSource社のSaaS基盤を組み合わせることによって、顧客は、最高パフォーマンスと信頼性を備えながら、何千もの同時のユーザーによる一日当たり何百万ものトランザクションを処理することが可能になります。

Bungee LabsのAlex Barnett氏とDave Mitchell氏は、最近サービスとしてのプラットホーム（PaaS）(source) を定義しようとした。Barnett氏とMitchell氏は、自分たちがPaaSを定義するのに必要だと感じる6つの条件をリストにした。

同じ総合環境の上での開発、テスト、展開、ホスト、保守が可能なこと
妥協のない使用体験を提供できること
スケーラビリティ、信頼性、セキュリティが初めから組み込まれていること
ウェブサービスとデータベースが初めから組み込まれていること
コラボレーションの支援があること
アプリケーションの詳細な動作確認が可能なこと

Mitchell氏は、リストの一番始めの条件を以下のように説明している。

開発と実行を異なった場所で行うのを止める時だということです。今日、殆どのアプリケーションはある環境、通常は、開発者によってそのプロジェクトのために特別に用意された環境でコーディングされ、テスト用に準備された別の環境でテストされ、さらに製造のための別の環境に移されます。こういった別々の環境を構築、構成、保守するためにコストがかかるのに加えて、殆どのアプリケーションは、たいていソフトウェアライフサイクルを進む中でぶつかる障害を克服するために変更や書き直しが必要で、それには、もっとコストがかかります。従来の業務モデルでは、こういったコストと付随するリスクはアプリケーションのオーナーに降りかかりますが、これらは、ウェブ・スケール・アプリケーションを展開するためのコストの一部と考えられています。完全に実現されたPaaSにおいては、全てのソフトウェアライフサイクルは、同じコンピューティング環境で支えられます。これが、開発や保守、市場にアプリケーションを出すまでの時間やプロジェクト・リスクのコストを激減させます。PaaSは、開発者が、自分たちが作ったアプリケーションをテストしたり、チューニングしたり、デバッグしたりするのはもちろんのこと、実行するだけのために、環境を構築したり、構成を調整したりすることに時間を費やすのではなく、すばらしいソフトウェアを作るためにこそ自分たちの時間を使えるようにするものでなければなりません。

サービス提供例としてSalesforce.com社とForce.comプラットホーム(サイト・英語)の話をすることなく「as-a-Service」に関する議論を終えることはできない。Salesforce.com社は、Walt Disney社と日本郵政公社との最近の取引(source)を通して、PaaS普及を加速している。eWeekのRenee Boucher Ferguson氏は、以下のように述べている。

日本郵政公社は、おそらく現時点ではSalesforce.com社の最も有名なForce.com顧客事例でしょう。日本最大の投資情報サービス機関であると同時に、国の郵便サービス提供機関である日本郵政公社は、政府所有の機関から私企業へと移行しつつあります。日本郵政公社は、Force.comを、その巨大な顧客ベースに金融商品を販売するのを支援する数多くのアプリケーションを構築して、配備するために使っています。日本郵政公社事例でのキーポイント: 日本郵政公社は、Salesforce.com社のCRMアプリケーションを使用していません。同様に、Walt Disney社は自社製のアプリケーションを構築するためにForce.comを使っています。この取引では、Salesforce社はMicrosoft社の.Net開発スタックに対して勝利を収めました。

より多くのベンダがas-a-Serviceスペースに参入すればするほど、より多くの革新が生まれ、顧客が選ばなければならないオプションは増加し続ける。Wainewright氏は、デスクトップ・クライアント・モデルについて要約してくれた。

私は、今後このモデルでクライアントを配布するSaaSベンダが増えると考えています。特に複雑なエンタープライズ・アプリケーションの配布でそれは顕著となるでしょう。SaaSベンダは、彼らが取って代わるつもりである業務用のクライアント・サーバ・アプリケーションと同じくらいあらゆる点で洗練されていることを示そうとしています。ネットワーク・アプリケーションは、ネットワークの中央になければならないと考えている人もいるようですが、私は、サービスを提供するコードが、集中的に管理されてはいるが、クライアントで実行されるようなものも、ネットワーク・アプリケーションと呼ぼうと思います。

原文はこちらです：http://www.infoq.com/news/2008/03/as-a-service-gains-acceptance