JP2017536608A - ステージ及びバージョンポリシーを用いるトポロジーベースの管理 - Google Patents

Abstract

１実施例において、ステージ及びバージョンポリシーを用いるトポロジーベースの管理のための方法は、開発中のアプリケーションにトポロジーを関連付けることと、複数のポリシーを決定することと、該複数のポリシーを該トポロジーの複数のノードに関連付けることと、該関連付けられた複数のポリシーを用いて該トポロジーをプロビジョニングすることとを含むことができ、該複数のポリシーは、該アプリケーションの所与のステージ及びバージョンに対して利用可能な複数のインフラストラクチャを定義するステージ及びバージョンポリシーを含む。【選択図】図３

Description

ますます多くの企業体及び個人が、たとえば、いくつかあるクラウド関連の目的の中でも特に、商品やサービスを販売したり、業務記録を維持したり、個人にコンピューティング資源へのアクセスを提供したりするために、クラウドコンピューティング、及び、クラウドコンピューティングシステムを通じて提供されるサービスを利用するようになってきている。クラウドコンピューティングは、クラウドの利用者に、該クラウド上に構築されたサービスもしくはそれらのサービスの組み合わせとして、スケーラブルで統合化されたコンピューティング、ストレージ（記憶装置）、及びネットワーキング能力を提供する。クラウドコンピューティングシステムがあるエンティティ（企業体など）のために生成される場合には、クラウドを、該エンティティによってまたは該エンティティのために、設計し、提供（プロビジョニング）し、配備（デプロイ）し、及び維持することができる。クラウドコンピューティングシステムを設計し、提供（プロビジョニング）し、配備（デプロイ）し、及び維持することは、難しい作業でありうる。

（補充可能性あり）

本開示にしたがう設計図のブロック図である。 本開示にしたがうアーキテクチャ由来のトポロジーを示すブロック図である。 本開示にしたがう、クラウドサービスを設計し、提供（プロビジョニング）し、配置（デプロイ）し、監視し、及び管理するためのトポロジーベースの管理ブローカーの機能の概要を示すブロック図である。 本開示にしたがう、クラウドサービスを設計し、提供（プロビジョニング）し、配置（デプロイ）し、監視し、及び管理するためのトポロジーベースの管理ブローカーの機能の概要を示すブロック図である。 トポロジーベースの管理ブローカーの共通のプラットフォームを示すブロック図である。 本開示にしたがう、トポロジーを設計する方法を示すフローチャートである。 本開示にしたがうシステムの１例を示す。 本開示にしたがうシステムの１例を示す。 本開示にしたがうシステムの１例を示す。 本開示にしたがう、トポロジーのノードに関連付けられた構成要素のトポロジーを構成する構成要素のプラットフォームの１例を示すブロック図である。

従来のクラウドコンピューティング環境では、ステージ（段階）及びバージョンポリシーは、クラウドコンピューティングプラットフォームの独立型の製品、及び／又は一部でありうる。さらに、従来のクラウドコンピューティング環境は、クラウドコンピューティング環境のトポロジーに基づかないステージ及びバージョンポリシーを含みうる。本開示のいくつかの実施形態では、システム及び方法は、クラウドコンピューティング環境のトポロジーに基づき、かつ、該トポロジー及び／又はトポロジーインスタンスにマッピングされたステージ及びバージョンポリシーを含むことができる。従来のシステム及び方法に対する本開示の実施形態の利点は、ファーストデーオペレーションなくしてセカンドデーオペレーションをサポートできること、及び／又は、ＣＳＡをサポートできること、及び／又は、レガシーシステム（従来のシステム）と互換性がある（ないしそれに適合する）ステージ及びバージョンポリシーを提供することである。

クラウドコンピューティングは、ユーザーのデータ、ソフトウェア、及び計算に対するサービスを提供する。クラウドサービス内のリソースに配置（デプロイ）されているアプリケーションは手動で配置（デプロイ）される場合がある。この手動配置には、かなりの管理時間がかかる。アプリケーションを手動で配置（デプロイ）するステップは、インフラストラクチャの提供（プロビジョニング）及びインスタンス化を含みうる。これは、ミドルウェアやＤＢ＋アプリケーションなどのアプリケーションもしくはプラットフォームのインストールをリンクすること、または、配置（デプロイ）されたインフラストラクチャに関する十分な知識を有していてもいなくてもイメージを配置（デプロイ）することを含みうる。手動配置はさらに、アプリケーションを配置することを試みるユーザーによって起動される多くの一連のステップを含みうる。したがって、配置されたインフラストラクチャにアプリケーションを手動でリンクすることは、大量のコンピューティング資源及び人的資源を消費し、また、ミス、並びに、アプリケーションと背後にあるインフラストラクチャとの間の矛盾する問題を引き起こし得る。配置されたインフラストラクチャへのアプリケーションのリンクを、いくつかのツール、スクリプト、及び実行ファイルで自動化することができ、この場合、オーケストレータが、それらのプロセスの一連の実行を自動化する。クラウドサービス内のリソースに配置されるアプリケーションの設計、提供（プロビジョニング）、配置（デプロイ）、及び管理（ないし維持）に使用されるいくつかのデバイス（装置）は、データセンター、プライベートクラウド、パブリッククラウド、マネージドクラウド（managed cloud）、ハイブリッドクラウド、及びそれらの組み合わせを含むことができる。

より具体的には、ネットワークを介してユーザーに提供されるクラウドサービスを、クラウドサービスマネージャを用いて、設計し、提供し、配置し、及び管理することができる。クラウドサービスプロバイダーやその他の（企業などの）エンティティもしくは個人は、クラウドサービスを設計し、提供し、配置し、及び、いくつかのサービス、アプリケーション、プラットフォーム、または、クラウド環境において配置され、実行され、及び管理されるインフラストラクチャ能力から適切に構成されたクラウドサービスを管理する。この場合、それらの設計をユーザーに提供することができ、該ユーザーは、カタログから市場またはＡＰＩコールを介してそれらの設計を注文し、要求し、及び購入して、同じメカニズムによって、それらの設計に基づいて配置されたクラウドサービスのライフサイクルを管理することができる。より詳細に後述する、ヒューレットパッカード社によって設計されて供給されているCLOUD SERVICE AUTOMATION（ＣＳＡ ３．２）などのクラウドサービスマネージャにおけるサービス設計は、「設計図（blueprint）」で表現される。

設計図は、サービスを構成する全ての構成要素を提供もしくは管理して、特定のライフサイクル管理アクションを実行するために実行されるワークフローの集合に関してサービスを記述する。設計図によって定義されているそれらのワークフローの機能のうちのいくつかは、リソースプロバイダーに対するコールとして実行される実際のライフサイクル管理アクションである。該リソースプロバイダーは、それらのコールを、リソースプロバイダーによって提供された特定のリソースまたはインスタンスに固有の良好に形成されかつ交換された命令に変換する。

図１は、本明細書に記載されている原理の１例にしたがう設計図（１００）のブロック図である。設計図中のそれぞれのオブジェクト（１０２−１、１０２−２、１０２−３、１０２−４、１０２−５、１０２−６、１０２−７、１０２−８、１０２−９、１０２−１０、１０２−１１、１０２−１２）を、リソースプロバイダーを呼び出すアクションワークフローに関連付けることができる。クラウドサービスを設計し、提供し、配置し、及び管理する設計図（１００）アプローチにはいくつかの課題が存在する。設計図は、関係によって関連付けられた特性及びアクションを含むオブジェクトからなるが、該設計図の構造は、たとえば、クラウドサービスをサポートするシステムの実際の物理的なアーキテクチャなどの物理的なトポロジー（物理トポロジー）との関係を識別しない。これは、たとえば、システムに関連付けられたポリシーを記述するために、追加のメタデータを設計図（１００）に関連付けることを難しくする。さらに、ポリシーと設計図（１００）中のノードとのこの関連付けは、配置されることになるクラウドサービスの設計者または管理者にとって直感的に理解できるものではない。

さらに、同じ理由によって、設計図（１００）の構造は、CONTINUOUS DELIVERY AUTOMATION（ＣＤＡ）がそうであるように、アプリケーションのモデルまたはインフラストラクチャのテンプレートとして使用するのが難しい。ＣＤＡは、バージョン、構成（コンフィグレーション）、及び他のアプリケーション要素を管理しつつ、インフラストラクチャ要件及びアプリケーション要件を独立にモデル化するトポロジーデザイナー内で使用されるシステムツールである。ＣＤＡ１．２も、ヒューレットパッカード社によって開発されて供給されている。上記と同じ理由によって、設計図（１００）の構造は、アプリケーションのモデルとして使用するのが難しい。なぜなら、設計図は、該アプリケーションのアーキテクチャを記述していないからである。さらに、設計図は、インフラストラクチャのテンプレートとして使用するのが難しい。なぜなら、設計図は、インフラストラクチャのアーキテクチャを記述していないからである。この結果、アプリケーションのモデル並びにインフラストラクチャもしくはプラットフォームのテンプレートをモデル化し、及び、アプリケーションのモデルとインフラストラクチャもしくはプラットフォームのテンプレートを互いにマッピングすることを目的とするシステムは、該設計図と簡単には両立しない。なぜなら、それらは、それらのサービスをモデル化する異なる方法に基づいているからである。

本システム及び方法は、クラウドサービスを構成するシステムの物理的なアーキテクチャを定義するアーキテクチャ記述トポロジーを記述する。図２は、本明細書に記載されている原理の１例にしたがう、アーキテクチャ由来のトポロジー（２００）を示すブロック図である。図２に示されているように、アーキテクチャ由来のトポロジー（２００）は、互いに関連付けられた複数のノード（２０１、２０２、２０３、２０４、２０５、２０６、２０７、２０８、２０９、２１０、２１１、２１２、２１３、２１４、２１５）を含むことができる。トポロジー（２００）内のノード間の関連付けは、白抜き矢印によって示されている。トポロジー（２００）内の複数のノード（２０１、２０２、２０３、２０４、２０５、２０６、２０７、２０８、２０９、２１０、２１１、２１２、２１３、２１４、２１５）を、塗りつぶし矢印によって示されているように、互いに集約させることもできる。集約（aggregation）は、単一の接続が維持することができるスループットを超えてスループットを高め、及び、リンクの１つが故障した場合に備えて冗長性を提供するのと同時に、複数のネットワーク接続を組み合わせる（集約する）ことを記述するために使用されるコンピューティング用語である。

たとえば、ロード（負荷）バランサ（２０１）、ウェブサーバーサービス（２０２）、アプリケーションエンタープライズアーカイブ（２０３）、及びデータベース（２０４）は、互いに関連付けられている。ウェブサーバーサービス（２０２）は、ウェブ仮想マシン（２０５）、そのセキュリティグループ（２１３）及びウェブ仮想ローカルエリアネットワーク（２０９）と集約される。同様に、アプリケーションエンタープライズアーカイブ（２０３）は、JavaBeans Open Source Software Application Server（ＪＢｏｓｓ）サービス（２０６）、ＪＢｏｓｓ仮想マシン（２０８）及びこれに関連するセキュリティグループ（２１４）、及び、セキュアアプリケーション仮想ローカルエリアネットワーク（２１０）などのアプリケーションサーバーサービスと集約される。さらに同様に、データベース（２０４）は、データベース仮想マシン（２０７）及びそのセキュリティグループ（２１５）、及び、セキュアデータベース仮想ローカルエリアネットワーク（２１１）に関連付けられる。ウェブ仮想ローカルエリアネットワーク（２０９）、セキュアアプリケーション仮想ローカルエリアネットワーク（２１０）、及びセキュアデータベース仮想ローカルエリアネットワーク（２１１）はルーター（２１２）に関連付けられる。

したがって、アーキテクチャ由来のトポロジー（２００）のインスタンス化に基づくクラウドサービスを、該トポロジー内の複数のノード間で定義された複数の関係を有するノードのトポロジーとして表すことができる。複数の特性及びアクションは、複数のノード、ノードの複数のグループ、トポロジーの一部、トポロジー全体、または、それらの組み合わせと関連付けられる。さらに、複数のポリシーが、複数のノード、ノードの複数のグループ、トポロジーの一部、トポロジー全体、または、それらの組み合わせと関連付けられる。さらに、複数のライフサイクル管理アクション（ＬＣＭＡ）が、複数のノード、ノードの複数のグループ、トポロジーの一部、トポロジー全体、または、それらの組み合わせと関連付けられる。

したがって、本システム及び方法は、トポロジーと設計図の両方をサポートすると共に、同じライフサイクル管理エンジンを使用するクラウドサービスブローカーまたはマネージャを記述する。ライフサイクル管理エンジンは、クラウドサービスのライフサイクル管理、及び、アプリケーションのモデルとインフラストラクチャのテンプレートのマッピングをサポートする。本システム及び方法はまた、クラウドサービス内の提供（プロビジョニング）プロセス、配置（デプロイ）プロセス、監視プロセス、及び改善プロセスを管理するためのポリシーベースのフレームワークを記述する。さらに、本システム及び方法は、より詳細に後述するように、ＣＳＡ、ＣＤＡ、及び設計図によってサポートされる利用（使用）モデルをサポートする。

本明細書及び特許請求の範囲で使用されている「自律計算」、「自律型コンピューティング」という用語は、予測できない変化に適合する一方で、ユーザー及びオペレータに対して固有の複雑さを隠す分散したコンピューティングリソースの自己管理特性として広義に理解されるべきことが意図されている。自己管理には、自己コンフィグレーション、自己最適化、自己監視、自己改善（自己修復）、自動提供（プロビジョニング）、自動改善、または、それらの組み合わせを含めることができる。

本明細書及び特許請求の範囲で使用されている「ブローカー」という用語は、クラウド内のトポロジーの設計、提供（プロビジョニング）、配置（デプロイ）、及び、そのトポロジーに基づいてインスタンス化されたサービスの維持（ないし保守）及びライフサイクル管理を管理する任意のコンピューティング装置またはコンピューティング装置のネットワーク内のコンピューティング装置の集合として広義に理解されるべきことが意図されている。

