クラウド・サービスの標準に顧客が期待する内容を探る

クラウド・サービスの標準間のギャップを埋められるスキルやツールを持つ組織を見つける

クラウドが停止するのは新しいことではありません。クラウドに格納しているデータのバックアップを定期的に取っている管理者であれば、クラウドが停止から復帰した後で、データをクラウドのストレージに完全にリストアすることができます。ただし、この単純なプロセスには潜在的な欠点があります。それは、彼らが管理するシステムは、現在利用しているサービス・プロバイダーが提供するクラウド・サービスやクラウド・ストレージのみに使える専用の手法として、そのサービス・プロバイダーにロックインされてしまう可能性があることです。また、クラウド・サービスの標準を使用することにより、異なるプロバイダー間でデータを転送できないという問題の根本原因に取り組み、対策を施すことができます。この記事では、クラウドの顧客が相互運用性に関して何を期待しているのか、またクラウド・サービスを標準化するためのさまざまな組織とそれらの組織が何を提供しているのかについて説明します。

Judith M. Myerson, Systems Engineer and Architect

Judith M. Myerson はシステム・アーキテクト兼システム・エンジニアです。ミドルウェア・テクノロジー、企業単位のシステム、データベース・テクノロジー、アプリケーション開発、ネットワーク管理、セキュリティー、RFID テクノロジー、そしてプロジェクト管理を含む数多くの分野を得意としています。


developerWorks 貢献著者レベル

2012年 8月 30日

クラウド・サービスが順調に実行されていて、SLA (Service Level Agreement: サービス・レベル・アグリーメント) が締結されている場合に、さまざまな事業者、企業、機関は、クラウドに格納されているデータを別のプロバイダー (IBM SmarterCloud など) に転送したいと考えるかもしれません。しかしさまざまな理由から、それが実際には不可能であることに気付く場合があります。例えば、データをクラウドに格納するための API を呼び出す場合、その API 呼び出しに必要なデータ・フォーマットに関してプロバイダー間に互換性がない、つまり相互運用性がない場合があります。

その結果、事業者はデータを転送できないという問題に直面します。この問題は、クラウド・サービスをホストするプロバイダーを選択する前に、プロバイダーが使用するデータ・ストレージ・フォーマットを比較しなかったために発生します。(この状況を改善するために考えられる 1 つの方法は、異なるプロバイダーへのデータ転送を柔軟に行うことができるようにプロバイダーと交渉するというものです。これには、プロバイダーのクラウド・サービスの API を呼び出すためのコードを変更することが含まれます。)

クラウドの顧客には、単に相互運用可能な API 以上のものが必要です。つまり、以下のようなあらゆるクラウド提供モデルで相互運用性を保証するためのクラウド・サービスの標準が必要になります。

  • Infrastructure as a Service の場合: あるプロバイダーがホストする IaaS で動作する仮想マシンと、別のプロバイダーがホストする IaaS で動作する仮想マシンとは互換性がなければなりません。
  • Platform as a Service の場合: ある IaaS 上で動作するプラットフォームは、別の IaaS 上で動作するどの PaaS とも互換性がなければなりません。
  • Software as a Service の場合: ある PaaS 上で開発されたアプリケーションは、その PaaSと互換性のある PaaS 上で動作する必要があります。

この記事では、読者の皆さんがクラウド・サービスの標準として何が必要なのか判断を下せるように、クラウド・サービスのプロバイダーやコンシューマーが相互運用性の標準に期待している内容をリストアップします。次に、クラウド・サービスの多様な側面に関する標準を作成している組織について詳細に紹介することで、皆さんが自分の要求に合った適切な組織のサイトを訪れて、相互運用性ツールとして彼らが提供するリソースを利用できるようにします。皆さんはさらに、それらの組織を取り巻くコミュニティーに参加し、それらの組織による標準の進化に貢献することもできます。

クラウド・サービスの顧客が期待すること

