このアプローチでは、クラウドコンピューティングの基本方針の1つが損なわれる。それはマルチテナントプールという概念だ。特定の顧客専用のハードウェアという設定により、プールは小さくなる。そのため、クラウドサービスプロバイダーは、共有のハードウェアを使用する場合よりも顧客に高額な代金を請求せざるを得なくなる。また、このプールのハードウェアとコンピューティングリソースにも限りがあるため、弾力性が制限される。

　ユーザー数を倍増するには、プロバイダーが追加のハードウェアを提供しなければならないだろう。そのため、遅延が生じる。DaaSのメリットの1つは、すぐ拡張できることだが、このシナリオでは、そのメリットが享受できない。クラウドサービスの弾力性とは、必要に応じて拡張できるだけではなく、縮小できることも含まれる。だが、ハードウェアの準備と配置が完了すると、DaaSプロバイダーは、この追加の容量が必要なくなった後も追加の容量に対して顧客に支払い続けることを求める可能性がある。

　もう1つの選択肢は、自社所有のサーバをプロバイダーのデータセンターに配置することだ。これは一般的に「コロケーションアレンジメント」と呼ばれる。プロバイダーは電源とインターネット接続を備えたサーバラックを用意し、顧客は、このサーバラックに自社所有のサーバを配置して環境を構築する。コロケーションアレンジメントは、厳密にはDaaSに分類されないかもしれない。だが、自社が所有するWindowsのライセンスを使用しながら、DaaSのメリットを享受できる可能性がある。

　マルチテナントに備わっているプールや弾力性は手に入らない。だが、セットアップの大半を所有しているため、確実性が段違いに高くなる。全てのハードウェアを所有している場合は、迷惑な隣人のリスクもない。迷惑な隣人とは、同じサービスプロバイダーを利用し、あなたのコンピューティングリソースを侵食している他の顧客だ。

WindowsデスクトップとWindows Serverデスクトップ

　DaaSプロバイダーが最大の経済的なメリットを得る方法は、大規模なマルチテナントのリソースプールでデスクトップVMを実行することだ。これには、Microsoftの「Service Provider License Agreement」（SPLA）の対象となるサーバOSを使用しなければならない。幸いなことに、Microsoftは数年前にWindowsのサーバ版とデスクトップ版のコードベースを統合する決断を下している。そのため、「Windows Server 2008」は、「Windows 7」を搭載したデスクトップPCとほぼ同じような外観と動作になるようセットアップ可能だ。「Windows Server 2012」と「Windows 8」についても同じことがいえる。多くのプロバイダーは、サービスのユーザーごとに個別のWindows ServerのVMを提供している。また、賢明なプロバイダーは、Windowsのデスクトップ版を模倣するために、Windows Serverの視覚的な要素を作り直している。

　サーバ版とデスクトップ版のWindowsは同じコードベースを共有している。この状況を踏まえると、どちらのOSでもアプリケーションが問題なく実行できることを期待するかもしれない。だが、いつもそうとは限らない。Windowsアプリケーションの大部分は、Windows Server OSとWindowsデスクトップOSのどちらでも問題なく動作する。Microsoftの標準に従って記述されたアプリケーションは、Windows Serverで実行できる。これには同社の「Microsoft Office」も含まれる。

　ただし、全てのアプリケーションがMicrosoftの標準に従って記述されているわけではない。インストール先がサーバOSであることをインストーラーが検出すると、インストールできないソフトウェアもある。また、Windowsコンポーネントの中には、デスクトップPCにはインストールされているが、サーバにはインストールされていないものもある。スキャナのサポートは、その一例だ。通常、このコンポーネントはサーバには存在しない。多くの場合、これらは克服不可能な問題ではない。インストーラーをだましてデスクトップOSだと思わせたり、追加のコンポーネントをインストールすることは可能だ。だが、これらの問題が事態を複雑にするのは紛れもない事実である。

　古いアプリケーションや特定の企業のために開発されたアプリケーションが問題をもたらすことは少なくない。多くの特注ソフトウェアは、デスクトップを装っているWindows Serverで実行しても問題はない。だが、安いコストで、明確な将来の要件を考えずに急いで記述されたソフトウェアは多数存在する。

　大半のDaaSデスクトップは、64ビットOSを実行している。64ビットOSでは、大容量のRAMがサポートされ、最近のアプリケーションは優れたパフォーマンスを発揮する。だが、64ビットのWindowsでは、16ビットのアプリケーションを実行することができない。過去15年以内に作成されたアプリケーションは32ビットだ。32ビットアプリケーションは64ビットOSで実行できる。現在、16ビットアプリケーションを使用している場合は、今が16ビットアプリケーションのリプレースを検討するのには最適なタイミングであろう。選択肢は、16ビットアプリケーションのユーザーをDaaSの対象から除外するか、16ビットアプリケーションが不要になったときにDaaSを検討するかの2つに1つだ。

DaaSでRDSHを使用する

　データセンターからWindowsデスクトップを配信するという方法を長年利用している場合は、「アプリケーションサービスプロバイダー」という名前に聞き覚えがあるだろう。これは、「Windowsターミナルサーバ」ベースのデスクトップの提供に関与していたものだ。アプリケーションサービスプロバイダーは、現行のDaaSモデルそのものある。Windows Server OSを各ユーザー専用にするのではなく、「リモートデスクトップセッションホスト」（RDSH）を使用して複数ユーザーのデスクトップセッションを1台のWindows Serverでホストするという選択肢がある。1台のRDSHサーバを複数の従業員が共有すると、DaaSプロバイダーが用意しなければならないハードウェアは少なく済む。つまり、専用のVMを用意するよりもコストが安くなる。

　一方、RDSHではユーザー間の分離があまり行われない。1台のRDSHホストの全ユーザーは、ホストのシステムドライブとアプリケーションを共有する。そのため、RDSHホストを共有しているユーザーは、うるさい隣人になり得る。1つの非常に複雑なExcelブックが、RDSHサーバのパフォーマンスを大幅に低下させることもある。RDSHとのアプリケーションの互換性は、これまでも潜在的な問題となっていた。

　ほとんどのアプリケーションは問題ない。繰り返しになるが、Microsoftの標準に従って記述されているアプリケーションであれば問題ない。デスクトップPCを装ったWindows Serverで問題なく実行できるが、新しいリモートデスクトップセッションで別のユーザーがアプリケーションを起動しようとした途端に問題が発生するアプリケーションも存在する。この問題は、一部の企業が使用している特殊な基幹業務アプリケーションで発生する傾向がある。多くの場合、ソフトウェアの開発メーカーに直接話をして、そのソフトウェアをRDSHで使用している顧客がいるかどうかを確認できる。筆者は、特別なインストールプロセスが必要なものやRDSH専用のインストーラーが別途用意されているアプリケーションを見たことがある。RDSHでアプリケーションを実行するにはいくらかの注意が必要だが、その多くは対処できるものだ。

　要件を満たすためには、DaaSに対して複数のアプローチを使用しなければならない可能性もある。マルチテナントのWindows Serverデスクトップが最適な選択肢となるユーザーもいれば、安価なRDSHデスクトップを使用できるユーザーもいるだろう。クラウドサービスプロバイダーのコロケーション施設に自社のVDIを構築することで、DaaSプロバイダーから得たいと考えているものを全て手に入れられるかもしれない。これらの選択肢の中には、MicrosoftがデスクトップOSについてもSPLAライセンスを提供するとシンプルになるものもあるだろう。だが、大半の選択肢には変化がなく、少し安価になるくらいが関の山だろう。