JP2013534675A - 複数のネットワークリソースのプロビジョニング - Google Patents

Abstract

リソースプロビジョニングサービスにより、ユーザーはアトミックな方法で、かつリソースプロビジョニングサービスへの一回の呼び出しで、複数の異なるネットワークリソースをプロビジョニングできるようになる。ある例において、複数の異なるネットワークリソースは、１つまたは複数のクラウドコンピューティングプラットホームの一部分を形成する個別のタイプのリソースを含む。例えば、１つまたは複数のエンティティは、ストレージサービス、負荷分散サービス、計算サービス、セキュリティサービス、または他の類似の、もしくは異なるタイプのネットワークにアクセス可能なサービス等の異なるタイプのネットワークリソースを含むクラウドコンピューティングプラットホームをホストし操作してもよい。

Description

関連案件の相互参照
本出願は、２０１０年６月２８日に出願された、米国非仮出願１２／８２４，７２３号に関連し、この優先権を主張し、この出願の内容全体を本願に引用して援用する。

大規模なネットワークベースのコンピューティングは、従来のクライアント／サーバコンピューティングの関係からのパラダイムシフトを意味する。大規模なネットワークベースのコンピューティングプラットホーム（例えばデータセンター）では、顧客はサードパーティーが所有し「クラウドに」存在するリソースを借用することにより共有資源をオンデマンドで活用できる。これらのリソースを使用し、プラットホームの顧客は大規模なアプリケーションを、これらのアプリケーションに必要な基盤となるインフラストラクチャーを実際に所有または提供することなく開始し維持することができる。そのため、ネットワークベースのコンピューティングプラットホームは、コンピュータアプリケーションの領域で効果的に競合できる個人および企業のクラスを拡大した。これらの進歩にもかかわらず、これら個人および企業は、所望のリソースをプロビジョニングする目的でこれらのネットワークベースのコンピューティングプラットホームのホストと仕事をする際、いまだに問題があると感じる可能性がある。

発明を実施するための形態は、添付の図を参照して記載される。図において、参照番号の左端の数字は、参照番号が最初に現われる図を特定する。異なる図において同一の参考番号が使用されている場合は、類似のまたは同一の事項または特性を示す。

複数の異なるネットワークリソースをプロビジョニングするためにユーザーコミュニティのユーザーがリソースプロビジョニングサービスと対話を行い得る環境例の図である。この環境において、ユーザーは、ある実施形態においてプロビジョニングサービスへの一回のリクエストで複数のリソースをプロビジョニングし得る。 複数の異なるネットワークリソースをプロビジョニングするために、図１のアーキテクチャが実行し得る処理例の図である。 複数の異なるネットワークリソースをプロビジョニングするため、リソースプロビジョニングサービスが実行し得る処理例の流れ図である。ここで、この処理は、サービスが各要求されたリソースのプロビジョニングに成功する、または要求されたリソースのいずれもプロビジョニングできないというアトミックな処理を含んでもよい。 図１のリソースプロビジョニングサービスのテンプレートに基づいたスタックビルダーの一例のより詳細な図である。 図１のリソースプロビジョニングサービスのスタック管理のワークフロー例の図である。 図１、４および５のアーキテクチャ内のテンプレートを使用したスタックを作成する処理例の図である。 図１、４および５のアーキテクチャ内のスタックを削除する処理例の図である。 図１、４および５のアーキテクチャ内のスタックを採用する処理例の図である。 スタックの作成または削除要求間の、内部スタック状態の遷移例の図である。 スタックの作成または削除要求間の、外部スタック状態の遷移例の図である。

この開示は、ユーザーがアトミックな方法を用いて、リソースプロビジョニングサービスへの一回の呼び出しで複数の異なるネットワークリソースをプロビジョニングできるようにするアーキテクチャおよび技術を記述する。ある例において、複数の異なるネットワークリソースには、１つまたは複数のクラウドコンピューティングのプラットホームの部分を形成する個別のタイプのリソースを含む。例えば、１つまたは複数のエンティティはストレージサービス、負荷分散サービス、計算サービス、セキュリティサービス、または他の類似の、もしくは異なるタイプのネットワークにアクセス可能なサービス等の異なるタイプのネットワークリソースを含むクラウドコンピューティングのプラットホームをホストし操作してもよい。

一例において、ユーザーは、１つまたは複数のサードパーティーエンティティにより提供された複数のネットワークリソースの使用したアプリケーション（例えばウェブアプリケーション）の開始を要望してもよい。ユーザーは、複数の異なるリソース間で作業負荷をルーティングする負荷分散サービス、アプリケーションをホストし、かつコンピューティング能力を提供する計算サービス、顧客データを格納するオンラインストレージサービスおよびアプリケーションのユーザーにセキュリティを提供するセキュリティサービスを要望してもよい。単一のエンティティがこれらネットワークリソースの各々を提供し操作し得るが、複数の異なるエンティティが他の実施でのこれらのリソースの１つまたは複数を提供し操作し得る。

いずれにおいても、これら複数の異なるネットワークリソースをプロビジョニングするために、リソースプロビジョニングサービスはユーザーと通信し得る。例えば、ユーザーは、複数のネットワークリソースのスタックをプロビジョニングするためプロビジョニングサービスに最初の要求を行い得る。ある例において、この要求は、複数のリソースをプロビジョニングするため事前に入力された命令を含むテンプレートに基づいてもよい。このテンプレートは、スタック作成要求を記すためにユーザーに宣言型言語を提供する。これによってユーザーは、これらのスタックを構築する方法およびどのアプリケーションプログラムインターフェイス（ＡＰＩ）呼び出しを呼び出すかではなく、どのリソースをプロビジョニングするべきか、およびこれらのリソースの相互接続に注目できる。例えば、テンプレートは、（エクステンシブルマークアップランゲージ（ＸＭＬ）フォーマット、ジャバスクリプトオブジェクトノーテーション（ＪＳＯＮ）等で）１つまたは複数の異なるネットワークリソースをプロビジョニングするプロビジョニングサービスに命令してもよい。

ある例において、その後、ユーザーは、リソースに関連した特定のパラメーターを指定するため、テンプレート内の命令を変更してもよく、変更したテンプレートを新しいテンプレートとして保存してもよい。例えば、ユーザーはストレージサービスの所望の特定のサイズ、計算サービスの所望のコンピュータの数等を指定して新しいテンプレートを作成してもよい。更に、新しいテンプレートを作成する場合、ユーザーは１つまたは複数のネットワークリソースに、またはネットワークリソースの構成要素に論理名を割り当ててもよい。例えば、ユーザーは命令の一部分を削除する、または過去呼び出されたテンプレートよりもさらに多くのネットワークリソースをプロビジョニングするため新しい命令を加える等のなんらかの方法によってオリジナルのテンプレートを変更して新しいテンプレートを作成してもよい。別の例において、ユーザーはテンプレート内で別のテンプレートをさらに呼び出してもよい。そのため、テンプレートは、複数の異なるネットワークリソースのスタックの作成で使用される構成要素となる場合がある。

ユーザーが作成した命令に満足な場合（テンプレートへの変更の有無に関わらず）、新しいテンプレートとして命令を格納するために、ユーザーはプロビジョニングサービスに命令を戻す。例えば、ユーザーは、新しいテンプレートを含むテキストファイルを提供してもよい。このテンプレートは、ＸＭＬまたはＪＳＯＮフォーマット、または他の適切なフォーマットでの命令を含んでもよい。

プロビジョニングサービスが新しいテンプレートを格納した後、ユーザーはそのテンプレートを使用して（または別のテンプレートを一緒に使用して）リソースのスタックを作成する要求をしてもよい。これを受けて、プロビジョニングサービスは、所望のネットワークリソースのスタックを識別するためにテンプレートを検索し解析してもよい。例えば１つの例において、プロビジョニングサービスは、ユーザーが負荷分散サービスの特定のサイズ、計算サービスのサーバの特定の数、ストレージサービスの特定のサイズおよびセキュリティサービスの特定のタイプの採用を希望しているかということを確認し得る。これを受けて、プロビジョニングサービスは、ユーザーのために要求されたネットワークリソースの各々のプロビジョニングを試行してもよい。すなわち、プロビジョニングサービスは、負荷分散サービス、計算サービス等の所望のサービスの確保を試行してもよい。

更に、プロビジョニングサービスは、互いに並行なネットワークリソースの少なくとも一部分のプロビジョニングを試行してもよい。例えば、プロビジョニングサービスは、複数のネットワークリソース間の依存を決定してもよく、これらの依存に従ったリソースのプロビジョニングを試行してもよい。プロビジョニングサービスは、テキストファイルからの暗黙的依存を識別してもよく、また、プロビジョニングサービスはユーザーにより指定された明示的依存を受信してもよい。

いくつかの例において、プロビジョニングサービスは、ネットワークリソースのスタックのアトミックなプロビジョニングを試行する。すなわち、プロビジョニングサービスが要求されたネットワークリソースの各々のプロビジョニングに成功する場合、プロビジョニングサービスはスタックの作成に成功したと考えるであろう。スタックの作成に成功したことに応じて、プロビジョニングサービスはこの成功をユーザーに通知してもよい。プロビジョニングサービスが要求されたリソースの１つまたは複数のプロビジョニングに（例えば試行を繰り返した後）失敗した例では、プロビジョニングサービスは、スタックのプロビジョニングを失敗と見なし、プロビジョニングサービスがプロビジョニングに成功した要求リソースをロールバック、またはティアダウンしてもよい。さらに、プロビジョニングサービスはこの失敗をユーザーに通知してもよい。そのため、ユーザーは、複数のネットワークリソースのスタックをプロビジョニングするための要求の提出時に、要求したリソースがすべてプロビジョニングされるか、または、どれもプロビジョニングされないであろうことを知っている。