クラウド・サービスは、顧客 (アプリケーション、プラットフォーム、またはインフラストラクチャー・サービスのコンシューマーまたはプロバイダー) が以下のさまざまな領域で妥当な相互運用性を期待できるようなものでなければなりません。

  • 提供モデルの相互運用性: 特に IaaS 対 IaaS、PaaS 対 PaaS の相互運用性
  • クラウド・ベースのやり取りとそのインターフェース: 例えば、クラウド・システムと非クラウド・システムとのやり取り
  • サービス指向アーキテクチャーと他の Web サービス: クラウド・システムと SOA リファレンス・アーキテクチャー、インフラストラクチャー・フレームワーク、統合モデルとの間の相互運用性のサポート
  • エンタープライズ IT 管理システム: まったく異なる IT 製品を 1 つの製品ファミリーのように動作させるための標準
  • ストレージ: データの一部はクラウド・アプリケーションの機能を実現するためのリソースとなる場合があるため、データのアーカイブやデータへのアクセスを管理するシステムが非常に重要になる可能性があります。
  • セキュリティー: メッセージのキューイング、身元識別と認証、インフラストラクチャーのトポロジー構成とアプリケーションのオーケストレーション構成など、クラウドのセキュリティーに関する問題を管理するプロトコルやユーティリティーの相互運用性
  • 移行機能: 組織がアプリケーション (さらには IT 環境全体) をクラウドに移行するために使用するツールも標準をベースにする必要があります。
  • ユーザー指向の権威者: もし、クラウド・ユーザーが影響を及ぼせる仕組みを持つ非常に大規模な組織 (例えば連邦政府など) がクラウドの相互運用性標準を確立するとしたら、クラウド製品を作成する会社は、市場の大部分がそうした標準を受け入れることを義務付けられることがわかっているため、製品を設計 (場合によっては再設計) する際に相互運用性を持つように設計すればよく、設計時の「苦労」が軽減される会社も出てくるはずです。

標準を作成、採用、改善することで、相互運用性の確立はとても容易なものになります。


クラウド・サービスの標準を作成する組織

クラウド・サービスの標準間のギャップを埋めようとするなかで、標準化を推進するための、あるいは (承認された、またはドラフトの) 標準を公開するための、さまざまな組織が生まれています。これらの組織は、以下に記載するものに対する顧客の期待に応えるために構成されたものです。

  • 組織が最も重点を置く、ベンダーに依存しないクラウド・サービスの標準
  • 業界の標準化組織内のクラウド・コンピューティングに関するワーキング・グループ
  • 情報技術の標準化組織によるクラウド・サービス標準

SLA で使われる標準用語や標準的な値についてベスト・プラクティスを提供する組織は、顧客の期待に応え、SLA 管理の標準化を推進します。程度の違いはあれ、これらの組織は顧客やプロバイダーの代弁者です。

  • オープンなクラウド・サービス標準にフォーカスする組織には、OpenStack Foundation、Open Grid Forum、The Open Group があります。
  • クラウド・コンピューティングに関するワーキング・グループを設立した業界標準化組織には、DMTF (Distributed Management Task Force) や SNIA (Storage Network Institute Association) があります。DMTF の Cloud Management Workgroup と SNIA の Cloud Storage Technical Work Group はクラウド・コンピューティングの標準インターフェースを規定しています。
  • クラウド・コンピューティングの標準を承認済みのものや作成中のものを含めて提供している情報技術の標準化組織には、NIST (National Institute of Science and Technology) や OASIS (Organization for the Advancement of Structured Information Standards) があります。NIST はクラウド・コンピューティングの実質的な定義を公開しています。OASIS はクラウド・コンピューティングの標準に関するドラフトを作成しています。
  • ユーザーの声を代弁して SLA 管理のベスト・プラクティスを提供する組織には、TM Forum と Cloud Service Customer Council があります。

SLA で使われる標準用語や標準的な値に関する資料は作成されつつありますが、この記事の執筆時点では、まだ存在していません。

では、これらの組織のいくつかと、これらの組織が提供するツールを詳細に調べてみましょう。

OpenStack Foundation: IaaS 同士を通信させる

クラウド・サービスの顧客 (既存の顧客と、将来的に見込まれる顧客) は、ある IaaS が (別のプロバイダーがホストする) 別の IaaS と完全に相互運用できるようなクラウド・サービスのオープン・スタンダードを期待しています。OpenStack Foundation はそうした顧客の期待に応えるために、先を見越したアクションを実行しています。

OpenStack Foundation とは何か、そして IaaS を標準化するために彼らが何をしているかについて詳しく見てみましょう。