本明細書及び特許請求の範囲で使用されている「クラウドサービス」という用語は、リアルタイム通信ネットワークを通じて接続された複数のコンピューティング装置を介して提供される任意の数のサービスとして広義に理解されるべきことが意図されている。クラウドサービスには、分散したハードウェア資源及びソフトウェア資源を実施ないし実装する分散システムで提供されるサービスを含めることができる。１例では、クラウドサービスを、プライベートクラウド、パブリッククラウド、マネージドクラウド、ハイブリッドクラウド、または、それらの組み合わせで提供される任意のサービスとすることができる。別の例では、クラウドサービスを、たとえばデータセンターなどの物理的に独立したマシンで提供されるサービスとすることができる。

本明細書及び特許請求の範囲で使用されている「ハイブリッドクラウド」という用語は、複数のクラウドサービスを提供するために互いに結合された複数の固有のコンピューティングクラウドとして広義に理解されるべきことが意図されている。

さらに、本明細書及び特許請求の範囲で使用されている「ノード」または「コンピューティング装置」という用語は、ネットワーク内の任意のハードウェア装置、仮想デバイス（仮想装置）、ハードウェア装置のグループ、仮想デバイス（仮想装置）のグループ、または、それらの組み合わせとして広義に理解されるべきことが意図されている。ノードには、たとえば、多くのタイプのハードウェア装置及び仮想デバイス（仮想装置）の中でも特に、サーバー、スイッチ、データ処理装置、データ記憶装置、ロードバランサ、ルーター、及び、それらの仮想実施形態を含めることができる。さらに、ノードは、該ノードがその一部であるトポロジーの実行及びインスタンス化の前の上記のハードウェア装置及び仮想デバイス（仮想装置）を表すことができる。

さらに、本明細書及び特許請求の範囲で使用されている「トポロジー」という用語は、ノードのグラフを表すデータとして広義に理解されるべきことが意図されており、この場合、それらのノード間の枝は、該ノード間の関係を表している。それらのノードは、ネットワーク内に配置された任意の数のコンピューティング装置を含むことができる。したがって、ネットワークのトポロジーは、ネットワーク化されたコンピューティング装置の物理的及び論理的レイアウト、及び、コンピューティング装置間の関係の定義を含むことができる。複数のポリシー及びライフサイクル管理アクション（ＬＣＭＡ）を、それらのトポロジー、それらのトポロジーの一部、それらのトポロジー内のノード、それらのトポロジー内のノードのグループ、及び、それらの組み合わせに関連付けることができる。

さらに、本明細書及び特許請求の範囲で使用されている「設計図」という用語は、クラウドサービスの配置（デプロイ）及びクラウドサービスのライフサイクル管理の自動化を可能にする実行フローとして広義に理解されるべきことが意図されている。設計図は、たとえば、オペレーティングシステム、アプリケーションスタック、データベースなどのサービスに含まれる複数のハードウェア及び／又は仮想化された構成要素の機能記述を含むことができる。設計図はさらに、ハードウェアと仮想化された構成要素との間の構成（コンフィグレーション）及び接続性の機能記述を含むことができる。設計図はまた、機能記述を配置（デプロイ）できるようにするための複数の配置モデルを含むことができる。設計図はさらに、ユーザーが、配置（デプロイ）されたサービスのいくつかのオプションの側面を構成ないし設定することができるようにするための一組のユーザー構成可能オプションを含むことができる。設計図は、アーキテクチャ由来ではない実行可能なトポロジーの例である。

さらに、上記の設計図に加えて、本開示は、実行可能なトポロジーの利用を提供する。したがって、本システム及び方法は、設計図由来のトポロジーとアーキテクチャ由来のトポロジーの両方の実行及びインスタンス化を提供する。設計図由来のトポロジーとアーキテクチャ由来のトポロジーは両方とも実行可能である。したがって、本明細書及び特許請求の範囲で使用されている「トポロジー」という用語は、インスタンス化されるネットワークの特性を定義する実行可能なロジックとして表すことができる実行可能なロジックまたは解釈可能なロジックの任意の組として広義に理解されるべきことが意図されている。トポロジーは、複数のノードを定義することができる。さらに、トポロジーは、それらのノードに、複数のグループとしてまたは個々にまたはそれらの組み合わせで関連付けられた複数のポリシー及びライフサイクル管理アクションを定義することができる。１例では、設計図をトポロジーとして表現することができる。この例では、設計図由来のトポロジーはまた、複数のノードと、それらのトポロジー内のノード、それらのトポロジー内のノードのグループ、それらのトポロジーの一部、トポロジー全体、及びそれらの組み合わせに関連付けられた複数のポリシー及びライフサイクル管理アクションとを定義することができる。

さらに、本明細書及び特許請求の範囲で使用されている「ポリシー」という用語は、クラウドサービス内の提供（プロビジョニング）、配置（デプロイ）、監視、実施、及び改善の管理を支援するために使用される任意のデータまたはメタデータとして広義に理解されるべきことが意図されている。それらのポリシーは、クラウドサービス環境内の複数のコンピューティング装置に関連付けられている提供（プロビジョニング）タスク、配置（デプロイ）タスク、監視タスク、実施タスク、及び改善タスクに適用可能な複数のルールまたはルールの組（集合）を表すことができる。

さらに、本明細書及び特許請求の範囲で使用されている「ユーザー」という用語は、任意の個人または（企業などの）エンティティであって、それらの個人またはエンティティのためにまたはそれらの個人またはエンティティによって、クラウドサービスが、設計され、提供（プロビジョニング）され、配置(デプロイ)され、監視され、ポリシーが実施され、インシデントが改善され、その他のやり方で管理され、または、それらの組み合わせが行われるところの個人またはエンティティとして広義に理解されるべきことが意図されている。１例では、ユーザーは、クラウドサービスの使用をある費用で購入することができる。たとえば、ユーザーは、クラウド資源及びサービスを使用するために会費を支払うことができ、この場合、該ユーザーを加入者（または会員）として分類することもできる。別の例では、ユーザーは、クラウドサービスの設計者または管理者でありうる。さらに別の例では、ユーザーは、クラウドサービスを管理する任意の個人でありうる。

さらに、本明細書及び特許請求の範囲で使用されている「複数の」という用語またはこれと類似の用語は、１（１を含む）から無限大までの任意の正の数として広義に理解されるべきことが意図されている（ゼロは数ではなく数がないことを意味する）。

以下の説明では、説明の便宜上、本システム及び方法を完全に理解できるようにするために、多くの特定の細部が説明される。しかしながら、当業者には、本装置、システム、及び方法を、それらの特定の細部なくして実施できることが明らかであろう。本明細書において「１例」またはこれと類似の用語が使用されている場合には、それは、その例に関連して記載されている特定の特徴、構造、または特性が、記載されている通りに含まれるが、他の例には含まれなくてよいことを意味している。

本システムを、たとえば、ネットワーク内の複数のコンピューティング装置の設計、提供（プロビジョニング）、配置（デプロイ）、及び管理を含む該ネットワーク内の任意のデータ処理状況で使用することができる。たとえば、本システムを、複数のコンピューティング装置が、それが実在であれ仮想であれ、サービス志向のネットワーク内で設計され、提供（プロビジョニング）され、配置（デプロイ）され、及び管理されるクラウドコンピューティング状況で使用することができる。別の例では、本システムを、独立型のデータセンターまたはクラウドコンピューティング状況内のデータセンターにおいて使用することができる。サービス志向のネットワークは、たとえば、複数のアプリケーションをホストするＳａａＳ（Software as aService：サービスとしてのソフトウェア）や、たとえば、とりわけ、オペレーティングシステム、ハードウェア、及び記憶装置を含むコンピューティングプラットフォームをホストするＰａａＳ（Platform as a Service：サービスとしてのプラットフォーム）や、たとえば、とりわけ、サーバー、記憶要素、ネットワーク、及び構成要素（コンポーネント）などの装備をホストするＩａａＳ（Infrastructure as a Service：サービスとしてのインフラストラクチャ）や、ＡＰＩａａＳ（API as a Service：クラウド型ＡＰＩサービス）や、その他の形態のクラウドサービス、またはそれらの組み合わせを含むことができる。本システムを、１つまたは複数のハードウェアプラットフォームにおいて実施することができ、この場合、該システム内のモジュールは１つのプラットフォームにおいてまたは複数のプラットフォームにわたって実行される。それらのモジュールを、種々の形態のクラウド技術及びハイブリッドクラウド技術で動作させることができ、または、クラウドにおいてもしくはクラウド外で実施することができるＳａａＳとして提供することができる。

さらに、本システムを、パブリッククラウドネットワーク、プライベートクラウドネットワーク、ハイブリッドクラウドネットワーク、その他の形態のネットワーク、または、それらの組み合わせにおいて使用することができる。１例では、本システムによって提供される方法は、たとえば、サードパーティーによってネットワークを通じたサービスとして提供される。別の例では、本システムによって提供される方法は、ローカル管理者によって実行される。さらに別の例では、本システムを、単一のコンピューティング装置内で使用することができる。このデータ処理状況では、単一のコンピューティング装置は、本明細書に記載されている装置（デバイス）及び関連する方法を利用して、クラウドサービスを配置（デプロイ）し及び該クラウドサービスのライフサイクルを管理することができる。上記の例では、クラウドサービスの設計、該クラウドサービス内の複数のコンピューティング装置及び関連するソフトウェアの提供（プロビジョニング）、設計されて提供されたクラウド資源及びサービスの配置（デプロイ）、該クラウド資源及びサービスの管理、及びそれらの組み合わせを、サービスとして提供することができる。

本開示の例を、システム、方法、またはコンピュータープログラム製品として具現化することができ、及び、本開示の例は、本明細書では一般的に「回路」、「モジュール」、または「システム」と呼ぶ場合がある、もっぱらハードウェアによる実施形態、またはソフトウェアとハードウェアを組み合わせた実施形態の形態を取ることができる。さらに、本開示の例は、コンピューター可読プログラムコードを含む（ないし格納している）複数のコンピューター可読媒体に具現化されているコンピュータープログラム製品の形態を取ることができる。１以上のコンピューター可読媒体の任意の組み合わせを使用することができる。

コンピューター可読媒体を、コンピューター可読信号媒体とは対照的なコンピューター可読記憶媒体とすることができる。コンピューター可読記憶媒体を、たとえば、電子、磁気、光学、電磁、赤外線、もしくは半導体システム／装置／デバイス、または、これらの任意の適切な組み合わせとすることができる。コンピューター可読記憶媒体のより具体的な例は、１以上のワイヤ（電線）を有する電気的接続、携帯型コンピュータディスケット（たとえばフロッピーディスク）、ハードディスク、ランダムアクセスメモリ（ＲＡＭ）、読取り専用メモリ（ＲＯＭ）、消去可能ＰＲＯＭ（ＥＰＲＯＭまたはフラッシュメモリ）、コンパクトディスク読取り専用メモリ（ＣＤ−ＲＯＭ）、光学式記憶装置、磁気記憶装置、または、これらの任意の適切な組み合わせを含むことができる。本開示の文脈において、コンピューター可読記憶媒体を、命令実行システム／装置／デバイスによってまたはそれらに関連して使用されるプログラムを含むことができもしくは格納することができる任意の有形の媒体とすることができる。

本開示を通じて、種々のコンピューティング装置が記述されている。それらのコンピューティング装置は、データ処理装置、データ記憶装置、及びデータ通信装置を含む実在のまたは仮想のコンピューティング要素を含むことができる。それらの種々の装置を、実在する物理的な装置に関連して説明することができるが、任意の数の該装置を仮想装置（仮想デバイス）とすることができる。それらの仮想装置は、エミュレートされたコンピューターアーキテクチャの仕様及び現実世界のコンピューターの機能に基づくソフトウェアベースのコンピューターを記述するものであるが、複数の関連するハードウェア装置を含み、または、それらのハードウェア装置に機能的に接続される。したがって、本開示の側面を、ハードウェア要素、（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）ソフトウェア要素、または、ハードウェア要素とソフトウェア要素の組み合わせによって実施することができる。

いくつかの例では、自己コンフィグレーションは、「配置（デプロイ）する」ための指示または命令に基づいてアプリケーションを配置（デプロイ）し及び該アプリケーションを構成（ないし設定）する該アプリケーションの特性を意味する。たとえば、トポロジーを、配置（デプロイ）及び構成（ないし設定）を決定する複数のポリシーに関連付けることができる。別の例では、トポロジーは、アプリケーションの配置（デプロイ）及び構成（ないし設定）を決定するプロビジョニングロジックを含むことができる。該ロジック、ポリシー、またはそれらの組み合わせはトポロジーと共にパッケージ化される（組み込まれる）ので、それらをクラウド管理システムによって自己配置することができる。かかる自己コンフィグレーションは、ワークフローを実行することを含むことができるが、該ワークフローにおいて、それらのアクションは、サービスを提供するために、クラウド環境の複数のアプリケーションプログラミングインターフェース（ＡＰＩ）をコールする。本明細書で使用されている「トポロジー」は、アプリケーションのトポロジー、及び／又は該アプリケーションを実施しているシステムに関する情報を含むデジタル構造である。

いくつかの例では、アプリケーションを自動提供（自動プロビジョニング）することができる。たとえば、（実行ファイル、トポロジー、該トポロジーに関連付けられたポリシーを含むことができる）アプリケーションを、サービスとしてインスタンス化するべく選択することができる。本明細書で使用されている「サービスをインスタンス化する」ことは、本明細書に記載されているようにクラウドシステムの動作を改善するための実施ないし実装を含む。それらのポリシーは、監視、イベント処理、インシデント処理、及び改善トポロジーを記述するポリシーを含むことができる。それらのポリシーを、配置（デプロイ）するために、図３及び図４に関連して説明されているシステムなどのプラットフォームに渡すことができる。提供（プロビジョニング）ポリシーを、能力及び要件を含む提供（プロビジョニング）ポリシーをコンテキスト情報で評価することができ、及びＬＣＭＡを実行するためにどのリソースプロバイダーを使用するかを決定するためのリソースプロバイダーポリシーを評価することができる提供（プロビジョニング）ポリシーエンジンへの入力とすることができる。

