IaaSからPaaSへの発展はクラウドサービスにとって自然な流れだ。だが、そこに至る道は1つではない。1つ目の方法は、米Microsoftの「Microsoft Azure」が採用したもので、既存のデータセンターのプラットフォームをクラウドに複製するという手法だ。2つ目の方法は、米Pivotal Softwareの「Cloud Foundry」などのツールを使用するものだ。具体的には、ユーザーが選んだツールを使用して独自の「プラットフォーム」を作成して展開する。3つ目の方法は米Amazon Web Servicesの「Amazon Web Services」（AWS）が採用したもので、IaaSをWebサービスで補強して「プラットフォームサービス」モデルを作成するという手法だ。どの方法にもメリットはある。そのため、採用する方法を決めるときには、詳しい調査を行うことが重要になる。

1．Microsoft Azureと同じアプローチを採用する

　Microsoft Azureと同じ方法でPaaSを実現するには条件がある。それは、クラウドに移行するアプリケーションが、Windows Serverで実行されているか、実行できることだ。このアプローチの長所は現行のソフトウェア戦略との関連性が高く、クラウドサービスプロバイダーとオンプレミスソフトウェアプラットフォームのプロバイダーが同じという点だ。Windows Serverは簡単にMicrosoft Azureに進化させることが可能で、MicrosoftサーバとMicrosoft Azureは簡単に同期できるだろう。

　この方法には短所もある。データセンターのサーバプラットフォームが単一のOSで展開されている状況はごくまれだ。Microsoftを除き、このアプローチが実際に役立つプラットフォームを挙げるのは難しい。Microsoftは「Windows Server」のフレームワークをPaaSの分野で競合する可能性がある他社に公開することを拒んでいる。そのため、縛り付けられていると感じるMicrosoft Azureユーザーもいるだろう。また、Microsoftが今後どのようにMicrosoft Azureを変化させて、Windows Serverと関係のないクラウドにネイティブの機能を追加するのかは明らかになっていない。例えば、AWSで使用できるキャッシュサービスなどがある。

　このPaaSモデルの別の例として、Java仮想マシン（JVM）をベースにしたクラウドプラットフォームを紹介しよう。JVMは複数のアーキテクチャで実行できるポータブルプラットフォームだ。Amazonをはじめとするパブリッククラウドサービスプロバイダーは、ホスト型のJVMとJavaアプリを提供している。これらは、ほぼ全てのデータセンターやデスクトップPCで機能する。だが、このアプローチにも制限は存在する。それはクラウドでホストするアプリケーションがJavaで作成されている必要があることだ。そのため、多くのユーザーにとって、これは重大な制限事項となるだろう。

2．サードパーティー製ツールを使用してPaaSを構成する

　PaaSを実現する2つ目の方法は、1つ目の方法よりも汎用性が高い。Cloud Foundryや米Red Hatの「OpenShift」などのツールを使用すると、ユーザーが用意したIaaSにOSやミドルウェアのツールを追加して、クラウドプラットフォームを構築することができる。また、アプリケーションを実行するための信頼できるハードウェアとソフトウェアの組み合わせを選ぶことが可能だ。そのため、ユーザーとアプリケーションライフサイクルプロセスは、プラットフォームソフトウェアの保守作業を新たに学び直す必要がない。

　この方法の問題点は、誰がプラットフォームのイメージの構築と保守を担当するのかということにある。パブリッククラウドサービスプロバイダーが、構成ツールを使用してPaaSの基盤となるプラットフォームを構築することは可能だ。だが、このリスクをプロバイダーが負う可能性は低い。プロバイダーがプラットフォームのイメージを作成する場合は、ある賭けをすることになる。具体的には、有望な市場機会を生み出すのに十分な数のアプリで構築したプラットフォームに賭けることになる。また、構成ツールのアジリティを利用して複数のプラットフォームを作成するという方法論もある。だが、この場合は、各プラットフォームを最新の状態に保つための作業が必要になり、管理コストが高くなる。このような保守作業はクラウドユーザーに転嫁されることになるだろう。

　ユーザーが構成ツールを使用してプラットフォームを構築し、IaaS上で実行することも可能だ。だが、ユーザーがメリットを得るには条件がある。それは、ユーザーが構成ツールを使用して構成したミドルウェアやOSのコンポーネントがアプリケーションの展開に使用できることだ。OSやミドルウェアに変更が生じた場合には、所有している全てのマシンイメージを再作成する必要がある。構成ツールを使用する方法は、イメージを再作成する方法の代替として使用できる。実際、これが現在プラットフォーム構成ツールの最大の用途だ。ただし、特定プラットフォームのすき間市場を見ると、この方法がパブリックPaaSで幅広く採用されているかどうかは疑わしい。

3．プラットフォームサービスアプローチを採用する

　3つ目の方法はプラットフォームサービスだ。これはAWSで実際に採用されている方法である。プラットフォームサービスでは、PaaSの目的を次のように想定している。URLを通じてWebサービスを実行するアプリケーションに、クラウド専用のサービス／クラウド用に高度に最適化されたサービスを追加してサポートすることである。この方法は、オンプレミスから移行したアプリケーションではなく、クラウド用に変更または作成したアプリケーションを対象としている点がユニークだ。

　プラットフォームサービスは、将来に焦点を合わせているため、パブリッククラウドサービスのトレンドを後押ししている。構成ツールを使用して構築したプラットフォームと同様に、プラットフォームサービスモデルのプラットフォームは、高いアジリティを備えているが、それだけではない。新しいプラットフォームの要素を有益なクラウドアプリケーション機能と連携させることもできる。

　この方法にも欠点はある。OSやミドルウェアがホストされていないので、ユーザーが仮想マシンイメージの保守を行わなければならない。OSやミドルウェアを管理するためにCloud Foundryなどのプラットフォーム構成ツールを投入すれば、この問題に対応できるだろう。

　理論上、AWSなどのパブリッククラウドサービスプロバイダーは、多種多様なプラットフォームサービスを提供することができる。そのため、事実上クラウドOSを定義しているといえる。もし、これが現実のものになったら、オンプレミスプラットフォームのプロバイダーは新しいアプリケーションを利用するためにクラウドOSをサポートするという判断を下すかもしれない。だが、そのような判断を下すには、既存のプラットフォーム用のアプリケーションと同じ方法でクラウドOS用のアプリケーションを作成できる特別な開発ツールが提供されることも条件となるだろう。そうなれば、クラウドは目標を達成したことになる。クラウド市場はオンプレミスプラットフォームに適合したクラウドから、クラウドに適合したオンプレミスプラットフォームという状況へと変化しているだろう。