この議論は、上で導入された技術を実施するアーキテクチャ例を記述する「アーキテクチャ例」という題のセクションから始まる。次に、「処理例」という題のセクションが続き、ここでは図１に記述されたアーキテクチャ例を使用して、複数のネットワークリソースをプロビジョニングする処理例を記載する。後続する「リソースプロビジョニングサービス例および処理」という題のセクションでは、図１で記述したリソースプロビジョニングサービスの特定の例およびスタックを作成、削除、採用するためのサービス例が実施し得る処理を記述する。このセクションでは、さらにこれらの処理の間に内部および外部スタック状態の遷移例を記述する。最後に、この議論を簡潔な結論で閉じる。

セクションの題および対応する要約を含むこの簡潔な導入部は、読み手の便宜のために提供されたものであり、請求項、手続きセクションの範囲を制限する意図はない。更に、上述のまたはこれから記述される技術は、数多くの方法、および数多くのコンテキストで実行され得る。以下でより詳細に記述したように、いくつかの実施およびコンテキスト例は以下の図を参照して提供される。しかしながら、以下の実施およびコンテキストは数あるうちほんの一部である。

アーキテクチャ例
図１は、記述された技術を実行し得るアーキテクチャ例１００を示す。アーキテクチャ１００はユーザーコミュニティ１０２を含むが、これは複数のネットワークリソース１０８（１）、１０８（２）、…、１０８（Ｎ）（単に「リソース」と呼ぶ）をプロビジョニングするためのリソースプロビジョニングサービス１０６を有するネットワーク１０４上で通信する。例えば、ユーザーコミュニティ１０２のユーザーは、１つまたは複数の大規模データセンターにおいてホストされる可能性のある１つまたは複数のクラウドコンピューティングプラットホームのサービスをプロビジョニングしてもよい。上で議論したように、これらのネットワークリソースには、ストレージサービス、負荷分散サービス、計算サービス、セキュリティサービス、ドメインネームシステム（ＤＮＳ）サービス、または他の類似の、もしくは異なるタイプのネットワークにアクセス可能なサービスを含んでもよい。これらのリソース１０８（１）〜（Ｎ）はそれぞれ、共通のエンティティもしくは所有者、別個のエンティティもしくは所有者、またはそれらの組合せに関連付けられていてもよい。

一方、ネットワーク１０４は、インターネット、ケーブルネットワーク、セルラーネットワーク、ワイヤレスネットワークおよび有線ネットワークのような複数の異なるタイプのネットワークのいずれか、またはそれらの組合せを表す。ネットワーク１０４はパブリックまたはプライベートネットワークであってもよい。更に、図１はいくつかの矢印を示しているが、図示したサービスの各々はネットワーク１０４、または異なるネットワークによって互いに直接または間接的に通信してもよい。

この図示した例では、代表ユーザー１０２（１）はコンピューティング装置１１０を使用して、リソースプロビジョニングサービス１０６にアクセスしネットワークリソース１０８（１）〜（Ｎ）の１つまたは複数のプロビジョニングを要求する。例えば、ユーザー１０２（１）は、クラウドベースのリソースを使用して、ウェブアプリケーションの開始を要望してもよい。そのため、ユーザー１０２（１）は、負荷分散サーバの負荷分散装置、ストレージサービスのデータベース等の複数のリソースをプロビジョニングする要求を送信してもよい。

リソースプロビジョニングサービス１０６へのアクセス、およびこのような要求を行うと、これに応じて、リソースプロビジョニングサービス１０６はユーザー１０２（１）のコンピューティング装置１１０にユーザーインターフェース（ＵＩ）１１２を提供してもよい。図１に、そのようなＵＩの一例を図示する。図示したように、ＵＩ１１２には、リソース１０８（１）〜（Ｎ）の特定のセットのスタックをプロビジョニングする要求に使用するテンプレートを、ユーザーが選択できる第１の領域１１２（１）を含む。ＵＩ１１２はさらに、ユーザー１０２（１）が、作成されることとなるスタックの名前を作成できる第２の領域１１２（１）を含む。最後に、ＵＩ例１１２はアイコン１１２（３）を含み、これが選択された場合、リソースプロビジョニングサービス１０６に要求を送信する。この要求を受信すると、リソースプロビジョニングサービス１０６は、以下に詳述されるように、テンプレートで指定されたリソースのスタックの作成を試行し得る。図１ではＵＩの一例を図示しているが、他の実施では他の類似の、または異なるＵＩを採用してもよい。

図示したように、リソース１０８（１）〜（Ｎ）の各々およびリソースプロビジョニングサービス１０６は、要求を送受信するために処理およびストレージの能力を集合的に有する１つまたは複数のサーバとして具体化される。これらのサーバは、他のサーバアーキテクチャ（例えばメインフレーム）を使用してもよいが、単一のサーバ、サーバのクラスター、サーバファームまたはデータセンター等を含む様々な方法で具体化されてもよい。

リソースプロビジョニングサービス１０６は１つまたは複数のプロセッサ１１４ならびに、インターフェース１１８およびテンプレートベースのスタックビルダー１２０を格納するメモリ１１６を含む。サービス１０６はさらに、データベース１２２、１２４および１２６を格納し、それらにアクセスする。インターフェース１１８は、ユーザーコミュニティのユーザーがリソースプロビジョニングサービス１０６にアクセスし通信できるようにする、ネットワークにアクセス可能なインターフェースを含む。例えば、ユーザーコミュニティ１０２のユーザーはあるパブリックＡＰＩによってインターフェースへの呼び出しを行ってもよい。これらの例および他の例において、ユーザーコミュニティ１０２のユーザーは、ネットワークリソース１０８（１）〜（Ｎ）の１つまたは複数のプロビジョニングを要求する目的でインターフェース１１８にアクセスする。

一方、テンプレートベースのスタックビルダー１２０は、（上述のように）ユーザーからネットワークリソースのスタックを作成する要求を受信し、かつ要求に基づいてユーザーに適切なテンプレートを提供するために機能する。例えば、図示した例において、ビルダー１２０は、ユーザー１０２（１）により選択された特定のテンプレートを使用して、リソースの指定されたスタックをプロビジョニングするための要求を受信してもよい。これを受けて、ビルダー１２０は、過去に作成されたテンプレートを格納し得る、あるいはアクセスし得るデータベース１２４から選択されたテンプレートを見つけてもよい。ある例において、リソースプロビジョニングサービス１０６、ユーザーコミュニティ１０２のユーザーおよび／または他のエンティティが、データベース１２４内のテンプレートの一部または全体を過去に作成した可能性がある。

選択されたテンプレートを見つけた後で、ビルダー１２０は、ユーザー１０２（１）のコンピューティング装置１１０にこのテンプレートを提供する。このテンプレートは、ネットワークリソース１０８（１）〜（Ｎ）の特定のセットをプロビジョニングするために事前に入力された命令を含んでいてもよい。その後、リソースに対する実際の要求を形成するために、ユーザー１０２（１）はテンプレート全体を、または一部分を使用してもよい。例えば、ユーザーは、要求されたリソースのサイズ、要求されたリソースの構成要素のいくつか（例えばコンピュータ、データベース等）、リソースの特定のバージョン、または他のパラメーターを指定するため、事前に入力された命令の中のあるパラメーターを変更してもよい。ある例において、ユーザー１０２（１）は、リソースの１つまたは複数の構成要素用のテンプレート内の論理名を指定してもよい。これらの論理名は、リソースプロビジョニングサービス１０６へのステータスまたは要求の呼び出しにより、後でこれらのリソースを管理する場合、ユーザーの便宜のためユーザーにより選択された名前を含む。

その代わりに、またはそれに加えて、ユーザー１０２（１）は、さらに別のリソースを呼び出すための命令をテンプレートに追加してもよく、またはプロビジョニングからリソースを削除するのに有効な命令を取り除いてもよい。サービス１０６により提供されるテンプレートを修正した（または、修正を行わなかった）後、ユーザー１０２（１）は、リソースプロビジョニングサービス１０６によるストレージのため、変更したテンプレートを新しいテンプレートとして提出する。その後、ユーザー１０２（１）は、新しいテンプレートにより指定されたリソースをプロビジョニングするための要求を送信してもよい。ある例において、テンプレートは、エクステンシブルマークアップランゲージ（ＸＭＬ）フォーマット、ジャバスクリプトオブジェクトノーテーション（ＪＳＯＮ）フォーマット等での命令を含むテキストファイルを形成してもよい。

テンプレートに基づいたリソースプロビジョニングの要求を受信すると、ビルダー１２０は、テンプレート（例えば、テキストファイル形式であり得る）を検索し解析してこれらのリソースをプロビジョニングする命令と同様、所望のリソースのアイデンティティーおよびパラメーター（例えばサイズ等）を決定してもよい。ビルダー１２０はテキストファイルの実命令から収集された暗黙的依存に基づいた、および／または、ユーザー１０２（１）により提供される明示的依存に基づいた命令を特定してもよい。