別の例では、アプリケーションを自己提供（自己プロビジョニング）することができる。この例では、ＡＰＩを用いて、図３及び図４のシステムに該ＡＰＩを構築することができる。それらのＡＰＩは、該システムにサービスを提供（プロビジョニング）して最適化させるために実行ファイルすなわちインストール可能な（ソフトウェア）生成物、トポロジー、及びポリシーを渡す。

図３及び図４は、本明細書に記載されている原理の１例にしたがう、クラウドサービスを提供（プロビジョニング）し、配置（デプロイ）し、監視し、保護し、及び改善するための設計段階と共に、トポロジーベースの管理ブローカー（３００）のブロック図を示している。図３及び図４のシステムは、より詳細に後述するように、トポロジーと設計図の両方をサポートする一方で、同じライフサイクル管理エンジンを使用する。

１例では、複数のトポロジーデザイナー（３０１）によって、新たにトポロジー（３０２）を設計することによって、トポロジー（３０２）を生成することができる。この例では、複数の提供（プロビジョニング）ポリシー（３０３）を含むようにトポロジー（３０２）を設計することができる。システム（３００）及びトポロジー（３０２）は、サービス（３１２）をインスタンス化するための特定のやり方を定義する（もしくは定める）ことができる。したがって、インスタンス化されたサービス（３１２）を、インスタンス化されたサービス（３１２）の提供（プロビジョニング）中に自己コンフィグレーション（自己構成ないし設定）することができる。

別の例では、複数のスティッチング法を用いて、複数のアプリケーションモデル（３１９）と複数のインフラストラクチャテンプレート（３２０）をスティッチする（結合する）ことによって、トポロジー（３０２）を生成することができる。この例では、システム（３００）、及び対応する能力ポリシー、要件ポリシー及び提供（プロビジョニング）ポリシーを有するアプリケーションモデル（３１９）は、トポロジー（３０２）に対して最良のインフラストラクチャテンプレート（３２０）を自己選択することができる。この例では、トポロジー（３０２）を自己設計することができる（または、トポロジー（３０２）は自己設計機能を有することができる）。この場合、トポロジー（３０２）は、上記のように、自己コンフィグレーションする、すなわち、サービス（３１２）をインスタンス化するための特定のやり方を定義することができる。

アプリケーションを、自己コンフィグレーション可能なものであることに加えて、自己回復が可能なものとすることができる。自己回復は、サービス（３１２）またはアプリケーションを監視し、メトリクスなどの収集されたデータに基づいて生成されたインシデントを自己改善（ないし自己修正）する該サービス（３１２）または該アプリケーションの能力を意味しうる。いくつかの例では、自己回復は、トポロジー（３０２）に含まれているポリシー（３０３）にしたがって監視し及び改善（ないし修正）することを含むことができる。別の例では、自己回復は、トポロジー（３０２）自体に含まれている改善（ないし修正）ロジック及び監視ロジックを実行することを含むことができる。

図５は、本明細書に記載されている原理の１例にしたがう、図３及び図４のトポロジーベースの管理ブローカー（３００）の共通のプラットフォーム（５００）を高レベルで示すブロック図である。図５に示されているように、ＣＳＡ（５０１）及びＣＤＡ（５０６）の共通のプラットフォームは、サービス設計の側面（５０４）及びサービス実施（サービスフルフィルメント）の側面（５０５）の共通の使用によって表されている。ＣＳＡ（５０１）の場合は、ＣＳＡ（５０１）のセルフサービスポータル（５０２）及びサービス消費（５０３）という側面は、ＣＤＡ（５０６）のＣＤＡ拡張の側面（５０７）が使用するのと同じリソース（資源）を使用する。このように、クラウドサービスをインスタンス化する全ての使用例は、共通のプラットフォームによってサポートされる。したがって、複数のトポロジーデザイナーによって、及び／又は、アプリケーションモデルとインフラストラクチャテンプレートとのスティッチングプロセスによって、トポロジーは新たに設計されうるが、本システム及び方法はまた、本明細書に記載されているシステム及び方法を用いて、同じシステム内で設計図を実行する。以下で、この側面を、図３及び図４に関連してより詳細に説明する。

図３及び図４に示されているように、１つまたは複数のトポロジーデザイナー（３０１）が、クラウドサービストポロジーの種々の側面を設計するのに貢献する。１例では、トポロジー設計は、ハードウェア装置、及びグラフィカルユーザーインターフェース（ＧＵＩ）やコーディングスクリプトなどのソフトウェアモジュールを使用する設計ツールを用いて実行される。（人間である）設計者は、設計ツール（３０１）を用いてトポロジーを設計する。したがって、トポロジー（３０２）の設計は、自律的な設計法と人間によって提供される設計法の組み合わせによって達成される。１例では、トポロジーデザイナー（３０１）を、インフラストラクチャ及び該インフラストラクチャのライフサイクル状態を指定するインフラストラクチャテンプレート（図４の３２０）を生成することと共に、アプリケーションモデル（図４の３１９）とそれに関連する構成要素を個別に生成することを可能にするＡＰＩを利用するインターフェースとすることができる。

トポロジーベースの管理ブローカー（２００）全体のうちの図３に示されているサブシステムは、クラウドサービス内において、ポリシーを提供（プロビジョニング）し、配置（デプロイ）し、監視し、実施し、及び該クラウドサービス内のインシデントを改善（ないし修正）することができるサブシステムを含む。トポロジーが設計図由来であってもアーキテクチャ由来であっても、それらのタスクは全て、ＬＣＭＡ及びポリシーと共にトポロジーを用いて実行される。したがって、本システム及び関連する方法はまた、ＣＳＡ３．２がサポートする全ての使用例をサポートする。上記したように、ＣＳＡ３．２は、クラウドコンピューティングアプリケーションを配置（デプロイ）及び管理するために使用される自動化システムツールであり、ヒューレットパッカード社によって開発されて供給されている。ＣＳＡ３．２技術は、設計図またはアーキテクチャトポロジーをサポートすることができる。さらに、ＣＳＡは、「Managing a Hybrid Cloud Service」と題するMaesに対する国際特許出願ＰＣＴ／ＵＳ２０１２／０４５４２９に記載されている（該出願の内容全体は参照により本明細書に組み込まれるものとする）。より詳細に後述するように、図３に示されているサブシステムは、複数のタイプのポリシー及びライフサイクル管理アクション（ＬＣＭＡ）を使用して、配置（デプロイ）されたクラウドサービス内においてポリシーを提供（プロビジョニング）し、配置（デプロイ）し、監視し、実施し、及び、該クラウドサービス内のインシデントを改善（ないし修正）する。

さらに、トポロジーベースの管理ブローカー（２００）全体のうちの図４に示されているサブシステムは、図３に示されているサブシステムと同じスタックにおいて、トポロジーのインフラストラクチャ及びアプリケーション要件を別個にモデル化することができるサブシステムを含む。本システム及び関連する方法はまた、ＣＤＡ１．２の使用例などのＣＤＡサブシステムがサポートする全ての使用例をサポートする。上記したように、ＣＤＡは、バージョン、構成（コンフィグレーション）、及び他のアプリケーション要素を管理する一方で、インフラストラクチャ要件及びアプリケーション要件を独立にモデル化するトポロジーデザイナー内で使用される自動化システムツールである。ＣＤＡ１．２も、ヒューレットパッカード社によって開発されて供給されている。さらに、ＣＤＡは、「Cloud ApplicationDeployment」と題するMaesに対する国際特許出願ＰＣＴ／ＵＳ２０１２／０４１６２５に記載されている（該出願の内容全体は参照により本明細書に組み込まれるものとする）。

このようにして、図３及び図４のサブシステムは、共通のスタック下で動作し、並びに、トポロジー、実現されているトポロジー、及びポリシーを共通に使用する単一のコンピューティングシステムとしてトポロジーベースの管理ブローカー（２００）内で共に動作して、トポロジーを構成し、及び、複数のプロバイダーの関連する技術をサポートする全ての使用例をサポートする。したがって、１例では、本システム及び方法は、同じスタックにおいて、クラウドサービスの（好ましくはアーキテクチャ由来の）設計されたトポロジー、複数のポリシー、及び、トポロジーノードに関連付けられた複数のＬＣＭＡ、トポロジーノードのサブセット、及び／又は、トポロジーノードの全てのセット（全集合）を利用することによって、ＣＤＡ及びＣＳＡによってそれぞれ使用される異なるモデル、テンプレート及び設計図を両立（ないし調和）させる。

図３に示されているように、トポロジーデザイナー（３０１）は、ライフサイクル管理（ＬＣＭ）トポロジー（３０２）を設計して、それを、トポロジーベースの管理ブローカー（２００）に提示ないし与えることができる。１例では、本明細書に記載されているトポロジーデザイナー（３０１）を、トポロジーベースの管理ブローカー（２００）に一体化された部分とすることができる。別の例では、トポロジーデザイナー（３０１）を、トポロジーベースの管理ブローカー（２００）とは別個のものとすることができる。別の例では、複数の人が、トポロジー（３０２）を設計するためにトポロジーデザイナー（３０１）を使用することができる。それらの個人は、トポロジーの設計の役割を持つ人員の中でも特に、サービスの設計者、インフラストラクチャの設計者もしくは管理者、システム管理者、情報技術オペレータ、オファーマネージャー、またはユーザーでありうる。さらに他の例では、トポロジーデザイナー（３０１）をサードパーティーによって動作させることができる。

ＬＣＭトポロジー（３０２）は、複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）、及び、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）間の複数の関係を定義する（ないし定める）ことができる。図３には７つのノードが示されているが、任意の数のノードをトポロジー（３０２）中に設計して、任意のデータ処理目的を達成することができる。１例では、トポロジーベースの管理ブローカー（２００）は、トポロジー（３０２）を拡張マークアップ言語（ＸＭＬ）ファイルとして表現することができる。別の例では、トポロジーベースの管理ブローカー（２００）は、トポロジー（３０２）をJavaScript Object Notation（JSON：ジェイソン）フォーマット（オブジェクトを表すためのJavaScriptスクリプト言語から得られた人間が読むことができるデータ交換用に設計されたテキストベースのオープンスタンダード）で表すことができる。さらに別の例では、トポロジーベースの管理ブローカー（２００）は、トポロジー（３０２）を、人間が読むことができるデータシリアライゼーションフォーマットであるＹＡＭＬ構文フォーマットで表すことができる。

図３では、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）間の関係は、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）を接続する線として示されている。ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の各々、トポロジー（３０２）全体、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のグループ、トポロジー（３０２）の一部、または、それらの組み合わせは、複数のポリシー（３０３）に関連付けられる。ポリシー（３０３）は、ノードもしくはトポロジーを記述する同じファイル内、または、該ノードもしくはトポロジーに関連付けられているファイル内に提供されるデータもしくはメタデータである。１例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、たとえば、トポロジー（３０２）の設計を提示した場合に、管理者によって該トポロジー（３０２）の設計中に実行することができる。別の例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、ユーザーが、たとえば、購入または要求としてトポロジー（３０２）の設計を選択した場合に、該トポロジー（３０２）の設計中に実行することができる。いくつかの実施形態では、ポリシー（３０３）を、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の各々に関連付けることができる。たとえば、ポリシー（３０３−１、３０３−２、３０３−３、３０３−４、３０３−５、３０３−６、３０３−７）を、対応するノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に割り当てることができる。本明細書にさらに記載されているように、ポリシー（３０３−１、３０３−２、３０３−３、３０３−４、３０３−５、３０３−６、３０３−７）は、たとえばアプリケーション及び／又はトポロジーに関連付けられた、アプリケーションのステージ（段階）及びバージョンを含むことができる。少なくとも１つの例において、本明細書で使用されている「ステージ」（段階）という用語は、アプリケーション開発及び／又は配置（デプロイ）のテスト、試作、及び製作の段階を意味することが意図されている。いくつかの実施形態では、トポロジー（３０２）を実現された（すなわち実現済の）トポロジーとすることができる。実現されたトポロジーは、トポロジー（３０２）を使用するエンティティによって生成されたトポロジー（３０２）でありうる。

ポリシー（３０３）は、ノードもしくはトポロジーを記述する同じファイル内、または、該ノードもしくはトポロジーに関連付けられているファイル内に提供されるデータもしくはメタデータである。１例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、たとえば、トポロジー（３０２）の設計を提示した場合に、管理者によって該トポロジー（３０２）の設計中に実行することができる。別の例では、トポロジー（３０２）内のポリシー（３０３）の関連付けを、ユーザーが、たとえば、購入または要求としてトポロジー（３０２）の設計を選択した場合に、該トポロジー（３０２）の設計中に実行することができる。

いくつかの実施形態では、ポリシー（３０３）を、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の各々に関連付けることができる。いくつかの実施形態では、ポリシー（３０３）を、図４に示されているように、複数のアプリケーションモデル（３１９）の各々に関連付けることができる。さらに、いくつかの実施形態では、ポリシー（３０３）を、図４に示されているように、複数のインフラストラクチャテンプレート（３２０）の各々に関連付けることができる。たとえば、ポリシー（３０３−１、３０３−２、３０３−３、３０３−４、３０３−５、３０３−６、３０３−７）を、対応するノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に割り当てることができる。本明細書にさらに記載されているように、ポリシー（３０３−１、３０３−２、３０３−３、３０３−４、３０３−５、３０３−６、３０３−７）は、アプリケーションのステージ及びバージョンを含むことができる。