OpenStack Foundation は、NASA の Nebula プラットフォームのコードを Rackspace のプラットフォームと統合する IaaS クラウド・コンピューティング・プロジェクト、OpenStack を管理しています。世界中の開発者やクラウド・コンピューティング技術者は、オープンソースのパブリック・クラウド用およびプライベート・クラウド用のクラウド・コンピューティング・プラットフォームを作成するために協力して作業をしています。このプロジェクトに対するコードの変更は、2011年に Rackspace からスピンオフした OpenStack Foundation のメンバーによるコントリビューションによって行われています。2012年 4月、IBM と Red Hat はプラチナ・メンバーとして OpenStack Foundation に参加することで合意しました。これは 2 社が年間 50 万ドルを 3 年間にわたって寄付することを意味します。2 社はソフトウェア・コードの変更に対するコントリビューションを行います。プラチナ・メンバーとして参加を計画中、または既に参加を表明した他の企業には、AT&T、Canonical、HP、Nebula、Rackspace、SUSE などがあります。

OpenStack はモジュール構造になっており、その中には IaaS を標準化するための作業成果としての 3 つのコンポーネントをはじめとする、以下のコンポーネントが含まれています。各コンポーネントには以下の括弧で示すコードネームがつけられています。

  • Compute (Nova): 自動でプロビジョニングされる仮想コンピューティング・インスタンスを大規模にデプロイするためのオープンソースのソフトウェアと標準を提供します。
  • Object Storage (Swift): 静的オブジェクトによる大規模で冗長構成のストレージのためのオープンソースのソフトウェアと標準を提供します。
  • Image Service (Glance): 仮想ディスク・イメージの発見、登録、提供サービスを提供します。
  • Identity Service (Keystone): すべての OpenStack プロジェクトにわたる統合認証を提供し、既存の認証システムと統合されます。
  • Dashboard (Horizon): 管理者やユーザーがセルフサービス・ポータルを介して、クラウド・ベースのリソースにアクセスしたり、クラウド・ベースのリソースをプロビジョニングしたりできるようにします。

Open Grid Forum: クラウドとのやり取りおよびそのインターフェース

クラウド・サービスの顧客はクラウド・コンピューティングのオープン・インターフェースを期待しています。OGF (Open Grid Forum) は、クラウド・インターフェースの標準を公開することによって顧客の期待に応えています。

OGF は標準を作成する組織であり、グリッド・コンピューティング、クラウド・コンピューティング、そしてこれらに関連する形態の高度な分散コンピューティングの分野で活動を行っています。OGF は先を見越して、クラウド・ベースのやり取りを規定する OCCI (Open Cloud Computing Interface) 標準を承認、公開しています。このインターフェースは、クラウド・コンピューティングにおける多種多様な問題 (科学データの処理、新薬の発見、癌研究、金融リスク分析、仮想化、製品設計などに関する問題) を解決するために使用されています。

OCCI は、あらゆる種類のクラウド管理タスクのためのプロトコルと API 設計コンポーネントを提供しています。この作業は元々、IaaS ベースのサービスに対するリモート管理 API を作成するために開始されたものです。OCCI の最新リリースは PaaS モデルや SaaS モデルにも適しています。

グリッド・コンピューティングで使用するソフトウェアは、「1 つの大規模なシステム・イメージとしてのプログラムを分割し、その各部分を数千台のコンピューターに割り当てる」という処理を実行できるものでなければならないことに注意してください。グリッドに関する 1 つの懸念事項として、あるノードでソフトウェアの一部に障害が発生すると、他のノードの別の部分のソフトウェアでも障害が発生する可能性があります。先を見越したアクションとして、分割したソフトウェアのどの部分も必ず別のノードにフェイルオーバーできるようにする必要があります。

Open Group: IaaS を標準化し、SOA をサポートする

クラウド・サービスの顧客は SOA (Service Oriented Architecture) をサポートする IaaS を期待しています。Open Group も IaaS の標準化作業を行う組織です。Open Group は IaaS や SOA を構築する組織を支援するために、以下の 3 つの標準を公開しています。

  • SOCCI (Service Oriented Cloud Computing Infrastructure Framework)
  • SOA RA (Service Oriented Architecture Reference Architecture)
  • OSIMM (Open Group Service Integration Maturity Model)

SOCCI は SOA やクラウドのイニシアチブをサポートするインフラストラクチャーのビルディング・ブロックです。このプロジェクトでは、IBM と HP が共同議長を務めました。

SOA RA は IaaS 上で SOA を作成、評価するための青写真を提供します。IBM の役割は、この標準に関する 200 ページのガイドに対する重要な助言をすることでした。