ファイルを解析後、次いでビルダー１２０は、ユーザーのために要求されたリソースの各々を、可能ならばアトミックな方法でプロビジョニングすることを試行してもよい。これらの例において、リソースプロビジョニングサービス１０６は、ユーザーに通知する前に、ネットワークリソース１０８（１）〜（Ｎ）の要求されたリソースの各々のプロビジョニングを試行する。リソースプロビジョニングサービス１０６が要求されたリソースの各々のプロビジョニングに成功した場合、次いでリソースプロビジョニングサービス１０６は、サービス１０６が要求されたスタックの作成に成功したことをユーザー１０２（１）に通知する。サービス１０６はさらに、新しくプロビジョニングされたスタックを反映するためデータベース１２２を更新し得る。最後に、サービス１０６は、データベース１２６により保守されているユーザー１０２（１）のアカウントへ、これらプロビジョニングされたリソースに関連した費用を課し得る。

リソースプロビジョニングサービス１０６のビルダー１２０が要求された各リソースのプロビジョニングに成功しない場合（例えば複数回の再試行後）、サービス１０６は、スタック生成に失敗したことをユーザー１０２（１）に通知してもよい。さらに、サービス１０６は、要求されたネットワークリソースのうちサービス１０６がプロビジョニングに成功したリソースをロールバック、またはティアダウンしてもよい。サービス１０６はこれらのプロビジョニングに成功したリソースに関してユーザーアカウントに請求してもしなくてもよい。

このアトミックな方法で動作することにより、サービス１０６が要求されたリソースのスタックのプロビジョニングに完全に成功するか、またはシステムの状態をユーザーの要求を受信する前に戻すかがわかるため、リソースプロビジョニングサービス１０６はユーザー１０２（１）にとって安心して使用できるものとなっている。すなわち、後者の例でも、サービス１０６がプロビジョニングされた各ネットワークリソースをロールバックするため、ユーザー１０２（１）は部分的には完了したが機能しないスタックとともに取り残されることはなくなるであろう。この快適さに加えて、アーキテクチャ１００および関連する技術により、ユーザーは、リソースプロビジョニングサービス１０６に対して、各要求リソースに対応して要求を複数回行うのではなく要求を一回にできる。サービス１０６は、ユーザー１０２（１）に要求に基づいたテンプレートを提供することにより、この一回の呼び出しをさらに容易にする。

処理例
図２は、図１のアーキテクチャ１００が実行し得る処理例２００である。この処理（全体にわたって記述した他の処理と同様）は論理的な流れ図として示され、ここで各オペレーションは、ハードウェア、ソフトウェアまたはその組合せにおいて実行できるオペレーションのシーケンスを表わす。ソフトウェアのコンテキストにおいて、オペレーションは、１つまたは複数のコンピュータが読み込み可能な記憶媒体上に格納されたコンピュータ実行可能命令を表わし、１つまたは複数のプロセッサにより実行された場合、列挙されたオペレーションを行なう。一般に、コンピュータ実行可能命令は、特定機能を実行する、または特定の抽象データ型を実行するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。オペレーションが記述された命令は、限界として解釈されることを意図せず、任意の数の記述されたオペレーションは処理を実行するためあらゆる順番におよび／または並行させて組み合わせることができる。

他のアーキテクチャがこの処理を実行し得るが、議論のため、処理２００（および他の処理）を図１のアーキテクチャ１００を参照して記述する。

この例において、「１」で、リソースプロビジョニングサービス１０６は、ユーザー１０２（１）のコンピューティング装置１１０より、ユーザーのために複数の異なるネットワークリソースのスタックのプロビジョニングを試行するのに有効なあるユーザーからの新しいテンプレートを受信する。例えば、ユーザー１０２（１）はリソースプロビジョニングサービス１０６が提供したＵＩによってこのテンプレートを提出し得る。さらに、このテンプレートは過去にサービスが格納したテンプレートに基づいている可能性がある。すなわち、ユーザー１０２（１）は図１のＵＩ１１２によってテンプレートを要求し受信してもよく、新しいテンプレートを形成するためにこのテンプレートを修正してもよく、次にサービス１０６によるストレージ用に新しいテンプレートを送信してもよい。ある例において、ユーザー１０２（１）は、リソースプロビジョニングサービス１０６への「テンプレート登録」呼び出しによってテンプレートのストレージを要求してもよい。「２」で、リソースプロビジョニングサービス１０６は、受信したテンプレートをデータベース１２４に格納する。

「３」で、リソースプロビジョニングサービス１０６はユーザー１０２（１）からユーザーのためにリソースのスタックをプロビジョニングする要求を受信する。この例では、ユーザー１０２（１）は、サービス１０６が「２」で格納されたテンプレートに指定された方法でリソースをプロビジョニングすることを要求する。すなわち「３」で、ユーザー１０２（１）は、ユーザー１０２（１）により過去に作成され、サービス１０６により格納されたテンプレートを呼び出し得る。もちろん他の例においては、ユーザー１０２（１）がユーザーコミュニティ１０２の他のユーザー、リソースプロビジョニングサービス１０６、および／または他のエンティティにより作成されたテンプレートを呼び出してもよい。

図２は、ネットワークリソース１０８（１）〜（Ｎ）の１セットをプロビジョニングするためのＸＭＬフォーマットでの命令を含むテンプレート２０２の例を示す。テンプレート例２０２にこれらの命令の一フォーマット例を示すが、提供されるテンプレートには、ユーザーがネットワークリソース１０８（１）〜（Ｎ）の複数のリソースのプロビジョニングを要求できる他のテキストベースの命令、選択可能なアイコン、ラジオボタンまたは他のインターフェース（グラフ式、または他の方法）を含んでもよい。

この例では、「４」で、リソースプロビジョニングサービス１０６は、ユーザー１０２（１）がユーザーの要求を記載したテンプレートを検索する。この例において、ユーザー１０２（１）は、ユーザーにより作成され、最近格納されたテンプレートを指定し、よって、サービス１０６はデータベース１２４からこのテンプレートを検索する。上で議論したように、ユーザー１０２（１）はこのテンプレートをカスタマイズした可能性がある。例えば、ユーザー１０２（１）にはリソースの特定のバージョン、リソースのサイズ、リソースの論理名等のあるパラメーターの値を指定している可能性がある。

「５」で、リソースプロビジョニングサービス１０６はテンプレートを解析し、ネットワークリソース１０８（１）〜（Ｎ）のうち要求されたリソースを識別し、かつこれら要求されたリソースのプロビジョニングを試行する命令を識別する。サービス１０６はこの命令の全体、または一部を暗黙および／または明示的依存に基づいて作成し得る。サービス１０６はユーザー１０２（１）が要求するリソースの特性を分析することで暗黙的依存を識別し得る。サービス１０６は、ユーザー１０２（１）からこれら依存を明示的に受信して明示的依存を識別し得る。例えば、ユーザー１０２（１）は、リソースのプロビジョニングを試行する所望の命令の全体または一部を宣言し得る。

「６」で、リソースプロビジョニングサービス１０６は、要求されたネットワークリソースのプロビジョニングを、可能ならば決定した順に、試行する。この例では、ユーザー１０２（１）は、ネットワークリソース１０８（１）、１０８（２）および１０８（Ｎ）のプロビジョニングを要求している。ある例において、リソースプロビジョニングサービス１０６は、これらの要求されたリソースのうち少なくともいくつかのプロビジョニングを並列に試行する。

「７」で、リソースプロビジョニングサービス１０６は個々のリソースから、サービス１０６がそれぞれのリソースのプロビジョニングに（一回または複数回のトライ後）成功したかどうかを示す表示を受信する。この例では、個々のリソースが成功の表示を提示しているので、リソースプロビジョニングサービス１０６は、スタックの生成は成功したと見なす。そのため、リソースプロビジョニングサービス１０６は、新しいスタックを反映するために「８」でデータベース１２２を更新する。リソースプロビジョニングサービス１０６は、さらにユーザー１０２（１）のアカウントにこのスタックを関連付け、ユーザー１０２（１）のアカウントに作成されたリソースに関する請求を行うためデータベース１２６を更新してもよい。

最後に、「９」で、リソースプロビジョニングサービス１０６は、ユーザー１０２（１）に成功または失敗の表示を提示する。例えば、リソースプロビジョニングサービス１０６はコンピューティング装置１１０にこの表示を提示してもよく、または別の通信チャンネルによりこの表示を伝達してもよい。この例で、リソースプロビジョニングサービス１０６は、ユーザー１０２（１）のために要求されたネットワークリソース１０８（１）、１０８（２）および１０８（Ｎ）の各々のプロビジョニングにサービス１０６が成功したという表示を提示する。ある例において、ユーザー１０２（１）は、「９」で表示を受信する前に、要求したスタック作成のステータスに関する質問を送信してもよい。サービス１０６はこの要求に応えて、ユーザー１０２（１）に、スタックの作成に成功したかどうかを通知してもよい。

図３は、複数の異なるネットワークリソースのプロビジョニングのため、リソースプロビジョニングサービス１０６が実行し得る処理例３００の流れ図である。ここで、処理３００は、サービスが要求された各リソースのプロビジョニングに成功する、または要求されたリソースのいずれもプロビジョニングできないアトミックな処理を含み得る。

処理３００は、３０２でクライアントのコンピューティング装置からテンプレートを受信し、これに応じて受信したテンプレートを格納するリソースプロビジョニングサービス１０６を含む。このテンプレートは、ネットワークリソースのスタックのプロビジョニングを促進し得る。３０４で、リソースプロビジョニングサービス１０６は、テンプレートを使用した、ネットワークリソースのスタックをプロビジョニングするための要求を受信する。ある例において、テンプレートおよび要求は同時に受信され得る（例えば、テンプレートが要求を含み得る）が、必ずしもそうである必要はない。３０６で、リソースプロビジョニングサービス１０６はテンプレートを解析してリソースを識別し、３０８で、リソースプロビジョニングサービス１０６は、識別されたリソースの各々のプロビジョニングを試行する。