本明細書にさらに記載されているように、トポロジー及び／またはシステムの管理者及び／または開発者に通知するために、通知ポリシーを利用することができる。より詳細に後述するように、いくつかの実施形態では、それらの通知を、インシデントのタイプに基づいて特定のユーザー及び／又はシステムに送るように指定することができる。

さらに、１例では、トポロジーまたはトポロジーの一部にポリシー（３０３）を加えることによって、該トポロジーの設計（ないし構成）を変えることができる。この例では、トポロジー（３０２）の要素に加えられたポリシー（３０３）は、複数の他のポリシーに影響を与えうる。たとえば、あるノードの可用性が高いことを示すポリシーのトポロジー（３０２）への関連付けは、たとえば一群のノードを要求するために、ポリシー（３０３）及びトポロジー（３０２）を全体として発展させうる。このようにして、ポリシーはトポロジー（３０２）の設計を駆動することができる。

ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の各々、トポロジー（３０２）全体、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のグループ、トポロジー（３０２）の一部、またはそれらの組み合わせは、さらに、複数のライフサイクル管理アクション（ＬＣＭＡ）（３０４）に関連付けられる。ＬＣＭＡ（３０４）がそれらのノードに関連付けられる例では、単一のＬＣＭＡが所与の１つのノードに関連付けられる。複数のＬＣＭＡがトポロジー（３０２）の一部またはトポロジー（３０２）全体に関連付けられる例では、それらのＬＣＭＡは、リソースプロバイダーの調整（オーケストレーション）を受ける。

ＬＣＭＡは、複数のアプリケーションプログラミングインターフェース（ＡＰＩ）として表され、この場合、それらのＬＣＭＡは、トポロジー（３０２）の実行中に呼び出され（コールされ）、及び、複数のコンピューティング資源が、所与のクラウド能力のライフサイクルを管理するために提供される。１例では、アプリケーションプログラミングインターフェース（ＡＰＩ）を実行するために、該ＡＰＩのＵＲＩ（uniform resource identifiers）を介してそれらのＬＣＭＡにアクセスして呼び出し（コール）を実行することができる。１例では、それらのＬＣＭＡは、ポリシー（３０３）に関連して上記したデータまたはメタデータを含むファイル内の参照によって提供される。

１例では、それらのＬＣＭＡは、デフォルトでは、１つのノードまたは複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）が表しているコンピューティング装置に基づいて、トポロジーの側面に関連付けられる。別の例では、それらのＬＣＭＡは、トポロジーの側面に関連付けられたポリシー、及び異なる関連する（もしくは適切な）リソースプロバイダーのポリシーに基づいてアクションを実行するために、リソースプロバイダーをどのようにして選択するかを定義する（ないし定める）複数の機能（もしくは関数）Ｆ_Actionを明示的に提供することによって該トポロジーの側面に関連付けられる。それらの機能（もしくは関数）は、該トポロジーの側面に関連付けられたポリシー、及び該異なる関連する（もしくは適切な）リソースプロバイダーのポリシーに基づいてアクションを実行するために、リソースプロバイダーをどのようにして選択するかを定義する（ないし定める）。

本明細書では、ポリシー（３０３）及びＬＣＭＡ（３０４）が、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）、トポロジー（３０２）全体、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のグループ、トポロジー（３０２）の一部、またはそれらの組み合わせに関連付けられることを示すために、ポリシー及びＬＣＭＡは、要素３０３及び３０４でそれぞれ示されている。１例では、ポリシー及びＬＣＭＡとトポロジーの側面との関連付けは、トポロジーデザイナー（３０１）を介して実行される。

図示されていないが、１例では、グループを構成するノードのサブセット（部分集合）を、複数のポリシー（３０３）及び複数のＬＣＭＡ（３０４）に関連付けることもできる。この例では、複数のノード、たとえば、ノード（３０２−２、３０２−３、３０２−４、３０２−６、３０２−７）を、複数のポリシー（３０３）及びこれに関連付けられている複数のＬＣＭＡ（３０４）にグループとして関連付けることができる。ノードのいくつかのグループ分けがトポロジー（３０２）全体内に存在しうる。１例では、ノードのグループは（部分的に）重なり合っていてもよく、その場合、ノードの第１のグループ内のある１つのノードが、ノードの第２のグループにも属して、それらの第１及び第２のグループの両方のポリシー（３０３）及びＬＣＭＡ（３０４）に従うという場合がある。ポリシー、及びポリシーと個々のノード及びノードのグループとの関連付けについては、より詳細に後述する。

ノードに関連付けられたポリシー（３０３）を、任意のやり方で、表現して、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に結び付けることができる。１例では、ポリシー（３０３）は、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の特性を定義する（ないし明らかにする）ことによって、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられる。別の例では、ポリシー（３０３）は、メタ言語表現によって、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられる。

ポリシー（３０３）は、トポロジー（３０２）が実装されることになるかまたは実装されているクラウドサービス環境内の複数のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）のライフサイクル管理に関連付けられた提供（プロビジョニング）タスク、監視タスク、実施タスク、管理タスク、及び改善（ないし修正）タスクをガイドする（たとえば、これらのタスクが該ポリシーにしたがうようにする）のに適用可能な複数の記述、メタデータ、ワークフロー、スクリプト、ルール、または、ルールの組（集合）である。ポリシー（３０３）は、トポロジーベースの管理ブローカー（２００）のＡＰＩのアクセス制御及び使用（利用）制御を定義する（ないし定める）。さらに、ポリシー（３０３）は、インスタンス化されたサービスを管理または使用するために使用されるＡＰＩのアクセス制御及び使用制御を定義する（ないし定める）。たとえば、監視システム（３１３）によってセキュリティ上の脅威が検出されたときは、改善（ないし修正）オプションは、複数のアクセス制御ポリシーを変更することができる（または該変更することを含むことができる）。

ポリシー（３０３）を、クラウドサービスのトポロジー全体内の複数の個々のノード、ノードの複数のグループ、ノードのクラスの複数のノード、ノードのサブセット、または、クラウドサービスのトポロジー全体、またはそれらの組み合わせに関連付けて、それらに対して動作可能とすることができる。ポリシー（３０３）が、個々のノード、ノードのグループ、またはクラウドサービスのトポロジー全体に対して作動すると、該ポリシーは、クラウドサービスのトポロジー全体内の個々のノード、ノードのグループ、ノードのクラスのノード、ノードのサブセット、または、クラウドサービスのトポロジー全体に対してライフサイクル管理アクションをどのように行うかすなわちどのように実行するかをガイドする。

１つのタイプのポリシーの１例は、アプリケーションのステージ及びバージョン、及び／又はトポロジー内のノードを含むプロビジョニングポリシーである。プロビジョニングポリシーは、実行されると、トポロジーが提供（プロビジョニング）され、配置（デプロイ）され、及び実行されるときに、該トポロジーに関連付けられたクラウドを構成するアプリケーションのテスト、試作、及び／又は製作の特性を定義する（または明らかにする）。このプロビジョニングは、インフラストラクチャ及びトポロジー（３０２）のプラットフォームを含むことができる。プロビジョニングポリシーは、たとえば、ノードの物理的な位置などの特性の定義を含むことができる。プロビジョニングポリシーはまた、たとえば、地理的なまたは配置タイプのプロビジョニングポリシーの中でも特に、インターネットへのアクセスの有無にかかわらず、またはファイアウォールの使用の有無にかかわらず、ネットワークゾーンなどの地理的な位置または配置タイプの位置などの特性の定義を含むことができる。この例では、ポリシーは、サーバー装置に関連付けることができるプロビジョニングポリシー要素であって、該サーバー装置が、ある国の特定の地理的領域、たとえば、米国の西海岸に対する東海岸などの特定の領域、または、特定のサーバー設備、または他の任意の地理的な位置に配置されることを要求するプロビジョニングポリシー要素を有することができる。

該ステージ及びバージョンポリシーは、特定のステージ及び／又はバージョンに固有の定義及び／又はガイド（たとえば、ステージ及びバージョンポリシーなど）を含むことができる。たとえば、第１のポリシーは、アプリケーションの第１のバージョンに対応する定義及び／又はガイドを含むことができ、第２のポリシーは、該アプリケーションの第２のバージョンに対応する定義及び／又はガイドを含むことができる。この例では、該アプリケーションの該第１のバージョンを、該アプリケーションの初期のバージョンとすることができ、該アプリケーションの該第２のバージョンを、該アプリケーションの該初期のバージョンよりも後で開発された（すなわちより進歩したバージョン）とすることができる。該定義及び／又はガイドは、対応するステージに対して利用できるインフラストラクチャや位置などの情報を含むことができる。さらに、該定義及び／又はガイドは、該対応するステージに対して利用できるトポロジーレイヤなどの情報を含むことができる。たとえば、該情報は、どのようなレイヤがアプリケーションのトポロジーを満たすか、及び／又は、該アプリケーションの対応するバージョンが利用できるのはどのレイヤかを含むことができる。

いくつかの実施形態では、トポロジー（３０２）、及び／又は該ステージ及びバージョンポリシー（３０３）の設計を、コード（たとえば、ＹＡＭＬ、ＴＯＳＣＡＹＡＭＡＬプロファイル）で書くことができる。これは、いくつかの従来の方法及びシステムは、トポロジー（３０２）を設計し、及びポリシー（３０３）を設計するためにデザイナーを用いる点で、従来の方法及びシステムとは異なり得る。

いくつかの実施形態では、ステージまたはバージョンに関する情報（たとえば、ステージ及びバージョンポリシー内の情報など）を、トポロジー（３０２）及びポリシー（３０３）に基づいてアプリケーションを提供（プロビジョニング）し及び／又は管理するための要求と共に送ることができ、及び／又は該要求に向けることができる。いくつかの実施形態では、提供（プロビジョニング）し及び／又は管理するための該要求を、開発ツールチェーンからのものとすることができる。たとえば、提供（プロビジョニング）し及び／又は管理するための該要求を、アプリケーションの開発に関わる別のフロー（たとえば、テスト（試験）をパスした後の、ＩＤＥ、エクリプスプラグイン（eclipse plug-in）を含むツールなど）からトリガすることができる。提供（プロビジョニング）し及び／又は管理するための要求を含むそれらの実施形態を、継続的インテグレーション（ＣＩ）及び／又は継続的デリバリー（ＣＤ）チェーンの一部とすることができるため、それらの実施形態は従来の方法及びシステムに対して有利でありうる。

ステージ及びバージョンポリシー（３０３）はまた、インスタンスを配置（デプロイ）するために使用することができるＤＳＬ及び／又は生成物（アーティファクト）のリポジトリ（repository of artefact）を指示するために用いることができる情報を含むことができる。いくつかの実施形態では、開発者が、実現されたトポロジーの管理のために、コード（たとえば、ＡＰＩ用のコードにおける呼び出し（コール）など）を用いて、該実現されたトポロジーのＬＣＭを利用できるようにすることができる。いくつかの実施形態では、ステージ及びバージョンポリシー（３０３）を、他のポリシー（３０３）または管理プランをどのように実行するかを決定するために用いることができる。たとえば、異なるステージ及び／又はバージョンのアプリケーションの異なる側面を監視するために決定を行うことができる。たとえば、アプリケーションの第１のステージでは、ステージ及びバージョンポリシー（３０３）は、該アプリケーションの全動作及び使用状況を監視するための情報を含むことができる。この例では、該アプリケーションの第２のステージでは、ステージ及びバージョンポリシー（３０３）は、該アプリケーションの全動作及び使用状況を監視するのをやめるための情報を含むことができる。

コンピューティング装置（たとえば、記憶装置やネットワーキングなど）の物理的な位置を定義する（ないし明らかにする）プロビジョニングポリシーに関して、他の特性は、たとえば、該位置のセキュリティのレベル、または、ノードが配置されているインターネットへのアクセスを含むことができる。他のプロビジョニングポリシーはまた、たとえば、いくつかあるプロビジョニングポリシーの中でも特に、ノードが、たとえば、非武装地帯（ＤＭＺ）または境界ネットワークなどのインターネットまたはイントラネットに接続されることになるか否か、ノードがファイアウォールで保護されているか否か、ノードがインターネットにアクセスできるか否か、ノードが別のノードの最上位に配置されることになるか否か、及び、ノードが特定のインフラストラクチャ要素またはプラットフォームを用いて別のノードの最上位に配置されることになるか否かに関係なく、該ノードが結合されているネットワーク内の速度、たとえば該ネットワークの帯域幅を含むことができる。

プロビジョニングポリシーはまた、実行されると、トポロジー（３０２）に基づく提案されたクラウドサービス内のノードの要件及び能力に依存しうる。要件は、いくつかある要件（必要性）の形態の中でも特に、たとえば、処理、メモリ（記憶装置）、及びオペレーティングシステム（ＯＳ）の要件に関連するサーバーまたはネットワーク要件などのノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の要件を定義する（ないし明らかにする）。たとえば、要件ポリシーは、ノードが、特定のオペレーティングシステムなどの該ノードに関連付けられている特定のソフトウェアまたは特定のソフトウェアバージョンを必要とすることを示すことができる。別の例では、要件ポリシーはまた、特定のノードが、該ノードに関連付けられている追加のハードウェア装置（たとえば、特に、サーバー装置、サーバー群、または可用性の高い構成など）を必要としうることを示すことができる。

とりわけ、プロセッサの特性、メモリ、容量、ＯＳ、ミドルウェアのタイプ及びバージョンなどの能力は、それぞれのノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）が何を提供するかを定義する（ないし明らかにする）。したがって、１例では、能力ポリシーは、ノードが、ある所定の速さ（速度）でデータを処理できることを示すことができる。別の例では、能力ポリシーは、メモリデバイス（記憶装置）が１テラバイト（ＴＢ）のデータ記憶空間を有することができることを示すことができる。