OSIMM は組織の SOA の成熟度レベルを評価するためのフレームワークを提供します。IBM には独自の成熟度モデルとして、IBM Service Integration Maturity Model があります。

すべての IaaS 実装が SOA のサポートに使用されるわけではないことを忘れないでください。

Distributed Management Task Force: インキュベーターからワーキング・グループへ

クラウド・サービスの顧客は、DMTF のような業界組織内のワーキング・グループが作成したオープンなコンピューティング標準を期待しています。DMTF は、エンタープライズ IT 環境のシステム管理のための標準を作成、維持、推進しています。DMTF は、さまざまなメーカーや企業の IT 製品間でのシステム管理の相互運用性を実現しようとしています。

DMTF の Open Cloud Standards Incubator は、クラウド管理のユース・ケース、アーキテクチャー、相互作用の標準を作成することで、クラウド環境間のやり取りを標準化することに焦点を当てたものです。この作業は 2010年 7月に完了しました。クラウド標準を作成するための DMTF の作業は現在、CMWG (Cloud Management Workgroup) と CADF WG (Cloud Auditing Data Federation Workgroup) によって行われています。

CMWG は、サービス・プロバイダーとしてのリクエスター、開発者、プロバイダーの間でクラウドの相互運用性を管理するための仕様を作成しています。CMWG は、作業が進行中のドラフトとして、IaaS 内のリソース管理モデルを定義する CIMI (The Cloud Infrastructure Management Interface) を公開しています。このインターフェースを使用することで、新しい仮想マシンの作成、マシンへのボリュームの追加、クラウドのエントリー・ポイントを介してのマシン・テンプレート定義をすることができます。

CADF WG は、クラウド・プロバイダーが特定の監査イベント、監査ログ、監査レポートなどの情報を作成、共有できるように、クラウドの監査情報をフェデレートするためのオープン・スタンダードを作成しています。これらのレポートやログには、コンプライアンス管理のドメインやフレームワーク (ISO 27002、PCI DSS、COBIT など) を基にイベントを分類、タグ付けするために必要な情報が含まれています。

Storage Network Industry Association: 常に重要なクラウド・ストレージ標準

クラウド・サービスの顧客は、クラウド・ストレージに関するクラウド・コンピューティング・インターフェース標準の技術作業グループを期待しています。そうしたグループの 1 つが非営利団体の Storage Network Industry Association です。1997年以来、この組織はストレージの標準に関わってきました。クラウド・ストレージのシステム標準を作成する作業のなかで、SNIA は先を見越して Cloud Storage TWG (Technical Work Group) を発足させました。そして良い知らせとして、このワーク・グループは CDMI (Cloud Data Management Interface) 標準と、この標準に対する拡張を公開しています。

この標準インターフェースには、アプリケーションがクラウドのデータ要素を作成、取得、更新、削除するために使用するインターフェースが規定されており、各サービス・プロバイダーはこのインターフェースを API として提供することになります。このインターフェースは、クライアントがクラウド・ストレージの機能を知ったり、コンテナーやコンテナー内に配置されるデータを管理したり、コンテナーやコンテナー内のデータ要素にメタデータを設定したりする上で役に立ちます。

管理アプリケーションはこのインターフェースを使用することで、他のプロトコルによってアクセス可能なコンテナー、アカウント、セキュリティー・アクセス、課金情報、ストレージを管理することができます。

Cloud Storage TWG は、CDMI の次期リリースの相互運用可能な実装がテストに合格して公開される前に、CDMI 標準に新機能を追加するための個々の拡張を公開しています。

Cloud Storage TWG は SNIA Strategic Alliances 委員会と協力してシステム・レベルの要件に関するドキュメントを提供し、これらのドキュメントを他のクラウド・ストレージ標準化組織と共有しようとしています。

OASIS (Organization for the Advancement of Structured Information Standards): クラウドのセキュリティー標準を推進

クラウド・サービスの顧客は、クラウド・コンピューティングを含む情報技術に関してオープンなセキュリティー標準を期待しています。こうした標準の例として、OASIS (Organization for the Advancement of Structured Information) によって推進されている標準があります。OASIS はクラウドのセキュリティー標準に関するドラフトを作成するために、以下の 3 つの TC (Technical Committee) を発足させました。

  • AMQP (Advanced Message Queuing Protocol)
  • IDCloud (Identity in the Cloud)
  • TOSCA (Topology and Orchestration Specification for Cloud Applications)