３１０で、リソースプロビジョニングサービス１０６は、それぞれのプロビジョニングの試みが成功したかどうか判断する。成功しなかった場合、リソースプロビジョニングサービス１０６は３１２でプロビジョニングに成功したネットワークリソースをロールバックする。ある例においては、サービスは一回のリソースの呼び出しが失敗するとすぐにリソースのプロビジョニングの試行を中止する。いずれかの例で、リソースプロビジョニングサービス１０６はさらに、３１４で要求ユーザーへの失敗の通知へ進む。ある例において、リソースプロビジョニングサービス１０６はまた、プロビジョニングに成功したリソースに関して要求ユーザーのユーザーアカウントに（例えば、全スタックの生成が成功するかどうかに関わらずサービス１０６がこれらのリソースのプロビジョニングに成功したらすぐに）請求してもよい。

しかしながら、もしリソースプロビジョニングサービス１０６が、各プロビジョニングの試みに成功したと判断した場合、次いでリソースプロビジョニングサービス１０６は３１６でこの成功を要求ユーザーに通知する。３１８で、リソースプロビジョニングサービス１０６は、プロビジョニングに成功したリソースに関して要求ユーザーのユーザーアカウントに請求してもよい。

リソースプロビジョニングサービス例と処理
図４は、図１のリソースプロビジョニングサービス１０６の一例を詳細に示す。図示したように、リソースプロビジョニングサービス１０６はインターフェース１１８およびテンプレートベースのスタックビルダー１２０を含んでおり、これは、上で議論した通りである。一例では、テンプレートベースのスタックビルダー１２０はスタックビルダーサービス４０２、スタックビルダーデーモン４０４および１つまたは複数のスタック管理ワークフロー４０６を含んでもよい。

上で議論した通り、インターフェース１１８は、ユーザーコミュニティ１０２のユーザーによるパブリックＡＰＩを通じた呼び出しを可能にするネットワーク側の構成要素である。この層の１つの機能はネットワークリソース１０８（１）〜（Ｎ）への要求を受理、検証、証明、認証、ルーティングすることである。他の機能にはスロットリング、要求ロギングおよび委任トークン交換を含む。インターフェース１１８は、ネットワークリソース１０８（１）〜（Ｎ）に対して以下の１つまたは複数のＡＰＩをプロキシし得る：Ｒｅｇｉｓｔｅｒ Ｔｅｍｐｌａｔｅ、Ｄｅｓｃｒｉｂｅ Ｔｅｍｐｌａｔｅｓ、Ｄｅｌｅｔｅ Ｔｅｍｐｌａｔｅ、Ｃｒｅａｔｅ Ｓｔａｃｋ、Ｄｅｓｃｒｉｂｅ Ｓｔａｃｋ、Ｄｅｌｅｔｅ Ｓｔａｃｋ、Ｄｅｓｃｒｉｂｅ Ｓｔａｃｋ Ｒｅｓｏｕｒｃｅｓ、Ｄｅｓｃｒｉｂｅ Ｓｔａｃｋ Ｅｖｅｎｔｓ、およびＡｄｏｐｔ Ｓｔａｃｋ。

一方、スタックビルダーサービス４０２は、インターフェース１１８が引き受けている様々なＡＰＩの具体的な実行を提供する。このサービス４０２はさらに１つまたは複数の内部ＡＰＩを提供し得る。このサービスにより提供されるＡＰＩは、ある例においては、テンプレート管理ＡＰＩ、スタック管理ＡＰＩおよび監査証跡ＡＰＩとして分類できる。

テンプレート管理ＡＰＩは、（例えば図１のデータベース１２４において）テンプレートのストレージおよび処理にあたる。生の、ユーザーが提供したテンプレートは受理および認証され、その後生のオリジナルとの並行したストレージのため正準／縮減形に転換される。スタックビルダーサービス４０２は、名前によりこれらアップロードされたテンプレートを調べて、使用すべきでないとマークを付ける能力を提供する。テンプレート管理ＡＰＩの例にはＲｅｇｉｓｔｅｒ Ｔｅｍｐｌａｔｅ、Ｄｅｓｃｒｉｂｅ Ｔｅｍｐｌａｔｅ、および／またはＤｅｌｅｔｅ Ｔｅｍｐｌａｔｅを含んでいてもよい。

一方、スタック管理ＡＰＩは、スタックの作成および削除を開始し、スタックの記述を得るためのエントリポイントである。スタックの作成および削除の呼び出しは非同期的な方法で扱われてもよい。すなわち、スタックビルダーサービス４０２は、スタックの作成および削除のためのユーザー要求を検証し記録する。一方、スタックビルダーデーモン４０４は、ユーザーの意思の実際の処理を非同期に扱う。スタック管理ＡＰＩは、さらに基盤となるストレージへスタックリソースデータの読み取りおよび書込みを可能にする。ユーザーコミュニティ１０２のユーザーは、これらのＡＰＩによってそれらスタックのリソースのための論理的物理的結合の検査を要求できる。同様に、スタック管理ワークフロー４０６がスタックのリソースを割り当てる、または割り当てを開放する場合、スタック管理ワークフロー４０６は、物理的論理的マップを記録／更新するためにスタック管理ＡＰＩを使用する。スタック管理ＡＰＩにはＣｒｅａｔｅ Ｓｔａｃｋ、Ｄｅｓｃｒｉｂｅ Ｓｔａｃｋ、Ｄｅｌｅｔｅ Ｓｔａｃｋ、Ａｄｏｐｔ Ｓｔａｃｋ、Ｄｅｓｃｒｉｂｅ Ｓｔａｃｋ Ｒｅｓｏｕｒｃｅｓ、Ａｄｄ Ｓｔａｃｋ Ｒｅｓｏｕｒｃｅ（内部ＡＰＩ）および／またはＤｅｌｅｔｅ Ｓｔａｃｋ Ｒｅｓｏｕｒｃｅ（内部ＡＰＩ）を含んでいてもよい。

スタックビルダーサービス４０２はさらに監査証跡ＡＰＩを保持してもよく、これによりユーザーのために行なわれたリソース作成／削除アクションの記録が可能となる。いくつかの例において、各アクションは、データベース１２６の各ユーザーアカウントに請求された費用のログを保持する目的で記録される。さらに、データベース１２６内にアカウントを有するユーザーコミュニティ１０２の各ユーザーは、Ｄｅｓｃｒｉｂｅ Ｓｔａｃｋ Ｅｖｅｎｔｓ ＡＰＩを呼び出すことによりユーザーのログを検索してもよい。監査証跡ＡＰＩはＤｅｓｃｒｉｂｅ Ｓｔａｃｋ Ｅｖｅｎｔおよび／またはＡｄｄ Ｓｔａｃｋ Ｅｖｅｎｔを含んでいてもよい。

一方、スタックビルダーデーモン４０４は、スタック管理ワークフロー４０６と上述のジョブ状態のストレージとの統合にあたる。このデーモン４０４は、新しい／開始されなかった要求があるかどうかスタック要求テーブルを定期的に点検してもよく、これらの要求を扱うためにスタック管理ワークフロー４０６を生成してもよい。スタックビルダーデーモン４０４はさらに既存のスタック管理ワークフロー４０６を定期的に点検してもよく、ジョブ格納記録でこれらのワークフローのうちのいくつかを完了したものとしてマークしてもよい。これは、あらゆるフロントエンドのサービスからのスタック管理ワークフロー４０６呼び出しを効果的に切り離し得る。

最後に、スタック管理ワークフロー４０６は、スタック削除中のネットワークリソース１０８（１）〜（Ｎ）の正常なシャットダウンと終了の間と同様、スタック作成中にネットワークリソース１０８（１）〜（Ｎ）の作成および構成のための様々なステップの実行にあたる。

図５は、図１と図４のリソースプロビジョニングサービス１０６のスタック管理ワークフロー例４０６を示す。図示したように、スタック管理ワークフロー例４０６はシンプルワークフローサービス（ＳＷＦ）５０２上に構築される。スタック管理ワークフロー４０６はスタック作成ワークフロータイプおよびスタック削除ワークフロータイプの２つのワークフロータイプを含む。スタック作成ワークフロータイプはスタック作成決定者５０４に関連付けられ、一方、スタック削除ワークフロータイプはスタック削除決定者５０６に関連付けられる。さらに、これらのワークフローは、対応する作成アクティビティ５０８、記述アクティビティ５１０および削除アクティビティ５１２に対応づけられ、これらは一緒になってスタックのコンテキストにおいてネットワークリソース１０８（１）〜（Ｎ）の作成、記述および削除を可能にする。

図６は、図１、４および５のアーキテクチャ内のテンプレートを使用したスタックを作成する処理例６００を示す。「１」で、ユーザー例１０２（１）はスタック作成ＡＰＩを呼び出し、インターフェース１１８へテンプレート名およびスタック名を渡す。「２」で、認証サービス６０２は要求を認証する。

「３」で、インターフェース１１８は、スタックビルダーサービス４０２、および特にスタックビルダーサービス４０２のＡＰＩサーバ６０４に要求を委任する。スタックビルダーサービス４０２は、最初にスタック名を検証し、スタックリソース６０６を参照することにより選ばれた名前が別のスタックの複製ではないことを保証する。その後、スタックビルダーサービス４０２は、テンプレートメタデータ６０８を参照してテンプレート名が有効かどうかを確認する。スタック名およびテンプレート名の両方が有効な場合、スタックビルダーサービス４０２はスタックメタデータ（ＳＤＢ）テーブル６１０においてスタックメタデータ（ネームスペース，スタック名，テンプレート名，Ｓｔａｔｕｓ＝ＣＲＥＡＴＥ＿ＰＥＮＤＩＮＧ）を固持し、成功した応答はユーザー１０２（１）に送信される。