さらに別の例では、要件ポリシーは、ノードが、特定のコンピューティングプラットフォームを必要とすることを示すことができる。トポロジー（３０２）を設計するときに、該トポロジーまたはメタデータの関連付けは、ハードウェアアーキテクチャ及び（アプリケーションフレームワークを含む）ソフトウェアフレームワークを含むコンピューティングプラットフォーム内の複数のハードウェア装置を定義する（ないし明らかにする）データを取得することをサポートする。該メタデータが与えられるかまたは関連付けられると、該メタデータを用いて、たとえば適切なデータセンターなどのコンピューティングプラットフォーム内の適切な要素をより良好に選択するために、プロビジョニングポリシーをガイドする。インフラストラクチャテンプレートへのアプリケーションモデルのスティッチングに関連してより詳細に後述するように、該メタデータが与えられるかまたは関連付けられると、該メタデータを用いて、トポロジーのフラグメントと他のフラグメントとのマッチングをガイドすることもできる。

能力ポリシーに関しては、ノードは、該ノードがどのような種類の装置（またはデバイス）であるか、該ノードが実行できるまたは実行しているソフトウェアのバージョンは何か、及び、該ノードは何をすることができるかを定義する（または明らかにする）ことができる。能力ポリシーの１例は、多くの能力の中でも特に、ノードをアプリケーションサーバーとして定義ないし明らかにし、または、ノードが、Java Platform（ジャバプラットフォーム）、EnterpriseEdition（Ｊ２ＥＥ）環境を提供し、または、ノードが、特定のオペレーティングシステムもしくはあるバージョンのオペレーティングシステムもしくは特定のリリースされたあるバージョンのオペレーティングシステムを動作させるという、該ノードに関連付けられた定義を含むことができる。上記のように、これを用いて、たとえば、他に何かを配置（デプロイ）することができるか、または、他のどのような装置がクラウドサービスを使用できるかを決定することができる。

割り当てることができる別のタイプのポリシー（３０３）には監視ポリシーがある。監視ポリシーは、実行されると、いくつかのタイプの監視に関連するポリシーの中でも特に、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）の動作状況の監視、ノードのセキュリティ監視、ノードのステージ及びバージョンの監視、ノード間及びノードのグループ間の分析、ノードの使用（状況）監視、パフォーマンス監視、及び、たとえば、メトリクスの収集、ビジネスインテリジェンス（ＢＩ）、ビジネスアクティビティ監視（ＢＡＭ）及び分析／ビッグデータデータ統合などのインテリジェンス監視を定義する（ないし明らかにする）ポリシーである。

監視ポリシーはまた、どのような種類の監視が期待されているか、及び、監視をどのように実施するかを定義する（ないし明らかにする）ことができる。ノード動作に関する監視ポリシーの例には、ノード、ノードのグループ、及びクラウドサービス全体の多くの動作パラメータの中でも特に、ネットワーク内の種々のノードのパフォーマンス（性能など）、ＣＰＵレベル及び負荷を監視すること、データが１つまたは複数のノードによって処理される速度またはデータをノード間で交換する速度を監視すること、及び、ネットワークの任意のレベルにおける１つまたは複数のノードで動作しているアプリケーションの動作状態を監視することが含まれる。

別の例では、監視ポリシーはまた、インスタンス化されたトポロジー内で生じた監視されたイベントをどのように処理するかを定義する。この例では、監視ポリシーは、該イベントを受け取って処理すること、該イベントから生じるインシデントの改善に関する決定をすること、及び、該インシデントに関する通知メッセージを送ることに関してイベントハンドラ（３１６）を支援する。トポロジーベースの管理ブローカー（２００）内のイベントの処理についてはより詳細に後述する。より詳細に後述するように、監視ポリシーは、監視から得られた監視されたイベントへの対処の仕方、たとえば、該イベントをどのように処理するか、該イベントをどこに送るか、どのような装置または個人が該イベントに対処するか、該イベントの処理から生じたインシデントをどのように処理するか、該イベント及びインシデントをどのように処理するか（たとえば、いくつかある処理の形態の中でも特に、イベントを集め、イベントをフィルタリングし、または、イベントを相互に関連付けるやり方）、及び、結果として生じたインシデントをどのように処理するかなどを定義する部分を含む。

監視ポリシーはまた、セキュリティに関する監視ポリシーを含む。セキュリティポリシーは、既知のもしくは疑わしいセキュリティ問題に関連しているものとして既知の異常な挙動をどのように監視するかを定義する。セキュリティに関する監視ポリシーの例には、いくつかあるセキュリティに関する監視ポリシーの中でも特に、ノードまたはノードのグループが攻撃を受けているか否か、クラウドサービス内で起こる奇妙な挙動またはクラウドサービスへの干渉の有無、及び、ノードまたはノードのグループにウィルスまたはその他の異常があるか否かを監視することが含まれる。

監視ポリシーはまた、使用に関する監視ポリシーを含む。使用に関する監視ポリシーの例には、いくつかある使用に関連する監視ポリシーの中でも特に、どれだけ多くのユーザーがノードまたはノードのグループのＣＰＵを使用しているかを判定すること、どれだけの量のメモリ（記憶装置）をユーザーが利用しているかを判定すること、どれだけ多くの金額がユーザーに課金されているかを判定すること、ユーザーが、ネットワークトポロジーの設計、提供（プロビジョニング）、配置（デプロイ）、及び監視にわたるサービス提供に対して料金を支払ったか否かを判定することが含まれる。

さらに、ポリシー（３０３）は、実行されると、トポロジー（３０２）またはクラウドサービス内のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）またはノードのグループのアクセス制御を定義する管理ポリシーを含むことができる。たとえば、管理ポリシーは、トポロジー（３０２）またはクラウドサービス内のノードに誰がアクセスすることができるか、及び、どのような条件の下で、それらの個人がそのようなアクセスを得ることができるかを定義するポリシーを含むことができる。

さらに、ポリシー（３０３）は、実行されると、トポロジー（３０２）内のノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）内またはそれらのノード間、または、ノードのグループ内またはノードのグループ間の分析及びビッグデータ監視を確保するために必要なもの、及び、これが予想通りに起こることを確保するために必要なものを定義する分析ポリシーを含むことができる。たとえば、分析ポリシーは、複数のワークフローを定義することができ、この場合、監視システム（３１３）は、該ワークフローによって、クラウドサービスを構成ないし設定し、分析を提供し、ビッグデータを収集し、及び、該データを処理するように動作することができる。

さらに、ポリシー（３０３）は、トポロジー（３０２）の配置（デプロイ）及び実行中に問題またはインシデントが発生した場合に、トポロジー（３０２）内で行われるべきアクションを定義する（または定める）改善ポリシーを含むことができる。改善ポリシーは、改善プロセス中に、トポロジーベースの管理ブローカー（２００）によって取られる複数のアクションを定義するポリシーを含むことができ、及び、（１）ユーザー、購入者、または管理者に通知を提供すること、（２）該ユーザー、購入者、または管理者からの命令を取得すること、（３）該ユーザー、購入者、または管理者によって入力された手動アクションを行うこと、（４）該ユーザー、購入者、または管理者からの命令を受け取った後に自律的なアクションを行うこと、（５）該ユーザー、購入者、または管理者からの命令を受け取ることなく自律的なアクションを行うこと、（６）該ユーザー、購入者、または管理者に通知することなく、または、該ユーザー、購入者、または管理者から命令を受け取ることなく、自律的なアクションを行うこと、（７）ユーザーまたは管理者に、承認を得るために改善アクションを提案して、該ユーザーまたは管理者またはそれらの組み合わせによって承認された場合には、該提案した改善アクションを実行すること、を含むことができる。

１例として、トポロジー（３０２）によってインスタンス化または実現されたクラウドサービスの障害が発生する場合があり、改善ポリシーは、上記の可能性のあるシナリオに基づいてその障害を処理できる方法を定義することができる。さらに、改善ポリシーは、任意の数の条件の下でインシデントを改善ないし修正するために実行すべき実際のルール及びアクションのワークフローを提供し、または、それらの改善アクションを行うことを決定し、該アクションの調整（オーケストレーション）及び実施（フルフィルメント）を行う権限を誰にまたはどの装置に委ねるかを示す。別の改善の例は、たとえば、トポロジー（３０２）に基づいて実現されたクラウドサービス内のサービス内容合意書（ＳＬＡ）またはサービス品質（ＱｏＳ）に基づいてサービスのレベルを維持する潜在的な必要性を考慮することができる。この例では、リソース（資源）の要求の増加をサポートするためのリソースの追加を、上記の可能性のあるシナリオに基づいて処理することができる。配置（デプロイ）されたトポロジーの監視及びイベント処理については、より詳細に後述する。

上記のように、ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）は、該ノード（３０２−１、３０２−２、３０２−３、３０２−４、３０２−５、３０２−６、３０２−７）に関連付けられた複数のライフサイクル管理アクション（ＬＣＭＡ）（３０４）を含むことができる。該ＬＣＭＡ（３０４）は、トポロジー（３０２）が実施されるクラウドサービス環境内のポリシー（３０３）によって起動されたときにプロセッサによって実行される、ポリシー（３０３）に関連付けられた複数のアクションである。該ＬＣＭＡを、クラウドサービスのトポロジー全体内の複数の個々のノード、ノードの複数のグループ、ノードのクラスの複数のノード、ノードのサブセット、または、クラウドサービスのトポロジー全体、またはそれらの組み合わせに関連付けて、それらに対して動作可能とすることができる。該ＬＣＭＡが、個々のノード、ノードのグループ、またはクラウドサービスのトポロジー全体に対して実行されると、該ＬＣＭＡは、該ＬＣＭＡ内で定義されているように、クラウドサービスのトポロジー全体内の個々のノード、ノードのグループ、ノードのクラスのノード、ノードのサブセット、または、クラウドサービスのトポロジー全体に対してアクションを取る。ＬＣＭＡ（３０４）は、いくつかあるライフサイクル管理アクションの中でも特に、たとえば、トポロジー内のコンピューティング資源の提供（プロビジョニング）、該トポロジーの更新、該トポロジーの全てもしくは一部の複製、該トポロジー内のコンピューティング資源の修正（ないし変更）、該トポロジー内でのコンピューティング資源の移動、該トポロジー内のリソースの破壊（ないし無効化）もしくは抹消などのアクションを含む。

本明細書に記載されている種々のポリシーは、トポロジー（３０２）に基づくサービスのインスタンス化の前、該インスタンス化中、及び該インスタンス化の後にトポロジー（３０２）のライフスタイルを通じてどのようなアクションが実行されるかを定義する（ないし定める）。さらに、本明細書に記載されている種々のポリシーは、それらのアクションをどのように実行するかを定義する。さらに、本明細書に記載されている種々のポリシーは、それらのアクションの権限をどの装置（もしくはデバイス）、またはどの個人、またはそれらの組み合わせのどれに委ねるかを定義する（ないし定める）。さらに、本明細書に記載されている種々のポリシーは上記の組み合わせを定義する（ないし定める）。たとえば、イベントの操作及び処理、または改善で使用される任意の監視ポリシーは、クラウドサービスのどのような装置（もしくはデバイス）または部分を監視しまたは改善（ないし修正）するか、または、そのような監視及び改善（ないし修正）をどのように実行するか、または、誰にもしくはどのような装置（もしくはデバイス）に、監視、及び改善（ないし修正）、またはそれらの組み合わせの役割を委ねるかを定義する（ないし定める）ことができる。

図６は、本明細書に記載されている原理の１例にしたがう、トポロジーを設計する方法を示すフローチャートである。図６の方法は、アプリケーションモデル（図４の３１９）を生成するステップ（ブロック６３０）から開始することができる。１例では、トポロジーデザイナー（３０１）を用いて、アプリケーションモデル（図４の３１９）を設計して作成し、このようして、アプリケーションモデル（図４の３１９）を生成することができる。別の例では、アプリケーションモデル（図４の３１９）を、いくつかあるアプリケーションモデル（図４の３１９）のソースの中でも特に、たとえば、カタログ（図３の３１０）、ＲＴＳＭ（図３の３１５）、またはＤＳＬデータベース（図４の３２３）などの複数のアプリケーションモデル（図４の３１９）のソースから得ることができる。アプリケーションモデル（図４の３１９）は、ライフサイクル管理トポロジーによって定義される。ＬＣＭトポロジー（図３の３０２）に関連して本明細書に記載されているように、アプリケーションモデル（図４の３１９）は、複数のノード（図４の３１９−１、３１９−２、３１９−３）を含む。

アプリケーションモデルを生成するステップ（ブロック６３０）は、自己管理、自動管理、またはそれらの組み合わせとしてアプリケーションを設計するステップ（ブロック５３２）を含むことができる。複数のインフラストラクチャテンプレート（図４の３２０）を生成することもできる（ブロック５３４）。１例では、トポロジーデザイナー（３０１）を用いてインフラストラクチャテンプレート（図４の３２０）を設計して作成することができる。別の例では、インフラストラクチャテンプレート（図４の３２０）を、いくつかあるインフラストラクチャテンプレート（図４の３２０）のソースの中でも特に、たとえば、カタログ（図３の３１０）、ＲＴＳＭ（図３の３１５）、またはＤＳＬデータベース（図４の３２３）などの複数のインフラストラクチャテンプレート（図４の３２０）のソースから得ることができる。インフラストラクチャテンプレート（図４の３２０）は、ライフサイクル管理トポロジーによって定義される。ＬＣＭトポロジー（図３の３０２）に関連して本明細書に記載されているように、インフラストラクチャテンプレート（図４の３２０）は、複数のノード（図４の３１９−１、３１９−２、３１９−３）を含む。１例では、複数の人が、トポロジーデザイナー（３０１）を用いて、アプリケーションモデル（図４の３１９）及びインフラストラクチャテンプレート（図４の３２０）を設計することができる。それらの個人は、トポロジーの設計の役割を持つ人員の中でも特に、サービスの設計者、インフラストラクチャの設計者もしくは管理者、システム管理者、情報技術オペレータ、オファーマネージャー、またはユーザーでありうる。