AMQP TC は、オープンな相互運用性によって組織がエンタープライズ・ミドルウェア・ソフトウェアの統合コストを削減できるようなプロトコルを推進しています。このプロトコルを利用することで、組織はアプリケーション (IBM WebSphere MQ (MQ Series) など) 間、組織間、分散クラウド・コンピューティング環境間、そしてモバイル・インフラストラクチャー内で、これまでよりも容易かつセキュアにビジネス・メッセージを交換することができます。

IDCloud TC はクラウド・コンピューティングの ID 管理で発生するセキュリティーの問題に対処します。IDCloud TC は、現在の ID 標準の中で相互運用性を実現するために必要な事項を判断し、収集されたユース・ケースに対してリスクと脅威の分析を行い、脆弱性を軽減するためのガイドラインを作成します。IBM は IDCloud TC のメンバーです。

TOSCA TC の目的はサービスとアプリケーションの移植性を向上させることです。そのために TOSCA TC では、標準に準拠する任意のクラウドに移植可能なデプロイメント、既存のアプリケーションのクラウドへのスムーズなマイグレーション、(コンシューマーの選択による) 柔軟なバースティング、複数のプロバイダーに対応した動的なクラウド・アプリケーションなどを実現しようとしています。移植性を実現するためには、提供されるそれぞれのインフラストラクチャーのクラウド・サービス、これらのサービスの各部分の関係、そしてこれらのサービスの動作 (デプロイ、パッチ、シャットダウンなど) についての相互運用性を実現することが必要です。

TM Forum: 複数のパートナーのための SLA に関するベスト・プラクティス

クラウド・サービスの顧客やプロバイダーはサービスの品質、優先順位、責任に関する SLA について、標準的な用語と数値を期待しています。TM Forum の Cloud & New Services Initiative は、クラウド市場を活性化するために、(SLA 管理などのトピックに関する) ベスト・プラクティスや標準 (Frameworx) を活用することに重点を置いています。TM Forum はオープンな市場を実現する手段として標準を重視しています。

TM Forum は、サービスの品質、優先順位、責任に関して 2 者以上の関係者間で期待される内容を規定するものとして SLA を定義しています。SLA は従来、サービス・プロバイダーと企業顧客との間での契約でしたが、新世代のサービスに対するバリュー・チェーンが拡大するにつれ、多種多様なパートナー関係のための SLA が重要となっています。パートナー関係には以下のような例が挙げられます。

  • サービス・プロバイダーとクラウドのエンドユーザー
  • サービス・プロバイダーとベンダー
  • サービス・プロバイダーと企業
  • 企業とエンドユーザー
  • サービス・プロバイダーと企業
  • ネットワーク・プロバイダーとサービス・プロバイダー (ネットワーク・アクセス・プロバイダー)
  • ベンダーとネットワーク・プロバイダー、サービス・プロバイダー、または企業
  • コンテンツ・プロバイダーとコンテンツ・アグリゲーターまたはアドバイザー

企業が競争を勝ち抜くためには、提供されるサービスの品質管理を事前に行うようにしなければなりません。これらのサービスのプロビジョニングは複数のパートナーに依存するため、パートナー・サービスの SLA の管理が成功に不可欠になっています。SLA を使用することで、パフォーマンス、カスタマー・ケア、課金、サービスのプロビジョニング、その他のビジネス領域に対するパートナー間で期待される内容を定義、管理することができます。

SLA を管理することで、SLA に規定されたパラメーター (パフォーマンス、タイムライン、コストの要件など) が満たされない場合に対して事前に定義されているペナルティーを評価することもできます。例えば、クラウド・コンピューティングのダウンタイムが 1 時間を超える場合、ペナルティーとしてサービス料金の 10 パーセントを払い戻す、などが考えられます。

TM Forum は、サービス・プロバイダーが運用や統合にサービス指向の手法を使用してパフォーマンスを評価、改善できるように、Frameworx という一連の標準を提供しています。Frameworx に含まれる標準には、Business Process Framework (eTOM)、Information Framework (SID)、Application Framework (TAM)、Integration Framework、Business Metrics などがあります。

Cloud Service Customer Council: SLA のための新たな標準用語

