pCardには、以下の4つの要素が表示される。
pCardのフォーマットとコンテンツを記述するメタデータ。このメタデータには、クラウドプロバイダーがpCardの残りの部分を処理できるかどうかを判断するのに十分な情報を記述しなければならない。
アプリケーションビットがパッケージ化される仕組みと、そのパッケージを処理するインフラストラクチャ（例えばuntarや「WebLogic」マネージャなど）がどのようなものになるかに関する記述。この記述は環境全体ではなく、個々のパッケージのニーズに焦点を当てたものにすべきだ。ただし、これら2つを組み合わせたパッケージ（Open Virtualization Format（OVF）など）がここに含まれ、環境に関する項目（以下の3）から参照される可能性もある。
クラウド環境によってサポートされなければならない中核的なサービスと環境アーキテクチャに関する記述。これには、VMのサイジングやストレージ要件、ネットワークトポロジなどが含まれるだろう。ペイロードパッケージの外側の自動化に関する要件も含まれる可能性があり、これは初期設定の一部として実行する必要がある。
ペイロードパッケージの記述内に関連情報を参照するポインタを追加しても構わない。
単一のベンダーがこの情報を所有することも考えられるが、一定のポータビリティを確保するために、アプリケーションの分類ごとに、より一般的な標準が策定されることが望ましい。
アプリケーションビットの自動化されたランタイム操作の処理に必要な、オーケストレーションとサービスレベルポリシー。この項目には、顧客によるペイロード監視に必要な特定の管理フィードフォーマットとデータに関する要件も含まれる可能性がある。
もう一度言うが、筆者はこの分野で何らかの標準が策定されることを望んでいる。しかし、この項目では、必要な情報を宣言するための多様な方法が許容されるべきだ。
筆者が以前、次世代のクラウド対応パブリックネットワークインフラストラクチャに取り組んでいるグループにこのコンセプトを披露したところ、かなり熱狂的な反応が返ってきた。ある意味で、これはクラウドがサービス割り当てを自動化し、さまざまなペイロードをサポートできるようにするための、「クラウド」へのインプットである。
皆さんはどのようにお考えだろうか。このコンセプトは、もっと深く追求する価値があるものに思えるだろうか。正式なワーキンググループを設立して、さらなる可能性を探るだけの価値があるだろうか。このコンセプトに関して現在議論が行われているが、それに参加したい人のために、筆者は公開のGoogle groupを立ち上げた。
あるいは、このコンセプトは自分のクラウドペイロードには向いていない、という人はその理由を聞かせてほしい。その場合、どのような代替案があるだろうか。
この記事は海外CBS Interactive発の記事を朝日インタラクティブが日本向けに編集したものです。
CNET Japan 特別企画 -PR-
ITジャーナリスト佐々木俊尚氏と日立のキーパーソンが語る！
2010年企業クラウド元年 ビジネスニーズが企業のクラウド化を加速する