複数のアプリケーションモデル（図４の３１９）が、複数のインフラストラクチャテンプレート（図４の３２０）にスティッチ（結合）される（ブロック９０３）。１例では、スティッチングエンジン（図４の３２１）は、たとえば、ＤＳＬデータベース（図４の３２３）、またはインフラストラクチャテンプレート（３２０）の他のソースに格納されている複数のインフラストラクチャトポロジー（図４の３２０）を取得して、複数のアプリケーションモデル（図４の３１９）を複数の適切なインフラストラクチャテンプレート（図４の３２０）にスティッチすることができる。別の例では、インフラストラクチャテンプレート（図４の３２０）を、複数のトポロジーデザイナー（３０１）によって新たに設計することができる。

スティッチングエンジン（図４の３２１）は、アプリケーションモデル（図４の３１９）（及び／又はインフラストラクチャテンプレート（図４の３２０））に関連付けられたポリシー及びＬＣＭＡに基づいて、任意のタイプの方法を用いて、アプリケーションモデル（図４の３１９）をインフラストラクチャテンプレート（図４の３２０）にスティッチ（結合）することができる。１例では、スティッチングエンジン（図４の３２１）は、マッチング処理を使用することができ、該処理において、スティッチングエンジン（図４の３２１）は、アプリケーションモデル（図４の３１９）のノード（図４の３１９−１、３１９−２、３１９−３）に関連付けられたポリシー、要件、及び能力を、インフラストラクチャテンプレート（図４の３２０）のノード（図４の３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）のポリシー、要件、及び能力とマッチングさせる。この例では、スティッチングエンジン（図４の３２１）は、本明細書に記載されているテンプレートソースを閲覧ないし調べて、マッチングまたはほぼマッチングする状態を見出すことができる。マッチングが見つかると、スティッチングエンジン（図４の３２１）は、アプリケーションモデル（３１９）の複数のノード（図４の３１９−１、３１９−２、３１９−３）を、マッチングするインフラストラクチャテンプレート（図４の３２０）の複数のノード（図４の３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）にマッチングさせる。

アプリケーションモデル（図４の３１９）をインフラストラクチャテンプレート（図４の３２０）にスティッチするためにスティッチングエンジン（図４の３２１）が使用することができる別の方法は、アルゴリズム的マッチング法を含むことができる。この方法では、スティッチングエンジン（図４の３２１）は、マッチング判定を実行する際にポリシーを利用するアルゴリズムを用いて数学的に判定を行う。１例では、これは推論手法を含むことができ、該方法において、アプリケーションレベルにおける要件が、ＤＳＬデータベース（図４の３２３）内のそれらの要件をサポートする構成要素にタグ付けされるかまたは他のやり方で関連付けられ、この場合、インフラストラクチャトポロジー（図４の３２０）全体が先ず統合された後に、該統合が、アプリケーションモデル（図４の３１９）に拡張される。

複数のポリシー及びライフサイクル管理アクション（ＬＣＭＡ）は、アプリケーションモデル（図４の３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付けられる。１例では、複数のポリシー（３０３）及びＬＣＭＡ（３０４）とアプリケーションモデル（３１９）及びインフラストラクチャトポロジー（３２０）のノード（３１９−１、３１９−２、３１９−３、３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）との関連付けを、トポロジーデザイナー（３０１）、セルフサービスポータル（３０９）、及びリソースオファリングマネージャ（３０８）の各々によって（単独で）、または、それらの組み合わせによって実行することができる。別の例では、本明細書に記載されているように、アプリケーションモデル（３１９）及びインフラストラクチャトポロジー（３２０）のノード（３１９−１、３１９−２、３１９−３、３２０−１、３２０−２、３２０−３、３２０−４、３２０−５）を、ポリシー（３０３）及びＬＣＭＡ（３０４）に関連付けるために、別個のポリシーエンジン及びＬＣＭＡエンジンを設けることができる。

１例では、ポリシー（３０３）及びライフサイクル管理アクション（ＬＣＭＡ）（３０４）を、アプリケーションモデル（３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付ける処理を、ブロック６３６に関連して記載されているスティッチングプロセスの前、該プロセス中、または該プロセスの後に実行することができる。ポリシー及びＬＣＭＡがブロック６３４のスティッチングプロセスの前に関連付けられる例では、ポリシー（３０３）及びＬＣＭＡ（３０４）を、アプリケーションモデル（３１９）及びインフラストラクチャトポロジー（３２０）内の複数のノードもしくはノードのグループに、並びに、アプリケーションモデル（３１９）全体及びインフラストラクチャトポロジー（３２０）全体に、関連付けることができる。この例では、追加のポリシー（３０３）及びＬＣＭＡ（３０４）を、スティッチングプロセスによって生成されたトポロジー（３０２）に関連付けることができる。別の例では、ポリシー（３０３）及びライフサイクル管理アクション（ＬＣＭＡ）（３０４）を、アプリケーションモデル（３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付ける処理を、ブロック６３４のスティッチングプロセス後のそれらの処理のパフォーマンスに応じてオプションとすることができる。さらに別の例では、ポリシー（３０３）及びライフサイクル管理アクション（ＬＣＭＡ）（３０４）を、アプリケーションモデル（３１９）のノード（図４の３１９−１、３１９−２、３１９−３）の各々及びインフラストラクチャトポロジー（図４の３２０）のノードの各々に関連付ける処理を、ブロック５３４のスティッチングプロセスの前及び後に実行することができる。

図６に記載されているプロセスは、図３に関連して説明したトポロジー（３０２）と類似の完全に設計されたトポロジー（３０２）を生じる。たとえば、図６の方法によって得られたトポロジー（図４の３０２）を、入力トポロジー（図３の３０２）として使用することができる。さらに、別の例では、図６の方法によって得られたトポロジー（図４の３０２）を、改善（ないし修正）におけるインスタンス化のための入力トポロジー（図３の３０２）として使用することができる。さらにまた、１例では、複数の人が、図６に記載されている方法に参加する。それらの個人は、トポロジー（３０２）の設計、実行、監視、及び改善の役割を持つ人員の中でも特に、サービスの設計者、インフラストラクチャの設計者もしくは管理者、システム管理者、情報技術オペレータ、オファーマネージャー、またはユーザーでありうる。

本システム及び方法のいくつかの側面が、本明細書に記載されている原理の例にしたがう方法、装置（システム）及びコンピュータープログラム製品のフローチャート及び／又はブロック図を参照して説明されている。該フローチャート及び該ブロック図の各ブロック、並びに、該フローチャート中のブロックと該ブロック図中のブロックとの組み合わせを、コンピューター使用可能プログラムコードによって実施することができる。該コンピューター使用可能プログラムコードを、汎用コンピューターのプロセッサ、専用コンピューター、または他のプログラム可能なデータ処理装置に提供して、該コンピューター使用可能プログラムコードが、たとえば、トポロジーベースの管理ブローカー（２００）を含む装置または他のプログラム可能なデータ処理装置内の複数のプロセッサによって実行されたときに、該フローチャート及び／又はブロック図の１つもしくは複数のブロックで指定ないし規定されている機能もしくは動作を実施するようにするマシン（装置）を生成することができる。１例では、該コンピューター使用可能プログラムコードを、該コンピュータープログラム製品の一部であるコンピューター可読記憶媒体内に具現化することができる。１例では、該コンピューター可読記憶媒体は、非一時的なコンピューター可読媒体である。

本明細書及び図面は、トポロジーとしてモデル化されたクラウドサービスのライフサイクルを管理する方法及びシステムを記載している。それらのシステム及び方法は、プロセッサを用いて、クラウドサービスを表すトポロジーを生成すること、複数のライフサイクル管理アクション（ＬＣＭＡ）を該トポロジー内の複数のノードに関連付けること、及び、ライフサイクル管理エンジンを用いて該トポロジーを実行することを含む。

トポロジーとしてモデル化されたクラウドサービスのライフサイクルのこの管理は、多くの利点の中でも特に、下記のものを含むいくつかの利点を有し得る：（１）トポロジー、実現されたトポロジー、及びポリシーの共通の使用と共に共通のスタックを提供することを、同じトポロジーを用いて複数のプロバイダーの関連する技術をサポートしつつ、トポロジーを構成するためのクラウドサービスオートメーション（ＣＳＡ）及び継続的デリバリーオートメーション（ＣＤＡ）プラットフォーム及びサービスの両方の全ての使用例をサポートするために用いることができ、（２）ＣＳＡ及びＣＤＡが、たとえば拡張マークアップ言語（ＸＭＬ）やJavaScript Object Notation（JSON：ジェイソン）などの同じトポロジー表現を使用するコンピューティング環境を提供し、（３）既存のＣＳＡコンテンツを再利用することによってＣＳＡ用のコンテンツの移動を管理し、リソースプロバイダーを移動する経路を生成し、及びプロバイダーを再利用する方法を提供し、（４）ＣＳＡ／ＣＤＡの混乱状態が永続するリスク、二度手間、及び将来のＣＳＡの機会を危うくするのを回避または軽減し、（５）複雑なアプリケーションの配置（デプロイ）を実行するやり方を理解することをユーザーに要求することなく、該アプリケーションを、要求されたインフラストラクチャに自動的に配置（デプロイ）することができ、（６）ＣＭ＆Ｓ環境をサポートし、及び（７）クラウド環境内に、自動コンピューティング（計算）、作業量管理、及び、ポリシーベースの自動改善（自動修復）及び自己改善（自己修復）を提供する。

図７は、本開示にしたがうシステム（７００）の１例である。図７は、ファーストデーオペレーションのないセカンドデーオペレーションを含んでいる。たとえば、図７は、実現されたトポロジーを、該トポロジーを以前に提供（プロビジョニング）し及び／又は修正（ないし変更）した手段から分離することを含む。システム（７００）は、本明細書に記載されているように、該システムにおいて、実現されたトポロジーがシステム（６００）によって提供（プロビジョニング）され及び管理されているために該トポロジーを知ることができるだけではなく、該トポロジーが、発見された実現済みのトポロジー及び／又は推測された実現済みの（inferred realized）トポロジーでもありうるところのシステムである。システム（７００）は、クラウドシステムを提供（プロビジョニング）して管理するための種々の要素を含むことができる。

発見されたトポロジーは、システム（７００）以外の異なるシステムから、該トポロジー（すなわち、メインシステム（７００）から提供（プロビジョニング）されていないか、または、メインシステム（７００）から独立に管理及び修正（ないし変更）された可能性があるトポロジー）に関連する情報を取得する能力を参照する（該能力に問い合わせる）。

たとえば、該トポロジーを、該トポロジーを提供（プロビジョニング）した別のクラウドコントローラもしくはシステム（たとえば、vCenterのようなＶＭＷareコントローラ、ＳＡのような従来のプロビジョナ、システム（７００）から分離されたシステムなど）からのものとすることができる。別の例では、該トポロジーをリポジトリから推測することができ、この場合、情報は、該トポロジーを設計及び／又は定義した（たとえば、HP Enterprise Map−ＥＭ）、該トポロジーを提供（プロビジョニング）し（たとえばHP UCMDB）及び／又は管理／修正（ないし変更）した、または、システムから提供（プロビジョニング）されたインスタンスを修正（ないし変更）した任意の者または任意のシステムによって格納されている。

たとえば、推測されたトポロジーを、ＳＡ（サーバーオートメーション）からの設計図及び／又は仕様、または、ＣＭＤＢに格納されている情報とすることができる。推測の場合には、リポジトリからの情報をシステム（７００）にロードして、該情報を、ポリシーと共に（たとえば、異なる要素及び（たとえば、ノードタイプの所定のコンテキスト／データに関連付けられたポリシーから推測されるかもしくは得られる）関連するポリシーに関連付けられたライフサイクル管理アクションを用いて））トポロジーにマッピングすることができる。推測されたトポロジー及び／又は関連付けられたポリシーは、いくつかの実施形態における最良の推測でありうる。推測されたトポロジーは、既知であるもの（たとえば、さらなる管理のためにポリシーまたはＬＣＭに関してシステム（７００）が使用できるもの）を明らかにすることができる。この場合、欠落したトポロジー情報及び／又は推測されたトポロジーに対する修正（たとえば、ＬＣＭの詳細、依存状態／関係、ポリシー）を、トポロジーデザイナーに類似のコンソールを用いて手動で更新することができる。

実現されたトポロジーが、システム（７００）によってなされた提供（プロビジョニング）、管理（たとえば、改善（ないし修正）以外の管理）、または改善（ないし修正）の結果ではないときも、他のシステムが、該実現されたトポロジーの管理に作用するときにも、システム（７００）は重要でありうる。たとえば、追加のシステムは、実現されたトポロジーの監視、管理、または改善（ないし修正）を独立して行うことができる（たとえばシステム７００はＨＰＣＳＡベースのものである）。いくつかの実施形態では、該ＣＳＡポリシーは、ＣＭＤＢ内の実現されたトポロジーインスタンスを共有することを含むことができる。別の例では、ＨＰＳＡ（サーバーオートメーション）のようなシステムは、（たとえば、動作、使用セキュリティの）監視、管理、及び／又は改善（ないし修正）を実行するために格納されている情報を使用することができる。いくつかの実施形態では、システム（７００）に関係のない監視、管理、及び／又は改善（ないし修正）を同時に（ないし並行して）行うことができる。いくつかの実施形態では、本明細書に記載されているように、または、単に、システム（７００）は、システム（７００）に情報が入れ直されることを知らされもしくは変更について知らされるという理由から、トポロジーを再発見または推測する必要がありうる。したがって、発見システムは、インスタンスに対する変更（または変化）または通知を追跡し、さらに、それらを（該システムが格納して追跡する）該インスタンスの更新に反映させることができる。すなわち、提供（プロビジョニング）後に、いくつかのステップを外部のシステム（たとえば、システム（７００）以外のシステム）によって実行することができる。この結果、システム（７００）の能力を維持するために、インスタンスの更新をシステム（７００）に反映させることが重要でありうる。したがって、システム（７００）は、インスタンスに対する変更を再発見することができ、または、システム（７００）にそれらの変更（すなわち通知）を知らせることができる。