CSCC (Cloud Standards Customer Council) は OMG のエンドユーザーを代弁するグループであり、クラウドの正常な導入を促進することに特化しています。CSCC は標準化組織ではありませんが、クラウド標準のための既存の作業を補完しています。CSCC はすべてのエンドユーザー組織に対して開かれた組織であり、設立にあたって出資したのは IBM、Kaavo、Rackspace、Software AG です。

CSCC は、クラウドへの移行に関する標準、セキュリティー、相互運用性の問題に焦点を絞っています。具体的には、CSCC はクラウドの SLA に関する標準用語と数値を提唱しています。今のところ、クラウド・サービスの SLA の標準は存在していません。

CSCC は、クラウドの SLA のことを、クラウドのコンシューマーとプロバイダーとの間でサービスに関して期待される内容を書面にしたものとみなしています。CSCC は、クラウド・コンピューティングのプロバイダーから提供されるエンドユーザーの SLA を評価、比較する際に意志決定者が何を期待し、何を認識しておく必要があるかの指針を提供しています。また意志決定者は、クラウド・コンピューティングのプロバイダーがベンダーやエンタープライズ・データ・センター、ネットワーク・プロバイダー、コンテンツ・プロバイダー、その他との間で締結した SLA も評価する必要があります。

National Institute of Standards and Technology: 米国連邦政府のデファクト・スタンダード

クラウド・サービスの一部の顧客は、クラウド・コンピューティングの定義に関して、政府がデファクト・スタンダードを提供することを期待しています。NIST (National Institute Standard and Technology) が提供するクラウド・コンピューティング標準の定義は、ほとんどの場合、より効率的なサービスをエンドユーザーに提供するためにクラウドに移行する政府機関を対象にしているようです。

2011年 9月、NIST は「The NIST Definition of Cloud Computing (NIST によるクラウド・コンピューティングの定義)」でクラウド・コンピューティングの定義を公開しました。その中では以下のように定義されています。

管理作業やサービス・プロバイダーとのやり取りが最小限で済むものとして迅速にプロビジョニングとリリースが行えて構成可能なコンピューティング・リソース (ネットワーク、サーバー、ストレージ、アプリケーション、サービス) の共有プールに対する、ユビキタスかつ便利なオンデマンドのネットワーク・アクセスを実現するためのモデル。NIST はクラウド・コンピューティングに不可欠の特性として以下の 5 つを挙げています。

  • オンデマンドでセルフサービス
  • 広範なネットワーク・アクセス
  • リソース・プール
  • 急峻なエラスティック性 (弾力性) や拡張性
  • 測定可能なサービス

NIST は 3 つのサービス・モデル (ソフトウェア、プラットフォーム、インフラストラクチャー) を挙げています。また、デプロイメント・モデルを 4 つのコンポーネント領域 (プライベート、コミュニティー、パブリック、ハイブリッド) に分けています。

2011年 12月、NIST は「Guidelines on Security and Privacy in Public Cloud Computing (パブリック・クラウド・コンピューティングにおけるセキュリティーとプライバシーの指針)」を公開し、2012年 5月にはクラウド・コンピューティングの長所と短所を説明した「Cloud Computing Synopsis and Recommendations (クラウド・コンピューティングの概要と推奨事項)」のドラフトを公開しています。


まとめ

クラウドの標準に関して、今後どのようなものが現れるのでしょう。

私達は、SaaS、PaaS、IaaS の顧客がプロバイダーを比較する際に標準化組織やユーザーの声を代弁する組織に何を期待するのかを念頭に置く必要があります。IaaS が今後数年間に完全に標準化されることは期待できません。SLA を比較する際に何を期待し、何を認識する必要があるのかを判断できるように、SLA の管理に関するベスト・プラクティスが提供されていますが、SLA に関するクラウド・コンピューティングの標準および数値が提供されるのは、まだこれからの話になります。

1 つの方向として、開発者、管理者、ビジネス・アナリスト (つまり実際の問題を扱う専門家) のチームを編成し、以下の点に関して標準化団体が容易に判断を下せるようにすることが考えられます。

  • クラウド・サービスの標準の間にはどんなギャップがあるのか
  • どの程度これらのギャップを埋められるのか
  • どうすれば SLA のベスト・プラクティスを SLA 標準に進化させられるのか

参考文献

学ぶために

製品や技術を入手するために

  • IBM SmarterCloud Enterprise で利用可能な製品イメージを調べてみてください。

議論するために

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing
ArticleID=832297
ArticleTitle=クラウド・サービスの標準に顧客が期待する内容を探る
publish-date=08302012