「４」で、スタックビルダーデーモン４０４は、Ｓｔａｔｕｓ＝ＣＲＥＡＴＥ＿ＰＥＮＤＩＮＧのスタックをピックアップし、ネームスペース、テンプレートｌＤ、スタックＩＤを作成されたワークフローに渡して、スタック作成ワークフローを始める。その後、デーモン４０４は、それらスタックのステータスをＣＲＥＡＴＥ＿ＩＮ＿ＰＲＯＧＲＥＳＳに更新する。デーモン４０４はさらに、スタック作成が進行中であることを示す監査証跡エントリを、監査証跡テーブル６１２へ入れる。

「５」で、スタック作成ワークフロータイプのスタック作成決定者５０４は、決定イベントのためＳＷＦ５０２を定期的にポーリングする。スタック作成決定者５０４の１つまたは複数がＳＷＦ５０２からワークフロー開始要求を受信する場合、それぞれの決定者５０４は作成ワークフロー要求の処理を開始する。

「６」で、スタック作成要求を受信すると、スタック作成決定者５０４は、スタック作成に関する監査証跡テーブル６１２へエントリを入れる。

「７」で、スタック作成決定者５０４はテンプレートサービス（例えばテンプレートメタデータ６０８）とコンタクトを取り、所与のテンプレートＩＤのテンプレートの内部表現を取得する。テンプレートを取得すると、決定者５０４は、リソースを作成する命令を計算する。これは、テンプレートもしくはテキストファイルからの暗黙的依存、またはユーザー１０２（１）により指定された明示的依存に基づいているかもしれない。一旦、決定者５０４がリソース作成の命令を決定すると、決定者５０４は、ネットワークリソース１０８（１）〜（Ｎ）のうちの１つの作成と構成を成功させるため、計算リストにネットワークリソース１０８（１）〜（Ｎ）に対応するリソース作成アクティビティ５０８の第１セットを（テンプレートでキャプチャーされた構成メタデータと一緒に）スケジューリングする。

「８」で、リソース作成アクティビティ５０８は、作業のためＳＷＦ５０２を定期的にポーリングする。「９」で、ＳＷＦ５０２から特定のリソースを作成し構成するための作業を受信すると、リソース作成アクティビティ５０８は、リソースを作成し構成するために対応するネットワークリソースとコンタクトを取る。一旦、リソースへの作成リソース呼び出しが正常に返されると、リソース作成アクティビティ５０８は、アクティビティの正常完了によって、リソースの作成に成功したことをＳＷＦ５０２に示す。アクティビティにより作成に成功したリソースの物理的な識別子は、アクティビティの完成表示に添付されてもよい。

しかしながら、リソース作成アクティビティ５０８がリソースからエラー／失敗を受信する場合、アクティビティ５０８はａｃｔｉｖｉｔｙ ｆａｉｌｅｄ ＡＰＩによってＳＷＦ５０２に失敗を報告する。アクティビティ５０８によりリソースから取得されたエラー／失敗メッセージは、ＳＷＦ５０２へのアクティビティ失敗呼び出しに添付されてもよい。

「１０」で、スタック作成決定者５０４は、作業のためＳＷＦ５０２を定期的にポーリングする。「１１」で、スタック作成決定者５０４のうちの１つが、リソース作成アクティビティ５０８が正常に完了したことを示す情報を受信する場合、その後、スタック作成決定者５０４は、作成されたリソースに関する情報で結合サービスを更新する。これは、物理リソース識別子および作成タイムスタンプへの論理リソース識別子のマッピングを含む。決定者５０４はさらに、リソースの作成成功に関するエントリを、監査証跡テーブル６１２へ入れる。その後、決定者５０４は、作成されたリソースのステータスを記述するためにリソース記述アクティビティ５１０をスケジューリングする。

決定者５０４が、リソース作成アクティビティがタイムアウトしたという情報を得る場合、決定者５０４は次いで、リソース作成アクティビティ５０８の指定回数と終了を再度スケジューリングする。アクティビティ５０８が正常に完了するまで、またはリトライが最大回数に到達するまで、ステップ８から１１を繰り返してもよい。リソース作成アクティビティのリトライが最大回数に到達している場合、決定者５０４は監査証跡テーブル６１２へ対応するエントリを入れ、ワークフローの終了を開始する。決定者５０４が、リソース作成アクティビティ５０８が失敗したという情報を得る場合、決定者５０４は、アクティビティ５０８により返されたエラーコードを調査する。エラーコードに基づいて、決定者５０４は、アクティビティタイムアウトに類似した方法でエラーを扱ってもよく、アクティビティをリトライしてもよい。

反対に、エラーコードに基づいて、決定者５０４は、アクティビティのリトライを行わないことを決定してもよく、その代り、リソース作成における失敗に関する情報で結合サービスを更新してもよい。この更新は、リソース作成を試行する間にアクティビティ５０８により受信されたエラーメッセージを記録し、対応するエントリを監査証跡テーブル６１２に入れ、ワークフローの終了を開始することを含んでもよい。

決定者５０４がワークフローの終了を開始する場合、以下のステップのシーケンスが実行され得る。まず決定者５０４はＣＲＥＡＴＥ＿ＦＡＩＬＥＤタグで（ワークフロー記録の状態フィールドを使用して）ワークフローに注釈を付ける。一旦、ワークフローがＣＲＥＡＴＥ＿ＦＡＩＬＥＤタグで注釈付けされると、決定者５０４はそのワークフローに対してそれ以上のアクティビティをスケジューリングしない。あるいは、一旦、ワークフローに過去にスケジューリングされたリソース作成アクティビティ５０８が動作を止めていると（例えば、完成もしくは失敗）、またはリトライの最大数に到達すると、決定者５０４はスタックの作成に成功できなかったことを示すエラーメッセージと共にワークフローを（Ｃｌｏｓｅ Ｗｏｒｋｆｌｏｗ ＳＷＦ ＡＰＩにより）終了する。

「１２」で、リソース記述アクティビティ５１０は、作業のためＳＷＦ５０２を定期的にポーリングする。「１３」で、ＳＷＦ５０２から特定のネットワークリソースを記述するための作業を受信すると、リソース記述アクティビティ５１０は、リソースのステータスをチェックするために対応するネットワークリソースとコンタクトを取る。リソースが「アクティブ」状態である場合、アクティビティ５１０は正常に完了する。他の場合には、アクティビティ５１０はＳＷＦ５０２に失敗を報告する。

「１４」で、スタック作成決定者５０４は、作業のためＳＷＦ５０２を定期的にポーリングする。スタック作成決定者５０４が、リソース記述アクティビティ５１０が正常に完了したことを示す情報を取得した場合、決定者５０４は監査証跡テーブル６１２へ対応するエントリを入れ、再度テンプレートサービス（例えばテンプレートメタデータ６０８）とコンタクトを取りテンプレートの内部表現を取得する。決定者５０４は、所与のスタックに対して作成された（ワークフロースタックヒストリーから取得された）リソースとテンプレートに記述されているリソースを比較し、まだ作成されていないリソースを決定する。作成されるリソースのセットが空の場合、それはスタックの作成に成功したことを示し、決定者５０４はワークフローを終了させる。しかしながら、リソースがまだ作成されていない場合、決定者５０４は、リソース作成アクティビティ５０８の次のバッチをスケジューリングする。全スタックが構築されるまで、処理６００はステップ８から１４を繰り返してもよい。

「１５」で、決定者５０４が、リソース記述アクティビティ５１０がタイムアウトしたまたは失敗したことを示す情報を受信する場合、その後、決定者５０４は、リソース作成アクティビティ５１０の指定回数と終了を再度スケジューリングする。処理６００は、アクティビティが正常に完了するまで、またはリトライが最大回数に到達するまで、ステップ１２から１４を繰り返してもよい。リソース作成アクティビティ５０８のリトライが最大回数に到達している場合、決定者５０４は監査証跡テーブル６１２へ対応するエントリを入れ、ワークフローの終了を開始する。決定者がワークフローを終了させる処理は、ステップ１０で詳述したものと同じであってもよい。

「１６」で、スタックビルダーデーモン４０４は、ワークフローがｓｔａｔｕｓ＝ＣＲＥＡＴＥ−ＩＮ−ＰＲＯＧＲＥＳＳのスタックが完了したかどうかをチェックするためＳＷＦ５０２を定期的にポーリングする。一旦、スタックビルダーデーモン４０４が、スタックの作成が正常に終了したことを知ると、スタックビルダーデーモン４０４はＣＲＥＡＴＥ−ＣＯＭＰＬＥＴＥとしてスタックのステータスをマークする。しかしながら、スタックビルダーデーモン４０４がスタック作成に失敗したことを、ワークフローステータスのＣＲＥＡＴＥ−ＦＩＥＬＤタグにより認める場合、デーモン４０４はＣＲＥＡＴＥ−ＦＡＩＬＥＤとしてスタックのステータスをマークする。失敗したスタック作成のクリーンアップの詳細は、後のスタック削除セクションにおいて議論される。一旦、スタック作成ワークフローが終了すると、スタックビルダーデーモン４０４は、エントリをスタック作成の成功／失敗に関する監査証跡テーブル６１２へ入れる。