いくつかの実施形態では、アプリケーションは、実現されたトポロジーの管理ステップの一部または全てを引き受けるプラットフォームに配置（デプロイ）される。たとえば、アプリケーションは、ＰａａＳ様のＣｌｏｕｄ Ｆｏｕｎｄｒｙ（クラウドファンドリー）、または、その他の実行及び管理プラットフォームに配置（デプロイ）され、この場合、システム（７００）を用いて、アプリケーション及び／又はＰａａＳ並びにそのコンテキストを配置（デプロイ）することができる（たとえば、インフラストラクチャにおけるＰａａＳデプロイメント、及び、ＰａａＳにおけるマニフェスト生成及びコードデプロイメント）。その後、ＰａａＳは、実現されたトポロジーを管理（たとえばオートスケーリング（auto-scaling））することができる。これが行われるときは、システム（７００）は、実現されたトポロジーに変更を加えないようにすることができる。本明細書に記載されている現在のソリューションは、実現されたトポロジーを管理するのに関わり続けるために必要とされる（たとえば、実現されたトポロジーの更新は、それらの更新を、cloud foundry（クラウドファンドリー）から取り込まれた（または同期した）、実現されたトポロジーの更新として追跡することによって、システム（７００）によって追跡されまたは該システム（７００）に通知される）。

システム（７００）は、ユーザーインターフェース（７０２）を備えることができる。ユーザーインターフェース（７０２）を用いて、クラウドシステムに関する情報を表示することができる。いくつかの実施形態では、ユーザーインターフェース（７０２）を用いて、クラウドシステムに関するデータを入力することができる。本明細書に記載されているように、システム（７００）を用いて、推測された実現済みのトポロジーを視覚化することができる。いくつかの実施形態では、システム（７００）を用いて、推測された実現済みのトポロジーを修正（ないし変更）することができる。たとえば、推測された実現済みのトポロジーを修正（ないし変更）することは、該推測された実現済みのトポロジーを（たとえば、ＬＣＭ、ポリシー（３０３）、及び／又は、該推測された実現済みのトポロジーに関する他の情報を用いて）編集し、訂正し、及び／又は補完することを含むことができる。いくつかの実施形態では、システム（７００）を用いて、他のシステム及び／又は該推測された実現済みのトポロジーのファイルから情報を駆動（または取得）し及び／又はロードすることができる。本明細書に記載されているように、システム（７００）を用いて、あるシステムが実現されているトポロジー及び／又は発見されたトポロジーを管理するのと同じ及び／もしくは類似のやり方で、該推測された実現済みのトポロジーを管理することもできる。さらに、システム（７００）は、ＬＣＭアクションの選択を可能にすることができる。いくつかの実施形態では、それらのトポロジーを補完することは、ポリシー（３０３）をそれらのトポロジーに結合することを含むことができる。たとえば、それらのトポロジーを補完することは、データセンターにおけるポリシーから得られたポリシー（３０３）を、それらのトポロジーの同じ及び／もしくは類似のノードタイプに結合することを含むことができる。すなわち、発見された及び／又は推測されたトポロジーの複数のノードにポリシー（３０３）を結合することによって、該発見された及び／又は推測されたトポロジーを更新することができる。したがって、それらの発見された及び／又は推測されたトポロジーの発見された及び／又は推測されたインスタンスを、システム（７００）によって、規定し及び管理することができる。

さらに、システム（７００）は、トポロジー、関係、依存状態、及び／又はポリシー（３０３）に対する変更を得るためのオプションを含むことができる。該変更を、システム（７００）によって、実現されたトポロジーに対して実施することができる。たとえば、該変更は、ノードを移動し、トポロジーを複製し、及び／又は、トポロジーを廃棄するための命令を含むことができる。いくつかの実施形態では、システム（７００）は、推奨エンジンによって推奨された改善（ないし修正）を承認することができる。トポロジー、関係、依存状態、及び／又はポリシー（３０３）に対する変更を得るためのオプションはまた、コードを変更すること（すなわち、デザイナーを使用しない）を含むことができる。いくつかの実施形態では、トポロジーがＴＯＳＣＡＹＡＭＬプロファイルで表されているときには、それらの変更をＹＡＭＬによって行うことができる。

システム（７００）は、カタログ（７０４）を備えることができる。いくつかの実施形態では、カタログ（７０４）は、クラウドシステムに関する情報を格納するために使用することができるコンピューター可読媒体を含むことができる。いくつかの実施形態では、カタログ（７０４）を用いて、クラウドシステムの配置（デプロイ）されたシステムに関する情報を格納することができる。したがって、実現されたトポロジーを、システム（７００）によって最初に提供（プロビジョニング）しなくてもよく、むしろ、システム（７００）以外の異なるシステムによって、ある時点で更新及び／又は管理することができる。

システム（７００）は、ポリシーベースの実施（フルフィルメント）、調整（オーケストレーション）、及び統合ツール（７０６）を備えることができる。ポリシーベースの実施（フルフィルメント）、調整（オーケストレーション）、及び統合ツール（７０６）は、クラウドシステムにおけるサービスの配置（デプロイ）のために使用することができる複数のポリシー（３０３）を含むことができる。本明細書に記載されているように、ポリシー（３０３）は、いくつかあるポリシー（３０３）の中でも特に、ステージ及びバージョンポリシー（３０３）でありうる。いくつかの実施形態では、ポリシー（３０３）は、システム（７００）によって最初に提供（プロビジョニング）されない実現されたトポロジーに（たとえば、自動的に、または、補完することなどによって）適用される。

システム（７００）は、サービス及びインスタンスリポジトリ（７０８）を備えることができる。サービス及びインスタンスリポジトリ（７０８）は、クラウドシステムからの複数のサービス及び／又は複数のインスタンスに関する情報を格納するために使用することができるコンピューター可読媒体を含むことができる。システム（７００）は、モデルリポジトリ（７１０）を含むことができる。モデルリポジトリ（７１０）は、クラウドシステムのアプリケーションモデル（３１９）、クラウドシステムのトポロジー（３０２）、クラウドシステムのインスタンス、クラウドシステムの環境、及び／又は、クラウドシステムの所望の環境に関する情報を格納することができるコンピューター可読媒体を含むことができる。

システム（７００）は、トポロジーの自動化された発見及び／又は手動による発見を開始することができる発見モジュール（７１２）を備えることができる。本明細書に記載されているように、発見モジュール（７１２）は、システム（７００）の実現されているトポロジー及び／又は推測された実現済みのトポロジーを発見することができる。システム（７００）は、報告プラットフォーム（７１４）を備えることができる。報告プラットフォーム（７１４）を用いて、エラーの報告及び／又はクラウドシステムの状態（ステータス）の報告を送ることができる。システム（７００）は、共通のデータウェアハウス（７１６）を備えることができる。共通のデータウェアハウス（７１６）は、報告プラットフォーム（７１４）に関するデータを格納するために使用することができるコンピューター可読媒体を含むことができる。いくつかの実施形態では、発見モジュール（７１２）に、発見すべきアイテムを知らせることができる。たとえば、トポロジーに対する変更がある場合には、発見モジュール（７１２）に、該トポロジーに対して実施された変更であって、該トポロジーを発見するために通知される変更があったことを通知することができる。いくつかの実施形態では、システム（７００）に発見すべきアイテムを知らせて、その後、発見すべきアイテムが何であるかを発見モジュール（７１２）に知らせることもできる。

いくつかの実施形態では、システム（７００）は、実現されたトポロジーインスタンスから、トポロジー設計、トポロジーモデル、及びトポロジーテンプレートを分離することによってイネーブル（使用可能）にされる。システム（７００）は、実現されたインスタンス（該インスタンスは該インスタンス用のモデル及び／又は設計を有していない）を管理することができる。さらに、システム（７００）は、実現されたトポロジーを、外部のシステムから、取り込み、発見し、及び／又は修正（ないし変更）すること、及び、実現されたトポロジーを管理するために該トポロジーを追跡することを可能にすることができる。

図８は、本開示にしたがう、図７に示されている構成要素、プラットフォーム、及びモジュールを含むシステム（８００）の１例である。システム（８００）は、本明細書に記載されているクラウドシステムの例示的なアーキテクチャを有している。図８は、管理ブローカー（３００）によって提供（プロビジョニング）されないトポロジーを発見するための例示的な方法にとって有用である。システム（８００）を、システム（７００）と類似のやり方で用いることができる。

図８に示されているように、システム（８００）は、発見部分（８１０）を備えることができる。発見部分（８１０）は、図７に関して参照された発見モジュール（７１２）を含むことができる。発見部分（８１０）は、実現されたトポロジー及び／又は推測された実現済みのトポロジーを発見するために使用されるシステム（８００）の一部を含むことができる。

システム（８００）は、セカンドデーオペレーション部分（８２０）を含んでいる。セカンドデーオペレーション部分（８２０）は、構成要素のこのサブセットによってイネーブル（使用可能）にされる。本明細書に記載されているように、セカンドデーオペレーションは、ハードウェア、ソフトウェア、及び／又はロジックの配置（デプロイ）後のクラウドシステムの動作を含むことができる。たとえば、セカンドデーオペレーションは、提供（プロビジョニング）すること、他の管理ツールを用いること、または、図３に関して参照された管理ブローカー（３００）によって管理されることになる別の物によって提供（プロビジョニング）されたトポロジーを発見すること、及び／又は、クラウドシステムを管理することを含むことができる。本明細書に記載されているように、いくつかの実施形態では、システム（８００）は、モデリング部分、設計部分、提供（プロビジョニング）、その後のセカンドデーオペレーション、報告（ただしそれらには限定されない）を含む複数の異なる部分を含むことができる。したがって、トポロジーがシステム（８００）によって提供（プロビジョニング）されない場合であっても、セカンドデーオペレーション（たとえば、システムの提供（プロビジョニング）後に実施されるもの）を、システム（８００）によって実行することができる。

システム（８００）は、報告部分（８３０）を含むことができる。システム（８００）の報告部分（８３０）は、エラーを報告し、及び／又は、クラウドシステム分析情報を提供するために使用されるシステム（８００）の要素を含むことができる。

図９は、本開示にしたがうシステム（９００）の１例である。システム（９００）は、モデリング部分（９４０）を含むことができる。モデリング部分（９４０）は、システム（９００）によって表されるクラウドシステムのモデリング（モデル化）に対応する該システムの要素を有する該システムの一部を含むことができる。モデリング部分（９４０）は、サービスリポジトリ及び／又はインスタンスリポジトリ（７０８）、発見モジュール（７１２）、モデルリポジトリ（７１０）、及び／又は、クラウドシステムをモデル化するために使用することができるクラウドシステムの他の要素を含むことができる。

システム（９００）は、クラウド管理部分（９５０）を含むことができる。クラウド管理部分（９５０）は、図１〜図６に関連して述べたように、クラウドシステムにおいてサービスを提供し、及び／又はクラウドサービスを管理し、及び／又はクラウドサービスを提供（プロビジョニング）するために使用することができる、及び／又は、クラウドシステムのブローカーとして使用することができるシステム（９００）の要素を含むことができる。

図１０は、本開示にしたがう、構成要素の例示的なプラットフォーム（１０００）を示すブロック図である。プラットフォーム（１０００）は、クラウドシステムを提供（プロビジョニング）し及び管理するために使用することができる複数の構成要素を備えている。プラットフォーム（１０００）は、図１〜図６に関連して述べたように、クラウドシステムのトポロジー（３０２）に関連付けられた構成要素を含むことができる。

プラットフォーム（１０００）は、ファーストデーオペレーション及び管理のためのクラウド制御及び管理システムを備えることができる。プラットフォーム（１０００）は、一体化されたまたは独立型の開発及び運用システム（１００４）を備えることができる。開発及びアプリケーションリリース自動化システム（１００４）は、ステージ（たとえば、テスト、試作、製造などの段階）に応じた適切なインフラストラクチャへのアプリケーションの配置（デプロイ）、並びに、関連する監視及び改善（ないし修正）を容易にすることができる。

いくつかの実施形態では、複数の管理ソリューションを、プラットフォーム（１０００）におけるアプリケーションとみなすことができる。たとえば、データセンター内で典型的に行われるファーストデーオペレーションなどのアプリケーション、及び、ＣＳＡなどの管理、または、セカンドデーオペレーションなどのアプリケーションを、データセンターとクラウドネットワークとの間で移動させ及び共有することができる。

プラットフォーム（１０００）は、一体化されたまたは独立型の報告システム（１００８）を備えることができる。報告システム（１００８）は、クラウドシステムで起こったエラーを報告することができる。いくつかの実施形態では、報告システム（１００８）は、クラウドシステムの動作及び機能に関する情報を含む報告（レポート）を生成することができる。

プラットフォーム（１０００）は、一体化されたまたは独立型の監視システム（１０１０）を備えることができる。監視システム（１０１０）を用いて、クラウドシステムの配置（デプロイ）されたサービスの性能及び状態（ステータス）を監視することができる。本明細書に記載されているように、配置（デプロイ）されたサービスは、アプリケーション１００２または異なるシステムによって、提供（プロビジョニング）及び管理され、または改善（ないし修正）されたものであってもよい。本明細書に記載されているように、監視システム（１０１０）を用いて、クラウドシステムの種々の関係を監視することができる。

