"実行可能命令で構成された1つまたは複数のコンピュータシステムの制御下で、ユーザーから、テンプレートによって識別された複数の異なるネットワークリソースのスタックをプロビジョニングするための要求を受信すること、プロビジョニングを要求された前記複数の異なるネットワークリソースの各々を識別するために前記テンプレートを解析すること、前記解析に応答して前記複数の異なるネットワークリソースの各々を少なくとも部分的にプロビジョニングすることを試行すること、前記複数の異なるネットワークリソースの各々が無事にプロビジョニングされる場合は、前記ユーザーに前記スタックのプロビジョニングが成功したことを通知すること、および前記複数の異なるネットワークリソースの1つまたは複数が無事にプロビジョニングされない場合は、前記ユーザーに前記スタックのプロビジョニングが成功しなかったことを通知すること、を含む、方法。前記ユーザーに関連したユーザーアカウントを維持することをさらに含み、前記複数の異なるネットワークリソースのプロビジョニングを試行することは、ネットワークリソースのプロビジョニングの成功に関連する費用が、前記ユーザーに関連した前記ユーザーアカウントに請求されるよう、前記ユーザーのために前記複数の異なるネットワークリソースのプロビジョニングを試行することを含む、請求項1に記載の方法。前記テンプレートが、前記複数の異なるリソースの少なくとも2つをプロビジョニングする要求のため事前に入力された命令を含む、請求項1に記載の方法。前記テンプレートが、前記複数の異なるネットワークリソースの各々への呼び出しを有するテキストベースの命令を含むテキストファイルを含む、請求項1に記載の方法。前記テンプレートが、前記複数の異なるネットワークリソースの少なくとも1つに対して複数の異なるバージョンの特定のバージョンを指定する、請求項1に記載の方法。前記テンプレートが、前記ユーザーによって選択された前記複数の異なるネットワークリソースのうちの1つのコンポーネントのための論理的な名前を指定する、請求項1に記載の方法。前記テンプレートを解析することは、前記複数の異なるネットワークリソースの中の暗黙的依存を識別するために前記テンプレートを解析することを含み、前記複数の異なるネットワークリソースのプロビジョニングを試行することは、前記暗黙的依存の少なくとも一部分に基づいた順番で前記複数の異なるネットワークリソースのプロビジョニングを試行することを含む、請求項1に記載の方法。前記要求が、前記複数の異なるネットワークリソースの少なくとも2つの間の依存を明示的に指定し、前記複数の異なるネットワークリソースのプロビジョニングを試行することは、前記依存の少なくとも一部分に基づいた順番で前記複数の異なるネットワークリソースのプロビジョニングを試行することを含む、請求項1に記載の方法。前記複数の異なるネットワークリソースの1つまたは複数が無事にプロビジョニングされなかった場合、プロビジョニングが成功した前記複数の異なるネットワークリソースのリソースをティアダウンすることをさらに含む、請求項1に記載の方法。1つまたは複数のプロセッサ、前記1つまたは複数のプロセッサにアクセス可能なメモリ、およびメモリに格納され、かつ、ユーザーから、テンプレートの少なくとも一部分に基づく別個のネットワークリソースのスタックを生成する要求を受信することであって、前記テンプレートは前記別個のネットワークリソースを含む前記スタックを生成するための事前に入力された命令を含む、こと、前記別個のネットワークリソースの各々を識別するために前記テンプレートを解析すること、および前記ユーザーのため前記別個のネットワークリソースの各々のプロビジョニングを試行すること、が前記1つまたは複数のプロセッサ上で実行可能なテンプレートベースのスタックビルダー、を含む、装置。前記テンプレートベースのスタックビルダーはさらに、前記テンプレートベースのスタックビルダーが、前記ユーザーのために前記別個のネットワークリソースの各々のプロビジョニングに成功した場合、前記スタックのプロビジョニングが成功したことを前記ユーザーに通知すること、前記テンプレートベースのスタックビルダーが、前記ユーザーのために前記別個のネットワークリソースの少なくとも1つのプロビジョニングに成功しなかった場合、前記スタックのプロビジョニングが成功しなかったことを前記ユーザーに通知すること、のために、前記1つまたは複数のプロセッサ上で実行可能である、請求項10に記載の装置。前記テンプレートベースのスタックビルダーはさらに、前記テンプレートベースのスタックビルダーが前記ユーザーのために前記別個のネットワークリソースの少なくとも1つのプロビジョニングの成功に失敗した場合、前記テンプレートベースのスタックビルダーがプロビジョニングに成功した前記別個のネットワークリソースの各々をロールバックすること、が前記1つまたは複数のプロセッサ上で実行可能である、請求項11に記載の装置。前記要求は、ウェブアプリケーションに対する前記スタックを生成する要求を含み、前記別個のネットワークリソースは、クラウドベースの負荷分散サービス、クラウドベースの計算サービス、およびクラウドベースのストレージサービスを含む、請求項10に記載の装置。前記別個のネットワークリソースのうちの1つが、第1のエンティティによって管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成し、前記別個のネットワークリソースのうちのもう1つが、前記第1のエンティティから独立している第2のエンティティによって管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成する、請求項10に記載の装置。複数の異なるテンプレートを格納する、または複数の異なるテンプレートへアクセスするデータベースをさらに含み、前記複数の異なるテンプレートの各々は別個のネットワークリソースを含むスタックを生成するために事前に入力された命令を含む、請求項10に記載の装置。この開示は、ユーザーがアトミックな方法を用いて、リソースプロビジョニングサービスへの一回の呼び出しで複数の異なるネットワークリソースをプロビジョニングできるようにするアーキテクチャおよび技術を記述する。ある例において、複数の異なるネットワークリソースには、1つまたは複数のクラウドコンピューティングのプラットホームの部分を形成する個別のタイプのリソースを含む。例えば、1つまたは複数のエンティティはストレージサービス、負荷分散サービス、計算サービス、セキュリティサービス、または他の類似の、もしくは異なるタイプのネットワークにアクセス可能なサービス等の異なるタイプのネットワークリソースを含むクラウドコンピューティングのプラットホームをホストし操作してもよい。一例において、ユーザーは、1つまたは複数のサードパーティーエンティティにより提供された複数のネットワークリソースの使用したアプリケーション例えばウェブアプリケーションの開始を要望してもよい。ユーザーは、複数の異なるリソース間で作業負荷をルーティングする負荷分散サービス、アプリケーションをホストし、かつコンピューティング能力を提供する計算サービス、顧客データを格納するオンラインストレージサービスおよびアプリケーションのユーザーにセキュリティを提供するセキュリティサービスを要望してもよい。単一のエンティティがこれらネットワークリソースの各々を提供し操作し得るが、複数の異なるエンティティが他の実施でのこれらのリソースの1つまたは複数を提供し操作し得る。いずれにおいても、これら複数の異なるネットワークリソースをプロビジョニングするために、リソースプロビジョニングサービスはユーザーと通信し得る。例えば、ユーザーは、複数のネットワークリソースのスタックをプロビジョニングするためプロビジョニングサービスに最初の要求を行い得る。ある例において、この要求は、複数のリソースをプロビジョニングするため事前に入力された命令を含むテンプレートに基づいてもよい。このテンプレートは、スタック作成要求を記すためにユーザーに宣言型言語を提供する。これによってユーザーは、これらのスタックを構築する方法およびどのアプリケーションプログラムインターフェイスAPI呼び出しを呼び出すかではなく、どのリソースをプロビジョニングするべきか、およびこれらのリソースの相互接続に注目できる。例えば、テンプレートは、エクステンシブルマークアップランゲージXMLフォーマット、ジャバスクリプトオブジェクトノーテーションJSON等で1つまたは複数の異なるネットワークリソースをプロビジョニングするプロビジョニングサービスに命令してもよい。ある例において、その後、ユーザーは、リソースに関連した特定のパラメーターを指定するため、テンプレート内の命令を変更してもよく、変更したテンプレートを新しいテンプレートとして保存してもよい。例えば、ユーザーはストレージサービスの所望の特定のサイズ、計算サービスの所望のコンピュータの数等を指定して新しいテンプレートを作成してもよい。更に、新しいテンプレートを作成する場合、ユーザーは1つまたは複数のネットワークリソースに、またはネットワークリソースの構成要素に論理名を割り当ててもよい。例えば、ユーザーは命令の一部分を削除する、または過去呼び出されたテンプレートよりもさらに多くのネットワークリソースをプロビジョニングするため新しい命令を加える等のなんらかの方法によってオリジナルのテンプレートを変更して新しいテンプレートを作成してもよい。別の例において、ユーザーはテンプレート内で別のテンプレートをさらに呼び出してもよい。そのため、テンプレートは、複数の異なるネットワークリソースのスタックの作成で使用される構成要素となる場合がある。ユーザーが作成した命令に満足な場合テンプレートへの変更の有無に関わらず、新しいテンプレートとして命令を格納するために、ユーザーはプロビジョニングサービスに命令を戻す。例えば、ユーザーは、新しいテンプレートを含むテキストファイルを提供してもよい。このテンプレートは、XMLまたはJSONフォーマット、または他の適切なフォーマットでの命令を含んでもよい。プロビジョニングサービスが新しいテンプレートを格納した後、ユーザーはそのテンプレートを使用してまたは別のテンプレートを一緒に使用してリソースのスタックを作成する要求をしてもよい。これを受けて、プロビジョニングサービスは、所望のネットワークリソースのスタックを識別するためにテンプレートを検索し解析してもよい。例えば1つの例において、プロビジョニングサービスは、ユーザーが負荷分散サービスの特定のサイズ、計算サービスのサーバの特定の数、ストレージサービスの特定のサイズおよびセキュリティサービスの特定のタイプの採用を希望しているかということを確認し得る。これを受けて、プロビジョニングサービスは、ユーザーのために要求されたネットワークリソースの各々のプロビジョニングを試行してもよい。すなわち、プロビジョニングサービスは、負荷分散サービス、計算サービス等の所望のサービスの確保を試行してもよい。更に、プロビジョニングサービスは、互いに並行なネットワークリソースの少なくとも一部分のプロビジョニングを試行してもよい。例えば、プロビジョニングサービスは、複数のネットワークリソース間の依存を決定してもよく、これらの依存に従ったリソースのプロビジョニングを試行してもよい。プロビジョニングサービスは、テキストファイルからの暗黙的依存を識別してもよく、また、プロビジョニングサービスはユーザーにより指定された明示的依存を受信してもよい。いくつかの例において、プロビジョニングサービスは、ネットワークリソースのスタックのアトミックなプロビジョニングを試行する。すなわち、プロビジョニングサービスが要求されたネットワークリソースの各々のプロビジョニングに成功する場合、プロビジョニングサービスはスタックの作成に成功したと考えるであろう。スタックの作成に成功したことに応じて、プロビジョニングサービスはこの成功をユーザーに通知してもよい。プロビジョニングサービスが要求されたリソースの1つまたは複数のプロビジョニングに例えば試行を繰り返した後失敗した例では、プロビジョニングサービスは、スタックのプロビジョニングを失敗と見なし、プロビジョニングサービスがプロビジョニングに成功した要求リソースをロールバック、またはティアダウンしてもよい。さらに、プロビジョニングサービスはこの失敗をユーザーに通知してもよい。そのため、ユーザーは、複数のネットワークリソースのスタックをプロビジョニングするための要求の提出時に、要求したリソースがすべてプロビジョニングされるか、または、どれもプロビジョニングされないであろうことを知っている。この議論は、上で導入された技術を実施するアーキテクチャ例を記述するアーキテクチャ例という題のセクションから始まる。次に、処理例という題のセクションが続き、ここでは図1に記述されたアーキテクチャ例を使用して、複数のネットワークリソースをプロビジョニングする処理例を記載する。後続するリソースプロビジョニングサービス例および処理という題のセクションでは、図1で記述したリソースプロビジョニングサービスの特定の例およびスタックを作成、削除、採用するためのサービス例が実施し得る処理を記述する。このセクションでは、さらにこれらの処理の間に内部および外部スタック状態の遷移例を記述する。最後に、この議論を簡潔な結論で閉じる。セクションの題および対応する要約を含むこの簡潔な導入部は、読み手の便宜のために提供されたものであり、請求項、手続きセクションの範囲を制限する意図はない。更に、上述のまたはこれから記述される技術は、数多くの方法、および数多くのコンテキストで実行され得る。以下でより詳細に記述したように、いくつかの実施およびコンテキスト例は以下の図を参照して提供される。しかしながら、以下の実施およびコンテキストは数あるうちほんの一部である。アーキテクチャ例図1は、記述された技術を実行し得るアーキテクチャ例100を示す。アーキテクチャ100はユーザーコミュニティ102を含むが、これは複数のネットワークリソース1081、1082、...、108N単にリソースと呼ぶをプロビジョニングするためのリソースプロビジョニングサービス106を有するネットワーク104上で通信する。例えば、ユーザーコミュニティ102のユーザーは、1つまたは複数の大規模データセンターにおいてホストされる可能性のある1つまたは複数のクラウドコンピューティングプラットホームのサービスをプロビジョニングしてもよい。上で議論したように、これらのネットワークリソースには、ストレージサービス、負荷分散サービス、計算サービス、セキュリティサービス、ドメインネームシステムDNSサービス、または他の類似の、もしくは異なるタイプのネットワークにアクセス可能なサービスを含んでもよい。これらのリソース1081~Nはそれぞれ、共通のエンティティもしくは所有者、別個のエンティティもしくは所有者、またはそれらの組合せに関連付けられていてもよい。一方、ネットワーク104は、インターネット、ケーブルネットワーク、セルラーネットワーク、ワイヤレスネットワークおよび有線ネットワークのような複数の異なるタイプのネットワークのいずれか、またはそれらの組合せを表す。ネットワーク104はパブリックまたはプライベートネットワークであってもよい。更に、図1はいくつかの矢印を示しているが、図示したサービスの各々はネットワーク104、または異なるネットワークによって互いに直接または間接的に通信してもよい。この図示した例では、代表ユーザー1021はコンピューティング装置110を使用して、リソースプロビジョニングサービス106にアクセスしネットワークリソース1081~Nの1つまたは複数のプロビジョニングを要求する。例えば、ユーザー1021は、クラウドベースのリソースを使用して、ウェブアプリケーションの開始を要望してもよい。そのため、ユーザー1021は、負荷分散サーバの負荷分散装置、ストレージサービスのデータベース等の複数のリソースをプロビジョニングする要求を送信してもよい。リソースプロビジョニングサービス106へのアクセス、およびこのような要求を行うと、これに応じて、リソースプロビジョニングサービス106はユーザー1021のコンピューティング装置110にユーザーインターフェースUI112を提供してもよい。図1に、そのようなUIの一例を図示する。図示したように、UI112には、リソース1081~Nの特定のセットのスタックをプロビジョニングする要求に使用するテンプレートを、ユーザーが選択できる第1の領域1121を含む。UI112はさらに、ユーザー1021が、作成されることとなるスタックの名前を作成できる第2の領域1121を含む。最後に、UI例112はアイコン1123を含み、これが選択された場合、リソースプロビジョニングサービス106に要求を送信する。この要求を受信すると、リソースプロビジョニングサービス106は、以下に詳述されるように、テンプレートで指定されたリソースのスタックの作成を試行し得る。図1ではUIの一例を図示しているが、他の実施では他の類似の、または異なるUIを採用してもよい。図示したように、リソース1081~Nの各々およびリソースプロビジョニングサービス106は、要求を送受信するために処理およびストレージの能力を集合的に有する1つまたは複数のサーバとして具体化される。これらのサーバは、他のサーバアーキテクチャ例えばメインフレームを使用してもよいが、単一のサーバ、サーバのクラスター、サーバファームまたはデータセンター等を含む様々な方法で具体化されてもよい。リソースプロビジョニングサービス106は1つまたは複数のプロセッサ114ならびに、インターフェース118およびテンプレートベースのスタックビルダー120を格納するメモリ116を含む。サービス106はさらに、データベース122、124および126を格納し、それらにアクセスする。インターフェース118は、ユーザーコミュニティのユーザーがリソースプロビジョニングサービス106にアクセスし通信できるようにする、ネットワークにアクセス可能なインターフェースを含む。例えば、ユーザーコミュニティ102のユーザーはあるパブリックAPIによってインターフェースへの呼び出しを行ってもよい。これらの例および他の例において、ユーザーコミュニティ102のユーザーは、ネットワークリソース1081~Nの1つまたは複数のプロビジョニングを要求する目的でインターフェース118にアクセスする。一方、テンプレートベースのスタックビルダー120は、上述のようにユーザーからネットワークリソースのスタックを作成する要求を受信し、かつ要求に基づいてユーザーに適切なテンプレートを提供するために機能する。例えば、図示した例において、ビルダー120は、ユーザー1021により選択された特定のテンプレートを使用して、リソースの指定されたスタックをプロビジョニングするための要求を受信してもよい。これを受けて、ビルダー120は、過去に作成されたテンプレートを格納し得る、あるいはアクセスし得るデータベース124から選択されたテンプレートを見つけてもよい。ある例において、リソースプロビジョニングサービス106、ユーザーコミュニティ102のユーザーおよび/または他のエンティティが、データベース124内のテンプレートの一部または全体を過去に作成した可能性がある。選択されたテンプレートを見つけた後で、ビルダー120は、ユーザー1021のコンピューティング装置110にこのテンプレートを提供する。このテンプレートは、ネットワークリソース1081~Nの特定のセットをプロビジョニングするために事前に入力された命令を含んでいてもよい。その後、リソースに対する実際の要求を形成するために、ユーザー1021はテンプレート全体を、または一部分を使用してもよい。例えば、ユーザーは、要求されたリソースのサイズ、要求されたリソースの構成要素のいくつか例えばコンピュータ、データベース等、リソースの特定のバージョン、または他のパラメーターを指定するため、事前に入力された命令の中のあるパラメーターを変更してもよい。ある例において、ユーザー1021は、リソースの1つまたは複数の構成要素用のテンプレート内の論理名を指定してもよい。これらの論理名は、リソースプロビジョニングサービス106へのステータスまたは要求の呼び出しにより、後でこれらのリソースを管理する場合、ユーザーの便宜のためユーザーにより選択された名前を含む。その代わりに、またはそれに加えて、ユーザー1021は、さらに別のリソースを呼び出すための命令をテンプレートに追加してもよく、またはプロビジョニングからリソースを削除するのに有効な命令を取り除いてもよい。サービス106により提供されるテンプレートを修正したまたは、修正を行わなかった後、ユーザー1021は、リソースプロビジョニングサービス106によるストレージのため、変更したテンプレートを新しいテンプレートとして提出する。その後、ユーザー1021は、新しいテンプレートにより指定されたリソースをプロビジョニングするための要求を送信してもよい。ある例において、テンプレートは、エクステンシブルマークアップランゲージXMLフォーマット、ジャバスクリプトオブジェクトノーテーションJSONフォーマット等での命令を含むテキストファイルを形成してもよい。テンプレートに基づいたリソースプロビジョニングの要求を受信すると、ビルダー120は、テンプレート例えば、テキストファイル形式であり得るを検索し解析してこれらのリソースをプロビジョニングする命令と同様、所望のリソースのアイデンティティーおよびパラメーター例えばサイズ等を決定してもよい。ビルダー120はテキストファイルの実命令から収集された暗黙的依存に基づいた、および/または、ユーザー1021により提供される明示的依存に基づいた命令を特定してもよい。ファイルを解析後、次いでビルダー120は、ユーザーのために要求されたリソースの各々を、可能ならばアトミックな方法でプロビジョニングすることを試行してもよい。これらの例において、リソースプロビジョニングサービス106は、ユーザーに通知する前に、ネットワークリソース1081~Nの要求されたリソースの各々のプロビジョニングを試行する。リソースプロビジョニングサービス106が要求されたリソースの各々のプロビジョニングに成功した場合、次いでリソースプロビジョニングサービス106は、サービス106が要求されたスタックの作成に成功したことをユーザー1021に通知する。サービス106はさらに、新しくプロビジョニングされたスタックを反映するためデータベース122を更新し得る。最後に、サービス106は、データベース126により保守されているユーザー1021のアカウントへ、これらプロビジョニングされたリソースに関連した費用を課し得る。リソースプロビジョニングサービス106のビルダー120が要求された各リソースのプロビジョニングに成功しない場合例えば複数回の再試行後、サービス106は、スタック生成に失敗したことをユーザー1021に通知してもよい。さらに、サービス106は、要求されたネットワークリソースのうちサービス106がプロビジョニングに成功したリソースをロールバック、またはティアダウンしてもよい。サービス106はこれらのプロビジョニングに成功したリソースに関してユーザーアカウントに請求してもしなくてもよい。このアトミックな方法で動作することにより、サービス106が要求されたリソースのスタックのプロビジョニングに完全に成功するか、またはシステムの状態をユーザーの要求を受信する前に戻すかがわかるため、リソースプロビジョニングサービス106はユーザー1021にとって安心して使用できるものとなっている。すなわち、後者の例でも、サービス106がプロビジョニングされた各ネットワークリソースをロールバックするため、ユーザー1021は部分的には完了したが機能しないスタックとともに取り残されることはなくなるであろう。この快適さに加えて、アーキテクチャ100および関連する技術により、ユーザーは、リソースプロビジョニングサービス106に対して、各要求リソースに対応して要求を複数回行うのではなく要求を一回にできる。サービス106は、ユーザー1021に要求に基づいたテンプレートを提供することにより、この一回の呼び出しをさらに容易にする。処理例図2は、図1のアーキテクチャ100が実行し得る処理例200である。この処理全体にわたって記述した他の処理と同様は論理的な流れ図として示され、ここで各オペレーションは、ハードウェア、ソフトウェアまたはその組合せにおいて実行できるオペレーションのシーケンスを表わす。ソフトウェアのコンテキストにおいて、オペレーションは、1つまたは複数のコンピュータが読み込み可能な記憶媒体上に格納されたコンピュータ実行可能命令を表わし、1つまたは複数のプロセッサにより実行された場合、列挙されたオペレーションを行なう。一般に、コンピュータ実行可能命令は、特定機能を実行する、または特定の抽象データ型を実行するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。オペレーションが記述された命令は、限界として解釈されることを意図せず、任意の数の記述されたオペレーションは処理を実行するためあらゆる順番におよび/または並行させて組み合わせることができる。他のアーキテクチャがこの処理を実行し得るが、議論のため、処理200および他の処理を図1のアーキテクチャ100を参照して記述する。この例において、1で、リソースプロビジョニングサービス106は、ユーザー1021のコンピューティング装置110より、ユーザーのために複数の異なるネットワークリソースのスタックのプロビジョニングを試行するのに有効なあるユーザーからの新しいテンプレートを受信する。例えば、ユーザー1021はリソースプロビジョニングサービス106が提供したUIによってこのテンプレートを提出し得る。さらに、このテンプレートは過去にサービスが格納したテンプレートに基づいている可能性がある。すなわち、ユーザー1021は図1のUI112によってテンプレートを要求し受信してもよく、新しいテンプレートを形成するためにこのテンプレートを修正してもよく、次にサービス106によるストレージ用に新しいテンプレートを送信してもよい。ある例において、ユーザー1021は、リソースプロビジョニングサービス106へのテンプレート登録呼び出しによってテンプレートのストレージを要求してもよい。2で、リソースプロビジョニングサービス106は、受信したテンプレートをデータベース124に格納する。3で、リソースプロビジョニングサービス106はユーザー1021からユーザーのためにリソースのスタックをプロビジョニングする要求を受信する。この例では、ユーザー1021は、サービス106が2で格納されたテンプレートに指定された方法でリソースをプロビジョニングすることを要求する。すなわち3で、ユーザー1021は、ユーザー1021により過去に作成され、サービス106により格納されたテンプレートを呼び出し得る。もちろん他の例においては、ユーザー1021がユーザーコミュニティ102の他のユーザー、リソースプロビジョニングサービス106、および/または他のエンティティにより作成されたテンプレートを呼び出してもよい。図2は、ネットワークリソース1081~Nの1セットをプロビジョニングするためのXMLフォーマットでの命令を含むテンプレート202の例を示す。テンプレート例202にこれらの命令の一フォーマット例を示すが、提供されるテンプレートには、ユーザーがネットワークリソース1081~Nの複数のリソースのプロビジョニングを要求できる他のテキストベースの命令、選択可能なアイコン、ラジオボタンまたは他のインターフェースグラフ式、または他の方法を含んでもよい。この例では、4で、リソースプロビジョニングサービス106は、ユーザー1021がユーザーの要求を記載したテンプレートを検索する。この例において、ユーザー1021は、ユーザーにより作成され、最近格納されたテンプレートを指定し、よって、サービス106はデータベース124からこのテンプレートを検索する。上で議論したように、ユーザー1021はこのテンプレートをカスタマイズした可能性がある。例えば、ユーザー1021にはリソースの特定のバージョン、リソースのサイズ、リソースの論理名等のあるパラメーターの値を指定している可能性がある。5で、リソースプロビジョニングサービス106はテンプレートを解析し、ネットワークリソース1081~Nのうち要求されたリソースを識別し、かつこれら要求されたリソースのプロビジョニングを試行する命令を識別する。サービス106はこの命令の全体、または一部を暗黙および/または明示的依存に基づいて作成し得る。サービス106はユーザー1021が要求するリソースの特性を分析することで暗黙的依存を識別し得る。サービス106は、ユーザー1021からこれら依存を明示的に受信して明示的依存を識別し得る。例えば、ユーザー1021は、リソースのプロビジョニングを試行する所望の命令の全体または一部を宣言し得る。6で、リソースプロビジョニングサービス106は、要求されたネットワークリソースのプロビジョニングを、可能ならば決定した順に、試行する。この例では、ユーザー1021は、ネットワークリソース1081、1082および108Nのプロビジョニングを要求している。ある例において、リソースプロビジョニングサービス106は、これらの要求されたリソースのうち少なくともいくつかのプロビジョニングを並列に試行する。7で、リソースプロビジョニングサービス106は個々のリソースから、サービス106がそれぞれのリソースのプロビジョニングに一回または複数回のトライ後成功したかどうかを示す表示を受信する。この例では、個々のリソースが成功の表示を提示しているので、リソースプロビジョニングサービス106は、スタックの生成は成功したと見なす。そのため、リソースプロビジョニングサービス106は、新しいスタックを反映するために8でデータベース122を更新する。リソースプロビジョニングサービス106は、さらにユーザー1021のアカウントにこのスタックを関連付け、ユーザー1021のアカウントに作成されたリソースに関する請求を行うためデータベース126を更新してもよい。最後に、9で、リソースプロビジョニングサービス106は、ユーザー1021に成功または失敗の表示を提示する。例えば、リソースプロビジョニングサービス106はコンピューティング装置110にこの表示を提示してもよく、または別の通信チャンネルによりこの表示を伝達してもよい。この例で、リソースプロビジョニングサービス106は、ユーザー1021のために要求されたネットワークリソース1081、1082および108Nの各々のプロビジョニングにサービス106が成功したという表示を提示する。ある例において、ユーザー1021は、9で表示を受信する前に、要求したスタック作成のステータスに関する質問を送信してもよい。サービス106はこの要求に応えて、ユーザー1021に、スタックの作成に成功したかどうかを通知してもよい。図3は、複数の異なるネットワークリソースのプロビジョニングのため、リソースプロビジョニングサービス106が実行し得る処理例300の流れ図である。ここで、処理300は、サービスが要求された各リソースのプロビジョニングに成功する、または要求されたリソースのいずれもプロビジョニングできないアトミックな処理を含み得る。処理300は、302でクライアントのコンピューティング装置からテンプレートを受信し、これに応じて受信したテンプレートを格納するリソースプロビジョニングサービス106を含む。このテンプレートは、ネットワークリソースのスタックのプロビジョニングを促進し得る。304で、リソースプロビジョニングサービス106は、テンプレートを使用した、ネットワークリソースのスタックをプロビジョニングするための要求を受信する。ある例において、テンプレートおよび要求は同時に受信され得る例えば、テンプレートが要求を含み得るが、必ずしもそうである必要はない。306で、リソースプロビジョニングサービス106はテンプレートを解析してリソースを識別し、308で、リソースプロビジョニングサービス106は、識別されたリソースの各々のプロビジョニングを試行する。310で、リソースプロビジョニングサービス106は、それぞれのプロビジョニングの試みが成功したかどうか判断する。成功しなかった場合、リソースプロビジョニングサービス106は312でプロビジョニングに成功したネットワークリソースをロールバックする。ある例においては、サービスは一回のリソースの呼び出しが失敗するとすぐにリソースのプロビジョニングの試行を中止する。いずれかの例で、リソースプロビジョニングサービス106はさらに、314で要求ユーザーへの失敗の通知へ進む。ある例において、リソースプロビジョニングサービス106はまた、プロビジョニングに成功したリソースに関して要求ユーザーのユーザーアカウントに例えば、全スタックの生成が成功するかどうかに関わらずサービス106がこれらのリソースのプロビジョニングに成功したらすぐに請求してもよい。しかしながら、もしリソースプロビジョニングサービス106が、各プロビジョニングの試みに成功したと判断した場合、次いでリソースプロビジョニングサービス106は316でこの成功を要求ユーザーに通知する。318で、リソースプロビジョニングサービス106は、プロビジョニングに成功したリソースに関して要求ユーザーのユーザーアカウントに請求してもよい。リソースプロビジョニングサービス例と処理図4は、図1のリソースプロビジョニングサービス106の一例を詳細に示す。図示したように、リソースプロビジョニングサービス106はインターフェース118およびテンプレートベースのスタックビルダー120を含んでおり、これは、上で議論した通りである。一例では、テンプレートベースのスタックビルダー120はスタックビルダーサービス402、スタックビルダーデーモン404および1つまたは複数のスタック管理ワークフロー406を含んでもよい。上で議論した通り、インターフェース118は、ユーザーコミュニティ102のユーザーによるパブリックAPIを通じた呼び出しを可能にするネットワーク側の構成要素である。この層の1つの機能はネットワークリソース1081~Nへの要求を受理、検証、証明、認証、ルーティングすることである。他の機能にはスロットリング、要求ロギングおよび委任トークン交換を含む。インターフェース118は、ネットワークリソース1081~Nに対して以下の1つまたは複数のAPIをプロキシし得る:RegisterTemplate、DescribeTemplates、DeleteTemplate、CreateStack、DescribeStack、DeleteStack、DescribeStackResources、DescribeStackEvents、およびAdoptStack。一方、スタックビルダーサービス402は、インターフェース118が引き受けている様々なAPIの具体的な実行を提供する。このサービス402はさらに1つまたは複数の内部APIを提供し得る。このサービスにより提供されるAPIは、ある例においては、テンプレート管理API、スタック管理APIおよび監査証跡APIとして分類できる。テンプレート管理APIは、例えば図1のデータベース124においてテンプレートのストレージおよび処理にあたる。生の、ユーザーが提供したテンプレートは受理および認証され、その後生のオリジナルとの並行したストレージのため正準/縮減形に転換される。スタックビルダーサービス402は、名前によりこれらアップロードされたテンプレートを調べて、使用すべきでないとマークを付ける能力を提供する。テンプレート管理APIの例にはRegisterTemplate、DescribeTemplate、および/またはDeleteTemplateを含んでいてもよい。一方、スタック管理APIは、スタックの作成および削除を開始し、スタックの記述を得るためのエントリポイントである。スタックの作成および削除の呼び出しは非同期的な方法で扱われてもよい。すなわち、スタックビルダーサービス402は、スタックの作成および削除のためのユーザー要求を検証し記録する。一方、スタックビルダーデーモン404は、ユーザーの意思の実際の処理を非同期に扱う。スタック管理APIは、さらに基盤となるストレージへスタックリソースデータの読み取りおよび書込みを可能にする。ユーザーコミュニティ102のユーザーは、これらのAPIによってそれらスタックのリソースのための論理的物理的結合の検査を要求できる。同様に、スタック管理ワークフロー406がスタックのリソースを割り当てる、または割り当てを開放する場合、スタック管理ワークフロー406は、物理的論理的マップを記録/更新するためにスタック管理APIを使用する。スタック管理APIにはCreateStack、DescribeStack、DeleteStack、AdoptStack、DescribeStackResources、AddStackResource内部APIおよび/またはDeleteStackResource内部APIを含んでいてもよい。スタックビルダーサービス402はさらに監査証跡APIを保持してもよく、これによりユーザーのために行なわれたリソース作成/削除アクションの記録が可能となる。いくつかの例において、各アクションは、データベース126の各ユーザーアカウントに請求された費用のログを保持する目的で記録される。さらに、データベース126内にアカウントを有するユーザーコミュニティ102の各ユーザーは、DescribeStackEventsAPIを呼び出すことによりユーザーのログを検索してもよい。監査証跡APIはDescribeStackEventおよび/またはAddStackEventを含んでいてもよい。一方、スタックビルダーデーモン404は、スタック管理ワークフロー406と上述のジョブ状態のストレージとの統合にあたる。このデーモン404は、新しい/開始されなかった要求があるかどうかスタック要求テーブルを定期的に点検してもよく、これらの要求を扱うためにスタック管理ワークフロー406を生成してもよい。スタックビルダーデーモン404はさらに既存のスタック管理ワークフロー406を定期的に点検してもよく、ジョブ格納記録でこれらのワークフローのうちのいくつかを完了したものとしてマークしてもよい。これは、あらゆるフロントエンドのサービスからのスタック管理ワークフロー406呼び出しを効果的に切り離し得る。最後に、スタック管理ワークフロー406は、スタック削除中のネットワークリソース1081~Nの正常なシャットダウンと終了の間と同様、スタック作成中にネットワークリソース1081~Nの作成および構成のための様々なステップの実行にあたる。図5は、図1と図4のリソースプロビジョニングサービス106のスタック管理ワークフロー例406を示す。図示したように、スタック管理ワークフロー例406はシンプルワークフローサービスSWF502上に構築される。スタック管理ワークフロー406はスタック作成ワークフロータイプおよびスタック削除ワークフロータイプの2つのワークフロータイプを含む。スタック作成ワークフロータイプはスタック作成決定者504に関連付けられ、一方、スタック削除ワークフロータイプはスタック削除決定者506に関連付けられる。さらに、これらのワークフローは、対応する作成アクティビティ508、記述アクティビティ510および削除アクティビティ512に対応づけられ、これらは一緒になってスタックのコンテキストにおいてネットワークリソース1081~Nの作成、記述および削除を可能にする。図6は、図1、4および5のアーキテクチャ内のテンプレートを使用したスタックを作成する処理例600を示す。1で、ユーザー例1021はスタック作成APIを呼び出し、インターフェース118へテンプレート名およびスタック名を渡す。2で、認証サービス602は要求を認証する。3で、インターフェース118は、スタックビルダーサービス402、および特にスタックビルダーサービス402のAPIサーバ604に要求を委任する。スタックビルダーサービス402は、最初にスタック名を検証し、スタックリソース606を参照することにより選ばれた名前が別のスタックの複製ではないことを保証する。その後、スタックビルダーサービス402は、テンプレートメタデータ608を参照してテンプレート名が有効かどうかを確認する。スタック名およびテンプレート名の両方が有効な場合、スタックビルダーサービス402はスタックメタデータSDBテーブル610においてスタックメタデータネームスペース,スタック名,テンプレート名,Status=CREATE_PENDINGを固持し、成功した応答はユーザー1021に送信される。4で、スタックビルダーデーモン404は、Status=CREATE_PENDINGのスタックをピックアップし、ネームスペース、テンプレートlD、スタックIDを作成されたワークフローに渡して、スタック作成ワークフローを始める。その後、デーモン404は、それらスタックのステータスをCREATE_IN_PROGRESSに更新する。デーモン404はさらに、スタック作成が進行中であることを示す監査証跡エントリを、監査証跡テーブル612へ入れる。5で、スタック作成ワークフロータイプのスタック作成決定者504は、決定イベントのためSWF502を定期的にポーリングする。スタック作成決定者504の1つまたは複数がSWF502からワークフロー開始要求を受信する場合、それぞれの決定者504は作成ワークフロー要求の処理を開始する。6で、スタック作成要求を受信すると、スタック作成決定者504は、スタック作成に関する監査証跡テーブル612へエントリを入れる。7で、スタック作成決定者504はテンプレートサービス例えばテンプレートメタデータ608とコンタクトを取り、所与のテンプレートIDのテンプレートの内部表現を取得する。テンプレートを取得すると、決定者504は、リソースを作成する命令を計算する。これは、テンプレートもしくはテキストファイルからの暗黙的依存、またはユーザー1021により指定された明示的依存に基づいているかもしれない。一旦、決定者504がリソース作成の命令を決定すると、決定者504は、ネットワークリソース1081~Nのうちの1つの作成と構成を成功させるため、計算リストにネットワークリソース1081~Nに対応するリソース作成アクティビティ508の第1セットをテンプレートでキャプチャーされた構成メタデータと一緒にスケジューリングする。8で、リソース作成アクティビティ508は、作業のためSWF502を定期的にポーリングする。9で、SWF502から特定のリソースを作成し構成するための作業を受信すると、リソース作成アクティビティ508は、リソースを作成し構成するために対応するネットワークリソースとコンタクトを取る。一旦、リソースへの作成リソース呼び出しが正常に返されると、リソース作成アクティビティ508は、アクティビティの正常完了によって、リソースの作成に成功したことをSWF502に示す。アクティビティにより作成に成功したリソースの物理的な識別子は、アクティビティの完成表示に添付されてもよい。しかしながら、リソース作成アクティビティ508がリソースからエラー/失敗を受信する場合、アクティビティ508はactivityfailedAPIによってSWF502に失敗を報告する。アクティビティ508によりリソースから取得されたエラー/失敗メッセージは、SWF502へのアクティビティ失敗呼び出しに添付されてもよい。10で、スタック作成決定者504は、作業のためSWF502を定期的にポーリングする。11で、スタック作成決定者504のうちの1つが、リソース作成アクティビティ508が正常に完了したことを示す情報を受信する場合、その後、スタック作成決定者504は、作成されたリソースに関する情報で結合サービスを更新する。これは、物理リソース識別子および作成タイムスタンプへの論理リソース識別子のマッピングを含む。決定者504はさらに、リソースの作成成功に関するエントリを、監査証跡テーブル612へ入れる。その後、決定者504は、作成されたリソースのステータスを記述するためにリソース記述アクティビティ510をスケジューリングする。決定者504が、リソース作成アクティビティがタイムアウトしたという情報を得る場合、決定者504は次いで、リソース作成アクティビティ508の指定回数と終了を再度スケジューリングする。アクティビティ508が正常に完了するまで、またはリトライが最大回数に到達するまで、ステップ8から11を繰り返してもよい。リソース作成アクティビティのリトライが最大回数に到達している場合、決定者504は監査証跡テーブル612へ対応するエントリを入れ、ワークフローの終了を開始する。決定者504が、リソース作成アクティビティ508が失敗したという情報を得る場合、決定者504は、アクティビティ508により返されたエラーコードを調査する。エラーコードに基づいて、決定者504は、アクティビティタイムアウトに類似した方法でエラーを扱ってもよく、アクティビティをリトライしてもよい。反対に、エラーコードに基づいて、決定者504は、アクティビティのリトライを行わないことを決定してもよく、その代り、リソース作成における失敗に関する情報で結合サービスを更新してもよい。この更新は、リソース作成を試行する間にアクティビティ508により受信されたエラーメッセージを記録し、対応するエントリを監査証跡テーブル612に入れ、ワークフローの終了を開始することを含んでもよい。決定者504がワークフローの終了を開始する場合、以下のステップのシーケンスが実行され得る。まず決定者504はCREATE_FAILEDタグでワークフロー記録の状態フィールドを使用してワークフローに注釈を付ける。一旦、ワークフローがCREATE_FAILEDタグで注釈付けされると、決定者504はそのワークフローに対してそれ以上のアクティビティをスケジューリングしない。あるいは、一旦、ワークフローに過去にスケジューリングされたリソース作成アクティビティ508が動作を止めていると例えば、完成もしくは失敗、またはリトライの最大数に到達すると、決定者504はスタックの作成に成功できなかったことを示すエラーメッセージと共にワークフローをCloseWorkflowSWFAPIにより終了する。12で、リソース記述アクティビティ510は、作業のためSWF502を定期的にポーリングする。13で、SWF502から特定のネットワークリソースを記述するための作業を受信すると、リソース記述アクティビティ510は、リソースのステータスをチェックするために対応するネットワークリソースとコンタクトを取る。リソースがアクティブ状態である場合、アクティビティ510は正常に完了する。他の場合には、アクティビティ510はSWF502に失敗を報告する。14で、スタック作成決定者504は、作業のためSWF502を定期的にポーリングする。スタック作成決定者504が、リソース記述アクティビティ510が正常に完了したことを示す情報を取得した場合、決定者504は監査証跡テーブル612へ対応するエントリを入れ、再度テンプレートサービス例えばテンプレートメタデータ608とコンタクトを取りテンプレートの内部表現を取得する。決定者504は、所与のスタックに対して作成されたワークフロースタックヒストリーから取得されたリソースとテンプレートに記述されているリソースを比較し、まだ作成されていないリソースを決定する。作成されるリソースのセットが空の場合、それはスタックの作成に成功したことを示し、決定者504はワークフローを終了させる。しかしながら、リソースがまだ作成されていない場合、決定者504は、リソース作成アクティビティ508の次のバッチをスケジューリングする。全スタックが構築されるまで、処理600はステップ8から14を繰り返してもよい。15で、決定者504が、リソース記述アクティビティ510がタイムアウトしたまたは失敗したことを示す情報を受信する場合、その後、決定者504は、リソース作成アクティビティ510の指定回数と終了を再度スケジューリングする。処理600は、アクティビティが正常に完了するまで、またはリトライが最大回数に到達するまで、ステップ12から14を繰り返してもよい。リソース作成アクティビティ508のリトライが最大回数に到達している場合、決定者504は監査証跡テーブル612へ対応するエントリを入れ、ワークフローの終了を開始する。決定者がワークフローを終了させる処理は、ステップ10で詳述したものと同じであってもよい。16で、スタックビルダーデーモン404は、ワークフローがstatus=CREATE-IN-PROGRESSのスタックが完了したかどうかをチェックするためSWF502を定期的にポーリングする。一旦、スタックビルダーデーモン404が、スタックの作成が正常に終了したことを知ると、スタックビルダーデーモン404はCREATE-COMPLETEとしてスタックのステータスをマークする。しかしながら、スタックビルダーデーモン404がスタック作成に失敗したことを、ワークフローステータスのCREATE-FIELDタグにより認める場合、デーモン404はCREATE-FAILEDとしてスタックのステータスをマークする。失敗したスタック作成のクリーンアップの詳細は、後のスタック削除セクションにおいて議論される。一旦、スタック作成ワークフローが終了すると、スタックビルダーデーモン404は、エントリをスタック作成の成功/失敗に関する監査証跡テーブル612へ入れる。図7は、図1、4および5のアーキテクチャ内のスタックを削除する処理例700を示す。1で、ユーザー例1021は、インターフェース118にスタック名を渡すDeleteStackAPIを呼び出す。2で、認証サービス602は要求を認証する。3で、インターフェース118はスタック名が検査されるスタックビルダーサービス402に要求を委任する。対応するスタックのステータスはDELETE_PENDINGとしてマークされる。4で、スタックビルダーデーモン404はDELETE_PENDINGステータスのスタックを探し、SWF502とコンタクトを取りスタック削除タイプのワークフローを始める。ワークフローへの入力はスタックID、およびスタックが使用するテンプレートIDを含む。ここで、スタックメタデータ610のスタックのステータスは、DELETE_IN_PROGRESSに更新される。スタックビルダーデーモン404は、エントリを削除スタートが開始されたことを示す監査証跡テーブル612に書く。5で、スタック削除ワークフロータイプの決定者506は、決定イベントのためSWF502を定期的にポーリングする。スタック削除決定者506の1つまたは複数がSWF502からワークフロー開始要求を受信する場合、決定者506はスタック削除要求の処理を開始する。6で、スタック削除要求を受信すると、決定者506は監査証跡テーブル612へ対応するエントリを入れる。7で、決定者506はテンプレートサービス例えばテンプレートメタデータ608とコンタクトを取り、削除されるスタックに対応したテンプレートを取得する。テンプレートを受信すると、決定者506は、リソースを削除する命令を処理する。これは、スタックおよび/もしくはテンプレートにおいて暗黙的である依存、ならびに/またはユーザー1021が提示した明示的依存に基づいてなされ得る。8で、ステップ7で計算されたリソース命令に基づいて、決定者506は、物理リソース識別子、およびDELETED状態でないリソースのリソースタイプを取得するため、結合サービスとコンタクトを取る。リソースタイプおよび識別子を取得すると、決定者506は、所与のスタックの一部分であるリソースを削除するために適切なリソース削除アクティビティ512をスケジューリングする。決定者506がDELETED状態にないリソースを一つも見つけることができない場合、スタックの削除は完了している。その後、決定者506はワークフローを終了する。9で、リソース削除アクティビティ512は作業のためSWF502を、定期的にポーリングする。10で、SWF502からネットワークリソースを削除するための作業を受信すると、リソース削除アクティビティ512は、リソース削除するために対応するネットワークリソースとコンタクトを取る。特定のリソース削除アクティビティ512への入力には、削除されるリソースの物理的な識別子を含む。リソースに削除要求を提出すると、リソース削除アクティビティ512は、リソースのステータスをチェックするために対応するリソースを定期的にポーリングする。一旦、リソースが要求されたリソースの削除に成功したと宣言すると、アクティビティ512は、アクティビティ512の正常完了によって、SWF502に削除が成功したことを示す。ネットワークが特定のエラータイプを返す場合、アクティビティ512は決定者506に失敗を報告し、ActivityFailedAPIと一緒にリソースにより返されたエラーメッセージを添付する。11で、スタック削除ワークフロータイプの決定者506は、決定イベントのためSWF502を定期的にポーリングする。12で、アクティビティ完了に関する情報を得ることで、結合サービスはスタック内のリソースの削除を反映するために更新される。決定者506は成功したリソース削除に関する監査証跡テーブル612へ、対応エントリを入れる。全スタックが削除されるまで、処理700はステップ7から12を繰り返してもよい。決定者506が、リソース削除アクティビティ512がタイムアウトした、または失敗したという情報を受信する場合、決定者506はリソース削除アクティビティ506を指定回数分再度スケジューリングする。リトライ試行が最大回数に到達している場合、決定者506は、結合サービスのリソースのステータスおよび理由フィールドをDELETE_FAILEDと最大削除試行回数に到達に更新する。決定者506は、さらに監査証跡テーブル612に対応エントリを入れ、ワークフローメタデータのステータスフィールドを使用して、ワークフローにDELETE_FAILEDタグの注釈を付ける。13で、スタックビルダーデーモン404は、ワークフローがstatus=DELETE_IN_PROGRESSのスタックに対して終了されているかどうかをチェックするため定期的にSWF502をポーリングする。一旦、スタックの削除が正常に完了したことがわかると、スタックビルダーデーモン404は、スタックのステータスをDELETE_COMPLETEへマークする。ワークフローにDELETE_FAILEDタグの注釈が付けられたことをデーモン404が発見する場合、スタックのステータスをDELETE_FAILEDへ更新する。いくつかの例において、スタックの作成が進行中である間、およびスタックが完全に作成される前に、ユーザー例1021が、スタックの削除を開始する場合がある。この例において、リソースプロビジョニングサービス106はこれをスタックの作成を終了させるための要求と解釈し得る。このシナリオの下で、スタックビルダーサービス402はスタックのステータスをCREATE_CANCEL_PENDINGとしてマークする。スタックビルダーデーモン404はCREATE_CANCEL_PENDINGステータスのスタックをスキャンし、ワークフローの終了を要求する対応するスタック作成ワークフローにノートを付ける。その後、スタックビルダーデーモン404は、スタックのステータスをCREATE_CANCEL_IN_PROGRESSへ更新する。ノートイベントの受信で、スタック作成決定者504は、未処理のアクティビティが動作をやめるのを待つことでワークフローの終了を開始する。ワークフローを終了するための手順は、スタック作成シナリオにおいて上述された手順と同じであってもよい。スタックビルダーデーモン404は、スタック作成ワークフローがステータスCREATE_CANCEL_IN_PROGRESSであるスタックに対して終了されるかどうかをチェックするために定期的にSWF502をポーリングする。一旦、スタックビルダーデーモン404が、スタック作成が終了したことを発見すると、スタックビルダーデーモン404は、スタックのステータスをDELETE_PENDINGにマークする。スタック削除の処理は、スタック作成中に作成されたあらゆるリソースをクリーンアップする。図8は図1、4および5のアーキテクチャ内のスタックを採用する処理例の図である。1で、ユーザー例1021は、AdoptStackAPIを呼び出して、テンプレート名、スタック名およびスタック結合をキャプチャーするマップを渡す。2で、認証サービス602は要求を認証する。3で、インターフェース118は、スタック名を検証する例えば、複製などがあるかチェックするスタックビルダーサービス402に要求を委任する。スタック名が無効の場合、フォルトがユーザーに返される。スタックビルダーサービス402が、テンプレート名の検証を試行し、テンプレート名が有効な場合、サービス402は次いで、テンプレート名により識別されたテンプレート、および結合マップが互いに一致していることを保証するためにスタックの結合マップの中身を検証する。テンプレート名が無効であるか、名前および結合マップにより識別されたテンプレートが矛盾する場合、フォルトがユーザーに返される。4で、スタックビルダーサービス402は次いでテンプレートに記録されたリソースを記述するDescribeResourceAPIを呼び出し、結合マップに記録されたリソースが存在しユーザー1021により所有されることを確認する。結合マップに記録されたリソースがどれも存在しない場合、フォルトがユーザーに返される。スタックビルダーサービス402は、スタックのため一意の識別子を作成し、結合マップの中にある結合情報で新しく生成されたスタックの識別子に対して結合サービスに新しいエントリを挿入する。スタックビルダーサービス402はさらに、ユーザーが提供したスタック名および生成されたスタックの識別子の間の関連性を追加/更新するため、スタックメタデータテーブル610を挿入/更新する。スタックビルダーサービス402はさらに、スタックの採用を示す監査証跡テーブル612へエントリを挿入する。図9は、スタックの作成または削除要求間の、内部スタック状態の遷移例を示す。この例で、902に示すように、スタック状態例の内部状態は最初にスタック作成保留に設定される。904で、リソースプロビジョニングサービス106はスタック作成ワークフローを開始する。906に示すように、これは内部スタック状態を作成中に変化させる。しかしながら、サービス106が908で示すようなスタックを削除する要求を受信する場合、910に示すように、内部スタック状態は作成キャンセル保留になる。サービス106は、状態が作成中906で示すようにである間、912のスタックを削除する要求をさらに受信する場合がある。これを受けて、内部スタック状態は910に示すように作成キャンセル保留へさらに遷移するだろう。スタック作成ワークフローが進行中で、スタックを削除する要求が受信されない場合、サービス106は、スタック作成ワークフローが成功するかどうか914で判断する。成功した場合、その後内部スタック状態は916の作成完了に遷移する。成功しなかった場合、内部スタック状態は918の作成失敗に遷移する。前者の例において、サービス106は、920でスタックを削除する要求を受信する場合がある。この例で、内部スタック状態は922で示されるように、削除保留へ遷移する。内部スタック状態が作成失敗となる例では、遷移900は924でスタックのクリーンアップを開始する。その後、内部スタック状態は922で示した削除保留に遷移する。910の作成キャンセル保留の内部スタック状態に戻ると、上で議論したように遷移900は926でスタック作成ワークフローにノートを付ける。その後、内部スタック状態は928の作成キャンセル中に遷移する。その後、スタック作成ワークフローは930で完了し、922で示すように、スタック状態は削除保留に更新される。内部スタック状態が削除保留である場合、スタック削除ワークフローは932から始まる。934で示したように、その後、内部スタック状態は削除中へ移行する。936で、サービス106はスタック削除ワークフローが正常に完了したかどうか判断する。正常に完了した場合、その後、内部スタック状態は938の削除完了に移行する。正常に完了しなかった場合、その後内部スタック状態は940の削除失敗に遷移する。その後、サービス106はワークフローをクリーンアップし、942でスタックを削除する要求を再度受信してもよい。これを受けて、内部スタック状態は922で示されるような削除保留に遷移する。図10は、スタックの作成または削除要求間の、外部スタック状態の遷移例1000を図示する。この例において、1002で示されるように、スタック状態例の外部状態は最初に作成中に設定される。1004で、リソースプロビジョニングサービス106は、作成が成功するかどうか判断する。成功した場合、その後外部スタック状態は、1006の作成完了へ遷移する。成功しなかった場合、外部スタック状態は1008の作成失敗に遷移する。1010で、サービス106は、スタックの削除要求を受信する。そのため、外部スタック状態は1012の削除中に遷移する。1014で、サービス106は、削除が成功したかどうか判断する。成功した場合、その後、外部スタック状態は1016の削除完了になる。成功しなかった場合、その後、外部スタック状態は1018の削除失敗になる。その後、1010で示したように、サービス106は再びスタックの削除要求を受信してもよい。条項1。実行された場合、複数の異なるネットワークリソースの各々に関連した1つまたは複数のパラメーターに従って、複数の異なるネットワークリソースのスタックをプロビジョニングするために少なくとも一部分が有効である、事前に入力された命令を含むテンプレートをユーザーのコンピューティング装置から受信すること;受信を受けてテンプレートを少なくとも部分的に格納すること;コンピューティング装置から、テンプレートを使用して複数の異なるネットワークリソースのスタックをプロビジョニングするための要求を受信すること;プロビジョニングを要求された複数の異なるネットワークリソースの各々、および関連する1つまたは複数のパラメーターの各々を識別するためにテンプレートを検索し解析すること;および解析を受けて少なくとも部分的に、ユーザーのために関連する1つまたは複数のパラメーターに従った、複数の異なるネットワークリソースの各々のプロビジョニングを試行することを含む行為を1つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令を格納する1つまたは複数のコンピュータが読み込み可能な媒体。条項2。複数の異なるネットワークリソースがストレージサービス、負荷分散サービス、計算サービスまたはセキュリティサービスを含む、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項3。複数の異なるネットワークリソースが、クラウドコンピューティングプラットホームの少なくとも一部分を形成する、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項4。複数の異なるネットワークリソースの各々に関連した1つまたはパラメーターが、各ネットワークリソースの要求サイズ、能力または特性を指定する、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項5。テンプレートが、ユーザーにより指定された論理名により複数の異なるネットワークリソースの少なくとも1つを識別する、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項6。テンプレートが、複数の異なるネットワークリソースの少なくとも1つに対して複数の異なるバージョンの特定のバージョンを指定する、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項7。複数の異なるネットワークリソースの各々のプロビジョニングの試行が、複数の異なるネットワークリソースの少なくとも2つの並行したプロビジョニングの試行を含む、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項8。複数の異なるネットワークリソースの各々のプロビジョニングの試行が、少なくとも一部分が複数の異なるネットワークリソースの部分間で指定された依存に基づいた順番で、複数の異なるネットワークリソースの各々のプロビジョニングを試行することを含む、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項9。指定された依存が暗黙的依存を含み、テンプレートの解析が複数の異なるネットワークリソースの部分間の暗黙的依存を識別するのに有効である、条項8に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項10。指定された依存にユーザーにより指定された明示的依存を含む、条項8に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項11。実行された場合、複数の異なるネットワークリソースの各々のプロビジョニングの成功を受けて、スタックが少なくとも部分的にプロビジョニングされたとユーザーに通知することを含む行為を1つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令をさらに格納している、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項12。実行された場合、複数の異なるネットワークリソースのうちの1つのプロビジョニングが失敗したという表示を受信すること;および表示の受信を受けて、複数の異なるネットワークリソースのうち少なくとも部分的にプロビジョニングに成功した各リソースをロールバックすることを含む行為を1つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令をさらに格納している、条項1に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項13。実行された場合、表示を受けてスタックのプロビジョニングが少なくとも少なくとも部分的に失敗したとユーザーに通知すること含む行為を1つまたは複数のプロセッサに実行させる、コンピュータ実行可能命令をさらに格納している、条項12に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項14。実行可能命令で構成された1つまたは複数のコンピュータシステムの制御下で、ユーザーから、テンプレートによって識別された複数の異なるネットワークリソースのスタックをプロビジョニングするための要求を受信すること;プロビジョニングを要求された複数の異なるネットワークリソースの各々を識別するためにテンプレートを解析すること;解析を受けて複数の異なるネットワークリソースの各々を少なくとも部分的にプロビジョニングすることを試行することを含み、複数の異なるネットワークリソースの各々のプロビジョニングに成功した場合、ユーザーにスタックのプロビジョニングが成功したことを通知し;および複数の異なるネットワークリソースの1つまたは複数のプロビジョニングに成功しなかった場合、ユーザーにスタックのプロビジョニングが成功しなかったことを通知する、方法。条項15。複数の異なるネットワークリソースの各々はクラウドコンピューティングプラットホーム上に存在する、条項14に記載の方法。条項16。ユーザーに関連したユーザーアカウントを維持することをさらに含み、複数の異なるネットワークリソースのプロビジョニングの試行が、ユーザーのために複数の異なるネットワークリソースのプロビジョニングを試行して、ネットワークリソースのプロビジョニングの成功に関連した費用が、ユーザーに関連したユーザーアカウントに請求される、条項14に記載の方法。条項17。前記テンプレートが、前記複数の異なるリソースの少なくとも2つをプロビジョニングする要求のため事前に入力された命令を含む、条項14に記載の方法。条項18。テンプレートが、複数の異なるネットワークリソースの各々への呼び出しを有するテキストベースの命令を含むテキストファイルを含む、条項14に記載の方法。条項19。テンプレートが、複数の異なるネットワークリソースの少なくとも1つに対して複数の異なるバージョンの特定のバージョンを指定する、条項14に記載の方法。条項20。テンプレートが、ユーザーにより選択された複数の異なるネットワークリソースのうちの1つのコンポーネントに論理名を指定する、条項14に記載の方法。条項21。テンプレートの解析が、複数の異なるネットワークリソースの中の暗黙的依存を識別するためテンプレートを解析することを含み、複数の異なるネットワークリソースのプロビジョニングの前記試行が、少なくとも一部分が前記暗黙的依存に基づいた順番における前記複数の異なるネットワークリソースのプロビジョニングの試行を含む、条項14に記載の方法。条項22。要求が、複数の異なるネットワークリソースの少なくとも2つの間の依存性を明示的に指定し、複数の異なるネットワークリソースのプロビジョニングの前記試行が、少なくとも一部分が依存に基づいた順番における前記複数の異なるネットワークリソースのプロビジョニングの試行を含む、条項14に記載の方法。条項23。複数の異なるネットワークリソースのプロビジョニングの試行が、複数の異なるネットワークリソースのうち少なくともいくつかのプロビジョニングを並行して試行することを含む、条項14に記載の方法。条項24。前記複数の異なるネットワークリソースの1つまたは複数のプロビジョニングに成功しなかった場合、プロビジョニングに成功した複数の異なるネットワークリソースのリソースをティアダウンすることをさらに含む、条項14に記載の方法。条項25。1つまたは複数のプロセッサ;1つまたは複数のプロセッサによりアクセス可能なメモリ;およびメモリに格納され、1つまたは複数のプロセッサ上で、別個のネットワークリソースのスタックをテンプレート上の少なくとも一部分に基づいて作成する要求をユーザーから受信し、テンプレートは別個のネットワークリソースを含む前記スタックを作成するために事前に入力された命令を含み;別個のネットワークリソースの各々を識別するためにテンプレートを解析し;およびユーザーのため前記別個のネットワークリソースの各々のプロビジョニングを試行するために実行可能なテンプレートベースのスタックビルダーを含む、装置。条項26。テンプレートベースのスタックビルダーがユーザーのために別個のネットワークリソースの各々のプロビジョニングに成功した場合、スタックのプロビジョニングが成功したことを前記ユーザーに通知し;前記テンプレートベースのスタックビルダーが前記ユーザーのために前記別個のネットワークリソースの少なくとも1つのプロビジョニングに成功しなかった場合、前記スタックのプロビジョニングが成功しなかったことを前記ユーザーに通知するために、前記テンプレートベースのスタックビルダーが前記1つまたは複数のプロセッサ上でさらに実行可能である、条項25に記載の装置。条項27。前記テンプレートベースのスタックビルダーが前記ユーザーのために前記別個のネットワークリソースの少なくとも1つのプロビジョニングに成功しない場合、前記テンプレートベースのスタックビルダーがプロビジョニングに成功した前記別個のネットワークリソースの各々をロールバックするために、前記テンプレートベースのスタックビルダーが前記1つまたは複数のプロセッサ上でさらに実行可能である、条項26に記載の装置。条項28。要求が、ウェブアプリケーションに対するスタックを作成する要求を含み、別個のネットワークリソースがクラウドベースの負荷分散サービス、クラウドベースの計算サービスおよびクラウドベースのストレージサービスを含む、条項25に記載の装置。条項29。別個のネットワークリソースが、単一のエンティティにより管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成する、条項25に記載の装置。条項30。別個のネットワークリソースのうちの1つが、第1のエンティティにより管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成し、別個のネットワークリソースのうちのもう1つが、第1のエンティティから独立している第2のエンティティにより管理されるクラウドコンピューティングプラットホームの少なくとも一部分を形成する、条項25に記載の装置。条項31。複数の異なるテンプレートを格納する、または複数の異なるテンプレートへアクセスするデータベースをさらに含み、複数の異なるテンプレートの各々は別個のネットワークリソースを含むスタックを作成するため事前に入力された命令を含む、条項25に記載の装置。条項32。複数の異なるテンプレートの少なくとも一部分が、独立したユーザーのコミュニティにより提供された、条項31に記載の装置。条項33。実行された場合に、別個のネットワークリソースの1セットを含むスタックを作成するために事前に入力された命令を含む複数の異なるテンプレートのうちの1つの選択を促進する、第1の領域;選択されたテンプレートを使用して作成されるスタックを指定する、第2の領域;およびスタックの作成を要求する第3の領域:を含むグラフィカルユーザーインターフェースGUIを1つまたは複数のプロセッサに描写させるコンピュータ実行可能命令を格納する1つまたは複数のコンピュータが読み込み可能な媒体。条項34。複数の異なるテンプレートの各々が、エクステンシブルマークアップランゲージXMLフォーマットまたはジャバスクリプトオブジェクトノーテーションJSONフォーマットでの命令を含む、条項33に記載の1つまたは複数のコンピュータが読み込み可能な媒体。条項35。複数の異なるテンプレートの少なくとも一部分がユーザーのコミュニティの異なるユーザーにより提供される、条項33に記載の1つまたは複数のコンピュータが読み込み可能な媒体。結論主題を、構造的特徴および/または方法論的行為に特定したことばで記述してきたが、添付した特許請求の範囲に定義した主題は、前述の特定の特徴または行為には必ずしも限定されないことが理解されるべきである。むしろこの特定の特徴や行為は、特許請求の範囲を実施する形態の例として開示されている。"