図７は、図１、４および５のアーキテクチャ内のスタックを削除する処理例７００を示す。「１」で、ユーザー例１０２（１）は、インターフェース１１８にスタック名を渡すＤｅｌｅｔｅＳｔａｃｋ ＡＰＩを呼び出す。「２」で、認証サービス６０２は要求を認証する。

「３」で、インターフェース１１８はスタック名が検査されるスタックビルダーサービス４０２に要求を委任する。対応するスタックのステータスはＤＥＬＥＴＥ＿ＰＥＮＤＩＮＧとしてマークされる。

「４」で、スタックビルダーデーモン４０４はＤＥＬＥＴＥ＿ＰＥＮＤＩＮＧステータスのスタックを探し、ＳＷＦ５０２とコンタクトを取りスタック削除タイプのワークフローを始める。ワークフローへの入力はスタックＩＤ、およびスタックが使用するテンプレートＩＤを含む。ここで、スタックメタデータ６１０のスタックのステータスは、ＤＥＬＥＴＥ＿ＩＮ＿ＰＲＯＧＲＥＳＳに更新される。スタックビルダーデーモン４０４は、エントリを削除スタートが開始されたことを示す監査証跡テーブル６１２に書く。

「５」で、スタック削除ワークフロータイプの決定者５０６は、決定イベントのためＳＷＦ５０２を定期的にポーリングする。スタック削除決定者５０６の１つまたは複数がＳＷＦ５０２からワークフロー開始要求を受信する場合、決定者５０６はスタック削除要求の処理を開始する。

「６」で、スタック削除要求を受信すると、決定者５０６は監査証跡テーブル６１２へ対応するエントリを入れる。「７」で、決定者５０６はテンプレートサービス（例えばテンプレートメタデータ６０８）とコンタクトを取り、削除されるスタックに対応したテンプレートを取得する。テンプレートを受信すると、決定者５０６は、リソースを削除する命令を処理する。これは、スタックおよび／もしくはテンプレートにおいて暗黙的である依存、ならびに／またはユーザー１０２（１）が提示した明示的依存に基づいてなされ得る。

「８」で、ステップ７で計算されたリソース命令に基づいて、決定者５０６は、物理リソース識別子、およびＤＥＬＥＴＥＤ状態でないリソースのリソースタイプを取得するため、結合サービスとコンタクトを取る。リソースタイプおよび識別子を取得すると、決定者５０６は、所与のスタックの一部分であるリソースを削除するために適切なリソース削除アクティビティ５１２をスケジューリングする。決定者５０６がＤＥＬＥＴＥＤ状態にないリソースを一つも見つけることができない場合、スタックの削除は完了している。その後、決定者５０６はワークフローを終了する。

「９」で、リソース削除アクティビティ５１２は作業のためＳＷＦ５０２を、定期的にポーリングする。「１０」で、ＳＷＦ５０２からネットワークリソースを削除するための作業を受信すると、リソース削除アクティビティ５１２は、リソース削除するために対応するネットワークリソースとコンタクトを取る。特定のリソース削除アクティビティ５１２への入力には、削除されるリソースの物理的な識別子を含む。リソースに削除要求を提出すると、リソース削除アクティビティ５１２は、リソースのステータスをチェックするために対応するリソースを定期的にポーリングする。一旦、リソースが要求されたリソースの削除に成功したと宣言すると、アクティビティ５１２は、アクティビティ５１２の正常完了によって、ＳＷＦ５０２に削除が成功したことを示す。ネットワークが特定のエラータイプを返す場合、アクティビティ５１２は決定者５０６に失敗を報告し、ＡｃｔｉｖｉｔｙＦａｉｌｅｄ ＡＰＩと一緒にリソースにより返されたエラーメッセージを添付する。

「１１」で、スタック削除ワークフロータイプの決定者５０６は、決定イベントのためＳＷＦ５０２を定期的にポーリングする。１２で、アクティビティ完了に関する情報を得ることで、結合サービスはスタック内のリソースの削除を反映するために更新される。決定者５０６は成功したリソース削除に関する監査証跡テーブル６１２へ、対応エントリを入れる。全スタックが削除されるまで、処理７００はステップ７から１２を繰り返してもよい。決定者５０６が、リソース削除アクティビティ５１２がタイムアウトした、または失敗したという情報を受信する場合、決定者５０６はリソース削除アクティビティ５０６を指定回数分再度スケジューリングする。リトライ試行が最大回数に到達している場合、決定者５０６は、結合サービスのリソースのステータスおよび理由フィールドをＤＥＬＥＴＥ＿ＦＡＩＬＥＤと「最大削除試行回数に到達」に更新する。決定者５０６は、さらに監査証跡テーブル６１２に対応エントリを入れ、ワークフローメタデータのステータスフィールドを使用して、ワークフローにＤＥＬＥＴＥ＿ＦＡＩＬＥＤタグの注釈を付ける。

「１３」で、スタックビルダーデーモン４０４は、ワークフローがｓｔａｔｕｓ＝ＤＥＬＥＴＥ＿ＩＮ＿ＰＲＯＧＲＥＳＳのスタックに対して終了されているかどうかをチェックするため定期的にＳＷＦ５０２をポーリングする。一旦、スタックの削除が正常に完了したことがわかると、スタックビルダーデーモン４０４は、スタックのステータスをＤＥＬＥＴＥ＿ＣＯＭＰＬＥＴＥへマークする。ワークフローにＤＥＬＥＴＥ＿ＦＡＩＬＥＤタグの注釈が付けられたことをデーモン４０４が発見する場合、スタックのステータスをＤＥＬＥＴＥ＿ＦＡＩＬＥＤへ更新する。

いくつかの例において、スタックの作成が進行中である間、およびスタックが完全に作成される前に、ユーザー例１０２（１）が、スタックの削除を開始する場合がある。この例において、リソースプロビジョニングサービス１０６はこれをスタックの作成を終了させるための要求と解釈し得る。このシナリオの下で、スタックビルダーサービス４０２はスタックのステータスをＣＲＥＡＴＥ＿ＣＡＮＣＥＬ＿ＰＥＮＤＩＮＧとしてマークする。スタックビルダーデーモン４０４はＣＲＥＡＴＥ＿ＣＡＮＣＥＬ＿ＰＥＮＤＩＮＧステータスのスタックをスキャンし、ワークフローの終了を要求する対応するスタック作成ワークフローにノートを付ける。その後、スタックビルダーデーモン４０４は、スタックのステータスをＣＲＥＡＴＥ＿ＣＡＮＣＥＬ＿ＩＮ＿ＰＲＯＧＲＥＳＳへ更新する。

ノートイベントの受信で、スタック作成決定者５０４は、未処理のアクティビティが動作をやめるのを待つことでワークフローの終了を開始する。ワークフローを終了するための手順は、スタック作成シナリオにおいて上述された手順と同じであってもよい。

スタックビルダーデーモン４０４は、スタック作成ワークフローがステータスＣＲＥＡＴＥ＿ＣＡＮＣＥＬ＿ＩＮ＿ＰＲＯＧＲＥＳＳであるスタックに対して終了されるかどうかをチェックするために定期的にＳＷＦ５０２をポーリングする。一旦、スタックビルダーデーモン４０４が、スタック作成が終了したことを発見すると、スタックビルダーデーモン４０４は、スタックのステータスをＤＥＬＥＴＥ＿ＰＥＮＤＩＮＧにマークする。スタック削除の処理は、スタック作成中に作成されたあらゆるリソースをクリーンアップする。

図８は図１、４および５のアーキテクチャ内のスタックを採用する処理例の図である。「１」で、ユーザー例１０２（１）は、ＡｄｏｐｔＳｔａｃｋ ＡＰＩを呼び出して、テンプレート名、スタック名およびスタック結合をキャプチャーするマップを渡す。「２」で、認証サービス６０２は要求を認証する。

「３」で、インターフェース１１８は、スタック名を検証する（例えば、複製などがあるかチェックする）スタックビルダーサービス４０２に要求を委任する。スタック名が無効の場合、フォルトがユーザーに返される。スタックビルダーサービス４０２が、テンプレート名の検証を試行し、テンプレート名が有効な場合、サービス４０２は次いで、テンプレート名により識別されたテンプレート、および結合マップが互いに一致していることを保証するためにスタックの結合マップの中身を検証する。テンプレート名が無効であるか、名前および結合マップにより識別されたテンプレートが矛盾する場合、フォルトがユーザーに返される。

「４」で、スタックビルダーサービス４０２は次いでテンプレートに記録されたリソースを記述するＤｅｓｃｒｉｂｅＲｅｓｏｕｒｃｅ ＡＰＩを呼び出し、結合マップに記録されたリソースが存在しユーザー１０２（１）により所有されることを確認する。結合マップに記録されたリソースがどれも存在しない場合、フォルトがユーザーに返される。スタックビルダーサービス４０２は、スタックのため一意の識別子を作成し、結合マップの中にある結合情報で新しく生成されたスタックの識別子に対して結合サービスに新しいエントリを挿入する。スタックビルダーサービス４０２はさらに、ユーザーが提供したスタック名および生成されたスタックの識別子の間の関連性を追加／更新するため、スタックメタデータテーブル６１０を挿入／更新する。スタックビルダーサービス４０２はさらに、スタックの採用を示す監査証跡テーブル６１２へエントリを挿入する。