プラットフォーム（１０００）は、図１〜図６に関連して述べたようなクラウドシステムを介してサービスを提供するための複数の特徴を含むことができるコアプラットフォーム（１０１２）を備えることができる。コアプラットフォーム（１０１２）は、ユーザーインターフェース（１０１４）を含むことができる。ユーザーインターフェース（１０１４）を用いて、報告システム（１００８）からの報告を表示し、及び／又は、プラットフォーム（１０００）に変更を加えることができる。コアプラットフォーム（１０１２）は、カタログ（１０１６）を含むことができる。カタログ（１０１６）は、クラウド環境において、配置（デプロイ）され、実行され、及び管理される複数のサービス、アプリケーション、プラットフォーム、またはインフラストラクチャ能力から適切に構成されるクラウドサービスなどの個々の設計、提供（プロビジョニング）、配置（デプロイ）及び管理を格納することができるコンピューター可読媒体を含むことができる。この場合、本明細書に記載されているように、それらの設計を注文し、要求し、及び購入することができるユーザーに、それらの設計をカタログ（１０１６）から提供することができる。

コアプラットフォーム（１０１２）は、複数のポリシー（３０３）を管理し、処理し、及び格納し／結合することができるポリシーサービス（１０１８）を含むことができる。複数のポリシー（３０３）は、管理及び／又は処理及び／又は格納／結合されることができる種々のポリシーの中でも特に、ステージ及びバージョンポリシー、プロバイダー選択ポリシー、セキュリティポリシー、アクセス制御ポリシー、監視ポリシー、イベント処理ポリシー、通知ポリシー、及び／又は改善ポリシーを含むことができる。コアプラットフォーム（１０１２）は、フルフィルメントエンジンサービス（１０２０）を含むことができる。フルフィルメントエンジン（１０２０）は、クラウドシステムの要求を実現し、提供（プロビジョニング）し、及び／又は更新すると共に、適用するポリシーのガイダンスに従うための複数の方法を含むことができる。

コアプラットフォーム（１０１２）は、通知サービス（１０２２）を含むことができる。通知サービス（１０２２）は、イベントハンドラを含むことができ、インシデントを取り出し、及び、ユーザーに知らせるためにポリシーに応じて該インシデントを送るべくイベントを処理する（たとえば、対応するポリシーでイベントを処理する）ことができる。いくつかの実施形態では、通知サービス（１０２２）は、改善の推奨を知らせることができる。いくつかの実施形態では、通知サービス（１０２２）は、改善するための改善メニューを知らせることができる。いくつかの実施形態では、通知サービス（１０２２）は、改善の推奨を受け入れることの通知、または該推奨とは異なる改善を行うことの通知を送ることができる。さらに、いくつかの実施形態では、通知サービス（１０２２）は、改善（ないし修正）が行われたことをユーザーに知らせることができる。通知サービス（１０２２）は、図１〜図６に関連して述べたような報告システム（１００８）によって生成された通知及び／又は報告を格納するためのコンピューター可読媒体を含むことができる。通知データベース（１０２２）は、実現されたトポロジー（３１４）及び／又は推測された実現済みのトポロジーの論理的システムリポジトリであって、任意の形態のデータリポジトリでありうる。

コアプラットフォーム（１０１２）は、トポロジーモデル（１０２４）を含むことができる。トポロジーモデル（１０２４）は、複数のトポロジー（３０２）のモデル表現を含むことができる。トポロジーモデル（１０２４）を用いて、クラウドシステムを提供（プロビジョニング）し及び／又は管理することができる。コアプラットフォーム（１０１２）は、モデルリポジトリ（１０２６）を含むことができる。いくつかの実施形態では、モデルリポジトリ（１０２６）は、システムモデル、トポロジー（３０２）、及び／又はインスタンスを格納するためのモデル及びインスタンスリポジトリでありうる。モデルリポジトリ（１０２６）は、複数のシステムモデル及び／又はトポロジー（３０２）を格納するために使用することができるコンピューター可読媒体を含むことができる。

コアプラットフォーム（１０１２）は、コンテンツリポジトリ（１０２８）を含むことができる。いくつかの実施形態では、コンテンツリポジトリ（１０２８）を用いて、トポロジーサービス及び／又はポリシーを設計することができる。さらに、コンテンツリポジトリ（１０２８）を用いて、リソースプロバイダーまたはＬＣＭＡを実施ないし実装することができる。コンテンツリポジトリ（１０２８）は、クラウドシステムからのコンテンツを格納するために使用することができるコンピューター可読媒体を含むことができる。コアプラットフォーム（１０１２）は、オーケストレーションシステム（１０３０）を含むことができる。オーケストレーションシステム（１０３０）を用いて、図７〜図９に関連して述べたようなクラウドシステムによって供給されたサービスを提供（プロビジョニング）し及び／又は管理することができる。

コアプラットフォーム（１０１２）は、発見システム（１０３２）を含むことができる。発見システム（１０３２）を用いて、クラウドシステム用のトポロジー（３０２）を発見することができる。さらに、図７〜図９に関連して述べたように、実現されたトポロジー及び／又は推測された実現済みのトポロジー、並びに、既存のインスタンスに対して外部のシステムによって実行される変更を発見する際に、発見システム（１０３２）を利用することができる。コアプラットフォーム（１０１２）は、統合及び実行環境（１０３４）を含むことができる。統合及び実行環境（１０３４）は、クラウドシステムにおいてサービスを実行するために、並びに、プラットフォーム（１０００）内／上で動作するアプリケーション及びサービスを実行するために利用することができる実行プラットフォームを含むことができる。

プラットフォーム（１０００）は、プロバイダー部分（１０４０）を含むことができる。該プロバイダー部分は、複数のリソースの選択をガイドする、複数のリソースプロバイダーのオファリングに関連付けられた任意のポリシーである、本明細書に記載されているリソースプロバイダーポリシー（３０８−１）を含むことができる。プロバイダー部分（１０４０）は、いくつかあるプロバイダーの中でも特に、リソース（１０４２）、管理（１０４４）、変更制御（または変更管理）（１０４６）、監視（１０４８）、セキュリティ（１０５０）を含むことができる。リソース（１０４２）は、クラウドシステムを介してサービスを提供することができるネットワークリソースを含むことができる。管理（１０４４）を用いて、クラウドシステムにおけるサービスの提供（プロビジョニング）を管理することができる。管理（１０４４）を、図３におけるサードパーティーオファリングによって実行することができる。変更制御（１０４６）を、クラウドシステムに対する手動変更、及び／又は、トポロジー（３０２）に対する手動変更のために用いることができる。監視（１０４８）は、クラウドシステムにおけるリソースの提供（プロビジョニング）及び配置（デプロイ）を監視するためのネットワークモニタを含むことができる。セキュリティ（１０５０）は、種々のセキュリティリスクを回避するために使用することができる独立型またはサードパーティーのネットワークセキュリティ要素を含むことができる。

本明細書に記載されているシステム及び方法は、別様に提供（プロビジョニング）及び／又は管理されるクラウドサービスを管理することを可能にする。たとえば、本明細書に記載されているシステム及び方法は、ファーストデーオペレーションなしで、セカンドデーオペレーション用のクラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にすることができる。すなわち、本明細書に記載されているシステム及び方法は、アプリケーションがマネージャによって開発されてマネージャによって管理されているときに、クラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にする。さらに、本明細書に記載されているシステム及び方法は、アプリケーションがマネージャによって開発されておらず、及び、トポロジーが、本明細書に記載されているように発見される推測されたトポロジー及び／又は推測された実現済みのトポロジーであるときに、クラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にする。さらに、本明細書に記載されているシステム及び方法は、本明細書で参照されているように、アプリケーションはマネージャによって開発されたが、クラウドサービスは異なる管理ブローカー（３００）によって管理されているときに、クラウドシステムのインスタンス化、提供（プロビジョニング）、及び／又は管理を可能にする。

本明細書で使用されている「ロジック」は、本明細書に記載されている特定のアクション及び／又は機能などを実行するための代替のもしくは追加の処理リソースであり、「ロジック」には、たとえば、メモリに格納されてプロセッサによって実行可能なソフトウェアやファームウェアなどのコンピューター実行可能命令とは対照的に、たとえば、種々の形態のトランジスタロジックや特定用途向け集積回路（ＡＳＩＣ）などのハードウェアが含まれる。さらに、本明細書で使用されている「１つ」または「複数の」物は、１以上のそのような物を意味することができる。たとえば、「複数のウィジェット」は、１以上のウィジェットを意味することができる。

本明細書、例、及びデータは、本開示の方法及び適用、並びに、本システム及び方法の使用の説明を提供する。本開示のシステム及び方法の思想及び範囲から逸脱することなく多くの例をなすことができるので、本明細書は、多くの可能性のある実施形態の構成及び実施のうちの一部を説明しているに過ぎない。

Claims (15)

1. ステージ及びバージョンポリシーを用いるトポロジーベースの管理のための方法であって、
   トポロジーを開発中のアプリケーションに関連付けるステップと、
   前記アプリケーションの複数のステージ及びバージョンの各々について利用可能なインフラストラクチャを定義するために、ステージ及びバージョンポリシーを決定するステップと、
   前記開発中のアプリケーションの試作及び製作中に、前記ステージ及びバージョンポリシーを前記トポロジーの複数のノードに関連付けるステップと、
   前記関連付けられたステージ及びバージョンポリシーを用いて前記トポロジーをプロビジョニングして管理するステップ
   を含む方法。
2. ステージ及びバージョンポリシーとトポロジーを関連付ける前記ステップが、前記トポロジーを定義すること、及び、前記ステージ及びバージョンポリシーと前記トポロジーとをコードの形態で関連付けることを含むことからなる、請求項１の方法。
3. 前記ステージ及びバージョンポリシーの評価に使用される前記アプリケーションの特性を変更することに基づいて、前記アプリケーションを、第１のステージ及びバージョンから第２のステージ及びバージョンに進めるステップを含む、請求項１の方法。
4. ＡＰＩを介して、前記アプリケーションの開発段階に基づいて、前記ステージ及びバージョンポリシーの評価に使用される規定されたステージ及びバージョンを作動させるステップを含む、請求項１の方法。
5. 前記ステージ及びバージョンポリシーが、
   前記アプリケーションのトポロジーに含まれる複数のレイヤについて、ステージ毎の該レイヤの要件が何であるかを示す情報と、
   前記アプリケーションの対応するステージ、バージョン、または能力に対して、複数のレイヤのうちのどのレイヤを、使用しなければならないかまたは使用しなくてもよいかの指標となる情報
   を含むことからなる、請求項１の方法。
6. 前記トポロジー、並びに前記ステージ及びバージョンポリシーがＹＡＭＬで書かれており、ステージ及びバージョンポリシーは該ＹＡＭＬに関連付けられる、請求項１の方法。
7. トポロジーをプロビジョニングする前記ステップが、前記アプリケーションの開発、テスト、試作、及び製作におけるＩＤＥからのプロビジョニングを作動させるために、アプリケーションアーティファクト、前記トポロジー、並びに前記ステージ及びバージョンポリシーをパッケージ化することを含み、データを含むファイル内の値もしくは参照によって、前記パッケージ化されたアプリケーションアーティファクト、トポロジー、並びにステージ及びバージョンポリシーのうちの任意のものを提供することができることからなる、請求項１の方法。
8. 試作及び製作という異なるステップ中に前記アプリケーションをテストするために、開発ツールチェーンを用いて、特定の段階にある前記アプリケーションをプロビジョニング及び管理することを要求するステップを含む、請求項１の方法。
9. 前記アプリケーションのステージ及びバージョンに関連付けられたステージ及びバージョンポリシーに基づいて前記トポロジーをインスタンス化するステップを含む、請求項１の方法。
10. ステージ及びバージョンポリシーを用いてトポロジーベースの管理を容易にするためのシステムであって、
    前記システムは、クラウドサービス管理を開発し、テストし、段階分けし、実行し、及びサポートするためのプラットフォームを備え、
    前記プラットフォームは、複数のエンジンを備え、
    前記エンジンは、
    トポロジーを開発中のアプリケーションに関連付けることと、
    複数のポリシーを決定することと、
    前記複数のポリシーを前記トポロジーの複数のノードに関連付けることと、
    前記関連付けられた複数のポリシーを用いて前記トポロジーをプロビジョニングすること
    を実行し、
    前記複数のポリシーは、前記アプリケーションの所与のステージ及びバージョンに対して利用可能な複数のインフラストラクチャまたは下位のレイヤを定義するステージ及びバージョンポリシーを含むことからなる、システム。
11. 前記ステージ及びバージョンポリシーは、前記アプリケーションの開発の対応するステージ及びバージョンの各々に対するプロビジョニング及び管理をガイドする、請求項１０のシステム。
12. 前記トポロジーは、前記プラットフォームによって管理されるクラウドサービスを構成する、請求項１０のシステム。
13. 前記複数のポリシーに基づいてサービスをインスタンス化するために管理プロセスを実行するトポロジーライフサイクル管理（ＬＣＭ）エンジンを備える、請求項１０のシステム。
14. 前記プラットフォームはブローカーを含み、該ブローカーは、前記複数のポリシーに基づいて前記プロビジョニングされたアプリケーションを管理するように構成された該ブローカーに構築された複数のアプリケーションを含むことからなる、請求項１０のシステム。
15. ステージ及びバージョンポリシーを用いてトポロジーベースの管理を容易にするためのコンピュータープログラム製品であって、
    前記コンピュータープログラム製品は、コンピューター使用可能プログラムコードを含むコンピューター可読記憶媒体を備え、
    前記コンピューター使用可能プログラムコードは、
    プロセッサによって実行されたときに、トポロジーを開発中のアプリケーションに関連付けるためのコンピューター使用可能プログラムコードと、
    プロセッサによって実行されたときに、複数のポリシーを決定するためのコンピューター使用可能プログラムコードと、
    プロセッサによって実行されたときに、前記複数のポリシーを、前記トポロジーの複数のノードに関連付けるためのコンピューター使用可能プログラムコードと、
    プロセッサによって実行されたときに、前記関連付けられた複数のポリシーを用いて前記トポロジーをプロビジョニングするためのコンピューター使用可能プログラムコード
    を含み、
    前記複数のポリシーは、前記アプリケーションの所与のステージ及びバージョンに対して利用可能な複数のインフラストラクチャを定義するステージ及びバージョンポリシーを含むことからなる、コンピュータープログラム製品。

Images