Googleドキュメント使用時に、実装に使用しているミドルウェアコンポーネントはわかりません。Googleドキュメントは、BigTable上に構築されているのかもしれませんが、製品ユーザーとして、製品に使用している全てのミドルウェアの実装の詳細を知る必要はありません。スプレッドシートの背後で計算実行時に使用しているOSのようなインフラも気にしていません。これらの詳細も、IT組織がGoogleドキュメントをオフィスツールソリューションとして導入を選択する上で気にする必要はありません。つまり、IT組織の観点からすれば、重要なのはアプリケーションの機能が自社のエンドユーザに確実に提供されることなのです。これは実際のところ、ITへのパブリックSaaSをITに提案する上での中核となる価値です。基盤となるミドルウェアやインフラの所有および維持に関わる心配事を完全にIT組織からSaaSプロバイダへシフトします。下の図は、このITデリバリーモデルを示しています。
[注意］
このエントリの図は、XaaSの灰色スペースにあるものはIT部門で利用でき、XaaSプロバイダにシフトされたメンテナンスの負担はないというふうにお考え下さい。
このような理解を念頭に置き、Platform as a Service（PaaS）ソリューションにとって同等のシナリオを検討することは価値があります。企業にPaaSソリューションを導入する場合、IT組織のメリットがぴったり一致している必要があります。基盤となるミドルウェアやインフラの所有および維持に関わる関心事を、完全にIT組織からPaaSのプロバイダーにシフトする必要があります。SaaSの観点からみた唯一の相違点は、PaaS環境にカスタムアプリケーションを作成し、デプロイできることです。こうしたカスタムアプリケーションは、強化し、SaaSが提供するアプリケーションを強化・補完することでしょう。開発の観点からすると、これらのカスタムアプリケーションの開発者は、ミドルウェアテクノロジーやコンセプト（Webアプリ、Webサービス、メッセージングなど）を使って優れたアプリケーションを開発することができるはずですが、同様に、こうしたミドルウェアテクノロジーを維持管理するという心配事から解放される必要があります。これが、PaaSの構成要素の基準と考えています。以下の図で、PaaSがInfrastracture as a Service (IaaS) やSaaSソリューションに比べてどこにフィットするかを説明します。
Java Cloud Service（Oracle Public CloudのPaaSサービスの一部）をお客様にご案内してきたのですが、Java Cloud Serviceが次のような環境と期待されていることがわかってきました。管理者がマシンインスタンスをプロビジョニング（CPUやメモリの使用率、ファイルストレージのプロパティなど）が可能で、Fusion Middleware製品（WebLogic Server、Oracle Web Services Manager、ADFなど）がプリインストールされている環境である、と。この考えを基にした絵は以下のようになります。
Java Cloud Service
http://cloud.oracle.com/mycloud/f?p=service:java:0
Oracle Public Cloud
http://cloud.oracle.com/mycloud/f?p=service:home:0:::::
事実上、このモデルでは、Infrastructure as a Service (IaaS)層を使って、従来の方法でミドルウェアをホストし管理します。基盤となるインフラの所有および維持に関する心配が、IT組織からSaaSプロバイダーにシフトされている点で、確かにこのモデルにはメリットがあります。これは、IT組織がもはやマシンのハードウェアスペースやOSのパッチやアップデートを心配する必要がないことを意味します。しかし基盤となるミドルウェアの所有および維持に関する心配は何も変化せず、ミドルウェアがオンプレミスの、非IaaSのインフラストラクチャで実行されている場合とまったく同じままであることがわかります。 IT組織は未だにパッケージ化されたミドルウェアコンポーネントを購入し、熟練の管理者たちにインストールさせ、保守させる必要があります。したがって、このモデルは私の見解ではPaaSではなく、正確には、IaaS上のミドルウェアとして特徴づけることができます。
IaaS上のミドルウェアというモデルは今日、アプリケーション管理者により多くの柔軟性を提供します。管理者は完全なミドルウェアランタイム環境とそのインフラのノブを完全に制御できます。しかし、PaaSモデルの美しさは、こうしたパラメータの制御を完全に不要にすることを約束しているところです。究極のPaaSソリューションは、アプリケーションに最適なランタイム環境を自動的に推論し、自動的にアプリケーションのニーズや利用方法が進化するのに合わせて調整できます。具体例をあげるとすれば、PaaSのソリューションを用いるとアプリケーションサーバのクラスタリングプロトコルでマルチキャストまたはユニキャストのどちらを使用するか、とか、アプリケーション用に作成されているはずの正確なJMSの送り先がどこに向いているか、といったことは心配する必要はありません。その代わり、PaaSのソリューションが自動的にこれらの詳細を把握し、単独でQoSポリシーに基づいて信頼性の高い方法でアプリケーションを利用できるようになります（例えば、このアプリケーションは他のアプリケーションよりも重要である、とか、このアプリケーションに対するリクエストが完了するまでに1秒を超えてはいけない、とか）。
アプリケーション向けのPaaSの世界で、このようなソリューションが当然ながら一晩で実体化することはありません。しかし、PaaSが提供する機能が成熟し、このビジョンにリアリティが出てきて、ますます複雑で多様な種類のアプリケーションに対応することを期待しています。こうした進化により、企業はIaaS上のミドルウェアといった類のクラウドソリューションから、PaaSソリューションに移行することができるのです。あなたがこの記述からその論理的結論へ到達するばらば、以下の図は将来の企業IT部門を表現していることになります。
純粋にPaaSやSaaSを提供するIT部門に徐々に移行すると、ITの世界は結果として段階的にシンプルかつ費用対効果が高くなります。ミドルウェアやインフラ全体を所有し管理するという負担を、PaaS/ SaaSのプロバイダーにシフトすることで、IT部門は本来のコア業務、つまりビジネスアプリケーションのタイムリーな配信に集中できるためです。Oracleは、Oracle Public Cloudで、この目的に向かって大きな飛躍を可能にするソリューションをお届けします。
原文はこちら。
http://blogs.oracle.com/rezashafii/entry/paas_is_not_middleware_over
0 件のコメント:
コメントを投稿