図９は、スタックの作成または削除要求間の、内部スタック状態の遷移例を示す。この例で、９０２に示すように、スタック状態例の内部状態は最初に「スタック作成保留」に設定される。９０４で、リソースプロビジョニングサービス１０６はスタック作成ワークフローを開始する。９０６に示すように、これは内部スタック状態を「作成中」に変化させる。しかしながら、サービス１０６が９０８で示すようなスタックを削除する要求を受信する場合、９１０に示すように、内部スタック状態は「作成キャンセル保留」になる。

サービス１０６は、状態が「作成中」（９０６で示すように）である間、９１２のスタックを削除する要求をさらに受信する場合がある。これを受けて、内部スタック状態は９１０に示すように「作成キャンセル保留」へさらに遷移するだろう。

スタック作成ワークフローが進行中で、スタックを削除する要求が受信されない場合、サービス１０６は、スタック作成ワークフローが成功するかどうか９１４で判断する。成功した場合、その後内部スタック状態は９１６の「作成完了」に遷移する。成功しなかった場合、内部スタック状態は９１８の「作成失敗」に遷移する。前者の例において、サービス１０６は、９２０でスタックを削除する要求を受信する場合がある。この例で、内部スタック状態は９２２で示されるように、「削除保留」へ遷移する。

内部スタック状態が「作成失敗」となる例では、遷移９００は９２４でスタックのクリーンアップを開始する。その後、内部スタック状態は９２２で示した「削除保留」に遷移する。

９１０の「作成キャンセル保留」の内部スタック状態に戻ると、上で議論したように遷移９００は９２６でスタック作成ワークフローにノートを付ける。その後、内部スタック状態は９２８の「作成キャンセル中」に遷移する。その後、スタック作成ワークフローは９３０で完了し、９２２で示すように、スタック状態は「削除保留」に更新される。

内部スタック状態が「削除保留」である場合、スタック削除ワークフローは９３２から始まる。９３４で示したように、その後、内部スタック状態は「削除中」へ移行する。９３６で、サービス１０６はスタック削除ワークフローが正常に完了したかどうか判断する。正常に完了した場合、その後、内部スタック状態は９３８の「削除完了」に移行する。正常に完了しなかった場合、その後内部スタック状態は９４０の「削除失敗」に遷移する。その後、サービス１０６はワークフローをクリーンアップし、９４２でスタックを削除する要求を再度受信してもよい。これを受けて、内部スタック状態は９２２で示されるような「削除保留」に遷移する。

図１０は、スタックの作成または削除要求間の、外部スタック状態の遷移例１０００を図示する。この例において、１００２で示されるように、スタック状態例の外部状態は最初に「作成中」に設定される。１００４で、リソースプロビジョニングサービス１０６は、作成が成功するかどうか判断する。成功した場合、その後外部スタック状態は、１００６の「作成完了」へ遷移する。成功しなかった場合、外部スタック状態は１００８の「作成失敗」に遷移する。

１０１０で、サービス１０６は、スタックの削除要求を受信する。そのため、外部スタック状態は１０１２の「削除中」に遷移する。１０１４で、サービス１０６は、削除が成功したかどうか判断する。成功した場合、その後、外部スタック状態は１０１６の「削除完了」になる。成功しなかった場合、その後、外部スタック状態は１０１８の「削除失敗」になる。その後、１０１０で示したように、サービス１０６は再びスタックの削除要求を受信してもよい。

条項１。実行された場合、
複数の異なるネットワークリソースの各々に関連した１つまたは複数のパラメーターに従って、複数の異なるネットワークリソースのスタックをプロビジョニングするために少なくとも一部分が有効である、事前に入力された命令を含むテンプレートをユーザーのコンピューティング装置から受信すること；
受信を受けてテンプレートを少なくとも部分的に格納すること；
コンピューティング装置から、テンプレートを使用して複数の異なるネットワークリソースのスタックをプロビジョニングするための要求を受信すること；
プロビジョニングを要求された複数の異なるネットワークリソースの各々、および関連する１つまたは複数のパラメーターの各々を識別するためにテンプレートを検索し解析すること；および
解析を受けて少なくとも部分的に、ユーザーのために関連する１つまたは複数のパラメーターに従った、複数の異なるネットワークリソースの各々のプロビジョニングを試行すること
を含む行為を１つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令を格納する１つまたは複数のコンピュータが読み込み可能な媒体。

条項２。複数の異なるネットワークリソースがストレージサービス、負荷分散サービス、計算サービスまたはセキュリティサービスを含む、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項３。複数の異なるネットワークリソースが、クラウドコンピューティングプラットホームの少なくとも一部分を形成する、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項４。複数の異なるネットワークリソースの各々に関連した１つまたはパラメーターが、各ネットワークリソースの要求サイズ、能力または特性を指定する、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項５。テンプレートが、ユーザーにより指定された論理名により複数の異なるネットワークリソースの少なくとも１つを識別する、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項６。テンプレートが、複数の異なるネットワークリソースの少なくとも１つに対して複数の異なるバージョンの特定のバージョンを指定する、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項７。複数の異なるネットワークリソースの各々のプロビジョニングの試行が、複数の異なるネットワークリソースの少なくとも２つの並行したプロビジョニングの試行を含む、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項８。複数の異なるネットワークリソースの各々のプロビジョニングの試行が、少なくとも一部分が複数の異なるネットワークリソースの部分間で指定された依存に基づいた順番で、複数の異なるネットワークリソースの各々のプロビジョニングを試行することを含む、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項９。指定された依存が暗黙的依存を含み、テンプレートの解析が複数の異なるネットワークリソースの部分間の暗黙的依存を識別するのに有効である、条項８に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項１０。指定された依存にユーザーにより指定された明示的依存を含む、条項８に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項１１。実行された場合、複数の異なるネットワークリソースの各々のプロビジョニングの成功を受けて、スタックが少なくとも部分的にプロビジョニングされたとユーザーに通知することを含む行為を１つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令をさらに格納している、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項１２。実行された場合、
複数の異なるネットワークリソースのうちの１つのプロビジョニングが失敗したという表示を受信すること；および
表示の受信を受けて、複数の異なるネットワークリソースのうち少なくとも部分的にプロビジョニングに成功した各リソースをロールバックすること
を含む行為を１つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令をさらに格納している、条項１に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項１３。実行された場合、表示を受けてスタックのプロビジョニングが少なくとも少なくとも部分的に失敗したとユーザーに通知すること含む行為を１つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令をさらに格納している、条項１２に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項１４。実行可能命令で構成された１つまたは複数のコンピュータシステムの制御下で、
ユーザーから、テンプレートによって識別された複数の異なるネットワークリソースのスタックをプロビジョニングするための要求を受信すること；
プロビジョニングを要求された複数の異なるネットワークリソースの各々を識別するためにテンプレートを解析すること；
解析を受けて複数の異なるネットワークリソースの各々を少なくとも部分的にプロビジョニングすることを試行すること
を含み、
複数の異なるネットワークリソースの各々のプロビジョニングに成功した場合、ユーザーにスタックのプロビジョニングが成功したことを通知し；および
複数の異なるネットワークリソースの１つまたは複数のプロビジョニングに成功しなかった場合、ユーザーにスタックのプロビジョニングが成功しなかったことを通知する、方法。

条項１５。複数の異なるネットワークリソースの各々はクラウドコンピューティングプラットホーム上に存在する、条項１４に記載の方法。

条項１６。ユーザーに関連したユーザーアカウントを維持することをさらに含み、複数の異なるネットワークリソースのプロビジョニングの試行が、ユーザーのために複数の異なるネットワークリソースのプロビジョニングを試行して、ネットワークリソースのプロビジョニングの成功に関連した費用が、ユーザーに関連したユーザーアカウントに請求される、条項１４に記載の方法。

条項１７。前記テンプレートが、前記複数の異なるリソースの少なくとも２つをプロビジョニングする要求のため事前に入力された命令を含む、条項１４に記載の方法。

条項１８。テンプレートが、複数の異なるネットワークリソースの各々への呼び出しを有するテキストベースの命令を含むテキストファイルを含む、条項１４に記載の方法。

条項１９。テンプレートが、複数の異なるネットワークリソースの少なくとも１つに対して複数の異なるバージョンの特定のバージョンを指定する、条項１４に記載の方法。

条項２０。テンプレートが、ユーザーにより選択された複数の異なるネットワークリソースのうちの１つのコンポーネントに論理名を指定する、条項１４に記載の方法。

条項２１。テンプレートの解析が、複数の異なるネットワークリソースの中の暗黙的依存を識別するためテンプレートを解析することを含み、複数の異なるネットワークリソースのプロビジョニングの前記試行が、少なくとも一部分が前記暗黙的依存に基づいた順番における前記複数の異なるネットワークリソースのプロビジョニングの試行を含む、条項１４に記載の方法。

条項２２。要求が、複数の異なるネットワークリソースの少なくとも２つの間の依存性を明示的に指定し、複数の異なるネットワークリソースのプロビジョニングの前記試行が、少なくとも一部分が依存に基づいた順番における前記複数の異なるネットワークリソースのプロビジョニングの試行を含む、条項１４に記載の方法。

条項２３。複数の異なるネットワークリソースのプロビジョニングの試行が、複数の異なるネットワークリソースのうち少なくともいくつかのプロビジョニングを並行して試行することを含む、条項１４に記載の方法。

条項２４。前記複数の異なるネットワークリソースの１つまたは複数のプロビジョニングに成功しなかった場合、プロビジョニングに成功した複数の異なるネットワークリソースのリソースをティアダウンすることをさらに含む、条項１４に記載の方法。

条項２５。１つまたは複数のプロセッサ；
１つまたは複数のプロセッサによりアクセス可能なメモリ；および
メモリに格納され、１つまたは複数のプロセッサ上で、
別個のネットワークリソースのスタックをテンプレート上の少なくとも一部分に基づいて作成する要求をユーザーから受信し、テンプレートは別個のネットワークリソースを含む前記スタックを作成するために事前に入力された命令を含み；
別個のネットワークリソースの各々を識別するためにテンプレートを解析し；および
ユーザーのため前記別個のネットワークリソースの各々のプロビジョニングを試行する
ために実行可能なテンプレートベースのスタックビルダー
を含む、装置。

条項２６。テンプレートベースのスタックビルダーがユーザーのために別個のネットワークリソースの各々のプロビジョニングに成功した場合、スタックのプロビジョニングが成功したことを前記ユーザーに通知し；
前記テンプレートベースのスタックビルダーが前記ユーザーのために前記別個のネットワークリソースの少なくとも１つのプロビジョニングに成功しなかった場合、前記スタックのプロビジョニングが成功しなかったことを前記ユーザーに通知する
ために、前記テンプレートベースのスタックビルダーが前記１つまたは複数のプロセッサ上でさらに実行可能である、条項２５に記載の装置。

条項２７。前記テンプレートベースのスタックビルダーが前記ユーザーのために前記別個のネットワークリソースの少なくとも１つのプロビジョニングに成功しない場合、前記テンプレートベースのスタックビルダーがプロビジョニングに成功した前記別個のネットワークリソースの各々をロールバックする
ために、前記テンプレートベースのスタックビルダーが前記１つまたは複数のプロセッサ上でさらに実行可能である、条項２６に記載の装置。

条項２８。要求が、ウェブアプリケーションに対するスタックを作成する要求を含み、別個のネットワークリソースがクラウドベースの負荷分散サービス、クラウドベースの計算サービスおよびクラウドベースのストレージサービスを含む、条項２５に記載の装置。

条項２９。別個のネットワークリソースが、単一のエンティティにより管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成する、条項２５に記載の装置。

条項３０。別個のネットワークリソースのうちの１つが、第１のエンティティにより管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成し、別個のネットワークリソースのうちのもう１つが、第１のエンティティから独立している第２のエンティティにより管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成する、条項２５に記載の装置。

条項３１。複数の異なるテンプレートを格納する、または複数の異なるテンプレートへアクセスするデータベースをさらに含み、複数の異なるテンプレートの各々は別個のネットワークリソースを含むスタックを作成するため事前に入力された命令を含む、条項２５に記載の装置。

条項３２。複数の異なるテンプレートの少なくとも一部分が、独立したユーザーのコミュニティにより提供された、条項３１に記載の装置。

条項３３。実行された場合に、
別個のネットワークリソースの１セットを含むスタックを作成するために事前に入力された命令を含む複数の異なるテンプレートのうちの１つの選択を促進する、第１の領域；
選択されたテンプレートを使用して作成されるスタックを指定する、第２の領域；および
スタックの作成を要求する第３の領域：
を含むグラフィカルユーザーインターフェース（ＧＵＩ）を１つまたは複数のプロセッサに描写させるコンピュータ実行可能命令を格納する１つまたは複数のコンピュータが読み込み可能な媒体。

条項３４。複数の異なるテンプレートの各々が、エクステンシブルマークアップランゲージ（ＸＭＬ）フォーマットまたはジャバスクリプトオブジェクトノーテーション（ＪＳＯＮ）フォーマットでの命令を含む、条項３３に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

条項３５。複数の異なるテンプレートの少なくとも一部分がユーザーのコミュニティの異なるユーザーにより提供される、条項３３に記載の１つまたは複数のコンピュータが読み込み可能な媒体。

結論
主題を、構造的特徴および／または方法論的行為に特定したことばで記述してきたが、添付した特許請求の範囲に定義した主題は、前述の特定の特徴または行為には必ずしも限定されないことが理解されるべきである。むしろこの特定の特徴や行為は、特許請求の範囲を実施する形態の例として開示されている。

Claims (15)

1. 実行可能命令で構成された１つまたは複数のコンピュータシステムの制御下で、
   ユーザーから、テンプレートによって識別された複数の異なるネットワークリソースのスタックをプロビジョニングするための要求を受信すること、
   プロビジョニングを要求された前記複数の異なるネットワークリソースの各々を識別するために前記テンプレートを解析すること、
   前記解析に応答して前記複数の異なるネットワークリソースの各々を少なくとも部分的にプロビジョニングすることを試行すること、
   前記複数の異なるネットワークリソースの各々が無事にプロビジョニングされる場合は、前記ユーザーに前記スタックのプロビジョニングが成功したことを通知すること、および
   前記複数の異なるネットワークリソースの１つまたは複数が無事にプロビジョニングされない場合は、前記ユーザーに前記スタックのプロビジョニングが成功しなかったことを通知すること、
   を含む、方法。
2. 前記ユーザーに関連したユーザーアカウントを維持することをさらに含み、前記複数の異なるネットワークリソースのプロビジョニングを試行することは、ネットワークリソースのプロビジョニングの成功に関連する費用が、前記ユーザーに関連した前記ユーザーアカウントに請求されるよう、前記ユーザーのために前記複数の異なるネットワークリソースのプロビジョニングを試行することを含む、請求項１に記載の方法。
3. 前記テンプレートが、前記複数の異なるリソースの少なくとも２つをプロビジョニングする要求のため事前に入力された命令を含む、請求項１に記載の方法。
4. 前記テンプレートが、前記複数の異なるネットワークリソースの各々への呼び出しを有するテキストベースの命令を含むテキストファイルを含む、請求項１に記載の方法。
5. 前記テンプレートが、前記複数の異なるネットワークリソースの少なくとも１つに対して複数の異なるバージョンの特定のバージョンを指定する、請求項１に記載の方法。
6. 前記テンプレートが、前記ユーザーによって選択された前記複数の異なるネットワークリソースのうちの１つのコンポーネントのための論理的な名前を指定する、請求項１に記載の方法。
7. 前記テンプレートを解析することは、前記複数の異なるネットワークリソースの中の暗黙的依存を識別するために前記テンプレートを解析することを含み、前記複数の異なるネットワークリソースのプロビジョニングを試行することは、前記暗黙的依存の少なくとも一部分に基づいた順番で前記複数の異なるネットワークリソースのプロビジョニングを試行することを含む、請求項１に記載の方法。
8. 前記要求が、前記複数の異なるネットワークリソースの少なくとも２つの間の依存を明示的に指定し、前記複数の異なるネットワークリソースのプロビジョニングを試行することは、前記依存の少なくとも一部分に基づいた順番で前記複数の異なるネットワークリソースのプロビジョニングを試行することを含む、請求項１に記載の方法。
9. 前記複数の異なるネットワークリソースの１つまたは複数が無事にプロビジョニングされなかった場合、プロビジョニングが成功した前記複数の異なるネットワークリソースのリソースをティアダウン(tear down)することをさらに含む、請求項１に記載の方法。
10. １つまたは複数のプロセッサ、
    前記１つまたは複数のプロセッサにアクセス可能なメモリ、および
    メモリに格納され、かつ、
    ユーザーから、テンプレートの少なくとも一部分に基づく別個のネットワークリソースのスタックを生成する要求を受信することであって、前記テンプレートは前記別個のネットワークリソースを含む前記スタックを生成するための事前に入力された命令を含む、こと、
    前記別個のネットワークリソースの各々を識別するために前記テンプレートを解析すること、および
    前記ユーザーのため前記別個のネットワークリソースの各々のプロビジョニングを試行すること、
    が前記１つまたは複数のプロセッサ上で実行可能なテンプレートベースのスタックビルダー、
    を含む、装置。
11. 前記テンプレートベースのスタックビルダーはさらに、
    前記テンプレートベースのスタックビルダーが、前記ユーザーのために前記別個のネットワークリソースの各々のプロビジョニングに成功した場合、前記スタックのプロビジョニングが成功したことを前記ユーザーに通知すること、
    前記テンプレートベースのスタックビルダーが、前記ユーザーのために前記別個のネットワークリソースの少なくとも１つのプロビジョニングに成功しなかった場合、前記スタックのプロビジョニングが成功しなかったことを前記ユーザーに通知すること、
    のために、前記１つまたは複数のプロセッサ上で実行可能である、請求項１０に記載の装置。
12. 前記テンプレートベースのスタックビルダーはさらに、
    前記テンプレートベースのスタックビルダーが前記ユーザーのために前記別個のネットワークリソースの少なくとも１つのプロビジョニングの成功に失敗した場合、前記テンプレートベースのスタックビルダーがプロビジョニングに成功した前記別個のネットワークリソースの各々をロールバックすること、
    が前記１つまたは複数のプロセッサ上で実行可能である、請求項１１に記載の装置。
13. 前記要求は、ウェブアプリケーションに対する前記スタックを生成する要求を含み、前記別個のネットワークリソースは、クラウドベースの負荷分散サービス、クラウドベースの計算サービス、およびクラウドベースのストレージサービスを含む、請求項１０に記載の装置。
14. 前記別個のネットワークリソースのうちの１つが、第１のエンティティによって管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成し、前記別個のネットワークリソースのうちのもう１つが、前記第１のエンティティから独立している第２のエンティティによって管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成する、請求項１０に記載の装置。
15. 複数の異なるテンプレートを格納する、または複数の異なるテンプレートへアクセスするデータベースをさらに含み、前記複数の異なるテンプレートの各々は別個のネットワークリソースを含むスタックを生成するために事前に入力された命令を含む、請求項１０に記載の装置。

Images