Systems and methods for providing ranked deployment options

CROSS-REFERENCE TO RELATED APPLICATIONS

0001This application claims priority to U.S. Provisional Application No. 61/801,199, filed Mar. 15, 2013, entitled “SYSTEM AND METHOD FOR CLOUD COMPUTING WITH METASCHEDULER”. This application is also a Continuation-in-Part of U.S. patent application Ser. No. 13/843,512, filed Mar. 15, 2013, entitled “SYSTEM AND METHOD FOR A CLOUD COMPUTING ABSTRACTION WITH MULTI-TIER DEPLOYMENT POLICY”, which is a Continuation-in-Part of U.S. patent application Ser. No. 13/354,275, filed Jan. 19, 2012, entitled “SYSTEM AND METHOD FOR A CLOUD COMPUTING ABSTRACTION LAYER WITH SECURITY ZONE FACILITIES”, which claims priority to U.S. Provisional Patent Application No. 61/434,396, filed Jan. 19, 2011, entitled, “SYSTEM AND METHOD FOR CLOUD COMPUTING”, and is also a Continuation-in-Part of U.S. patent application Ser. No. 13/009,774, filed Jan. 19, 2011, entitled, “SYSTEM AND METHOD FOR A CLOUD COMPUTING ABSTRACTION LAYER”, which claims priority to U.S. Provisional Application No. 61/296,405, filed on Jan. 19, 2010, entitled “ENTERPRISE CLOUD SYSTEM AND METHOD”, and is also a Continuation-in-Part of U.S. patent application Ser. No. 12/488,424, filed Jun. 19, 2009, issued as U.S. Pat. No. 8,514,868, issued Aug. 20, 2013, entitled “CLOUD COMPUTING GATEWAY, CLOUD COMPUTING HYPERVISOR, AND METHODS FOR IMPLEMENTING SAME”, which claims priority to U.S. Provisional Patent Application No. 61/074,027 filed Jun. 19, 2008, entitled “CLOUD COMPUTING GATEWAY AND CLOUD COMPUTING HYPERVISOR”, all of which are incorporated herein by reference in their entirety.

FIELD OF THE INVENTION

0002The present technology relates to the field of infrastructure environments. More particularly, the present technology relates to techniques for providing ranked deployment options.

BACKGROUND

0003Application developers can utilize infrastructure environments, such as cloud environments, to deploy applications (or services). In some cases, the applications can comprise complex, multiple-tier workloads. Moreover, application developers may desire to utilize various hybrid cloud environments that include multiple clouds, such as internal private clouds, external hosted clouds, infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and/or any combination thereof. For example, the application developers can desire to deploy the complex, multiple-tier workloads into the various hybrid cloud environments. However, under conventional approaches, differences in the applications, workloads, environments, and other factors can create challenges for deployment.

0004In one example, different applications and different workloads can demand different infrastructure resource requirements. Furthermore, different infrastructure environments and infrastructure resources typically offer different capabilities (e.g., processing capabilities, memory capabilities). As such, under conventional approaches, in order to efficiently utilize a particular infrastructure environment(s) or infrastructure resource(s), it can be necessary for the application developers to manually ensure that their applications and workloads are compatible (or operable) with the particular infrastructure environments and infrastructure resources. In some instances, conventional approaches can require the application developers to modify their applications and workloads in order for the applications and workloads to be suitable for deployment into and usage at the particular infrastructure environments and infrastructure resources. These and other concerns can create challenges for and reduce the overall experience associated with application design and deployment for infrastructure environments.

SUMMARY

0005Various embodiments of the present disclosure can include systems, methods, and non-transitory computer readable media configured to receive information about an application design plan. In some implementations, the application design plan can be associated with at least one deployment criterion. One or more available infrastructure resources (e.g., computing resources, network resources, storage resources, etc.) can be identified based on the information about the application design plan. A plurality of deployment options can be determined based on the one or more available infrastructure resources. The plurality of deployment options can be determined to be compliant with the at least one deployment criterion. Moreover, the plurality of deployment options can be ranked to produce an ordered set of deployment options. In some instances, some deployment criteria can be specified as hard constraints which must be satisfied, while other deployment criteria can be used to determine best fit but would not necessarily fail the deployment.

0006In one embodiment, ranking the plurality of deployment options can include evaluating one or more quantitative metrics (e.g., performance, utilization, scalability, cost, latency, etc.) associated with each deployment option in the plurality of deployment options. In some cases, quantitative metrics can include business requirements, constraints, etc.

0007In one embodiment, the one or more quantitative metrics associated with each deployment option can correspond to one or more computational resource attribute metrics.

0008In one embodiment, the one or more quantitative metrics associated with each deployment option can comprise at least one of a utilization metric, an available resource capacity metric, a requested resource capacity metric, a service level metric, a weight metric (e.g., a relative weight metric), a geographical metric, or a cost metric.

0009In one embodiment, a tree data structure can be generated to represent the ordered set of deployment options. Each level of nodes in the tree data structure can be sorted based on ranking the plurality of deployment options. Each leaf node in the tree data structure can represent a workload associated with the application design plan. Further, each deployment option in the plurality of deployment options can correspond to a respective component (and/or workflow) associated with the application design plan, and each deployment option corresponding to the respective component can be represented by a path from a respective leaf node to a root node in the tree data structure.

0010In one embodiment, the application design plan can comprise a logical composition of an application, and at least a portion of the at least one deployment criterion can be based on the logical composition of the application.

0011In one embodiment, the logical composition can include at least one of a container defined during application development, a resource affinity specified for the container, a workload, a computational resource attribute descriptive of the workload, a connection associated with the workload, or a package configured to facilitate application installation.

0012In one embodiment, a computing system configured to rank the plurality of deployment options can be associated with an abstraction layer represented between at least one application and a plurality of infrastructure resources. The plurality of infrastructure resources can include the one or more available infrastructure resources. The abstraction layer can be configured to facilitate one or more operations between the at least one application and the plurality of infrastructure resources.

0013In one embodiment, a data package associated with the application design plan can be received. Information about at least one data residency criterion can also be received. A set of repositories that are compliant with the at least one data residency criterion can be determined. The set of repositories can be associated with the one or more available infrastructure resources. The data package can be provided to at least a subset of the set of repositories. The at least one deployment criterion can be dependent, at least in part, upon an availability of the data package at a repository associated with an available infrastructure resource.

0014In one embodiment, user access to the ordered set of deployment options can be provided. In some cases, at least one of, a highest ordered deployment option in the ordered set or a user-selected deployment option in the plurality of deployment options, can be deployed.

0015Many other features and embodiments of the disclosed technology will be apparent from the accompanying drawings and from the following detailed description.

BRIEF DESCRIPTION OF THE DRAWINGS

<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example graphical representation of an application design plan for which ranked deployment options can be provided, according to an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example tree data structure configured to represent ranked deployment options, according to an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 3</figref> illustrates an example system configured to store packages operable with ranked deployment options, according to an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 4A</figref> illustrates an example method for providing ranked deployment options, according to an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 4B</figref> illustrates an example method for providing ranked deployment options based on data residency, according to an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 5</figref> shows a diagram illustrating an example system in accordance with an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 6</figref> shows a diagram illustrating an example management module in accordance with an embodiment of the present disclosure.

<figref idref="DRAWINGS">FIG. 7</figref> illustrates an example of a computing device or system that can be used to implement one or more of the embodiments described herein, according to an embodiment of the present disclosure.

0024The figures depict various embodiments of the disclosed technology for purposes of illustration only, wherein the figures use like reference numerals to identify like elements. One skilled in the art will readily recognize from the following discussion that alternative embodiments of the structures and methods illustrated in the figures can be employed without departing from the principles of the disclosed technology described herein.

DETAILED DESCRIPTION PROVIDING RANKED DEPLOYMENT OPTIONS

0025Organizations and other entities are increasingly leveraging hybrid cloud environments that span multiple infrastructure environments (e.g., computing environments, network environments, storage environments, etc.). These infrastructure environments can include, for example, internal private clouds, external hosted clouds, infrastructure-as-a-service (IaaS), platform-as-a-service (PaaS), and/or other systems, etc. These infrastructure environments can be different and can be provided by various vendors. However, the ability to deploy complex multi-tier workloads into these heterogeneous multi-vendor environments and/or systems can be costly, inefficient, inconvenient, and/or difficult.

0026Various embodiments of the present disclosure can provide a scheduling module, engine, or component (i.e., “meta-scheduler”) configured to place workloads across multiple environments to achieve optimal price, performance, and service levels while providing governance and control over security and compliance. The scheduling module can be implemented as software, hardware, or any combination thereof. In some embodiments, the scheduling module can be implemented as an extension to a cloud (e.g., hybrid cloud environment) management abstraction layer (or module, component, system, platform, etc.). The scheduling module can, for example, be implemented as an extension to a policy and governance model of the cloud management abstraction layer. Furthermore, the cloud management abstraction layer can, for example, correspond to a hybrid cloud management platform or system.

0027In some implementations, the scheduling module (i.e., meta-scheduler) can correspond to a policy-based scheduling module configured to take into consideration various factors, including deployment policies, when determining and providing deployment options. The scheduling module can also enable de-coupling of an application (or service) design from the underlying infrastructure environment(s) at which the application is to be deployed. Various embodiments can enable an application design to be produced without requiring the application design to be necessarily tied to a particular environment(s). This can allow for optimized (e.g., best-fit) deployment execution.

0028Deployment of applications can be optimized at deployment time with respect to various dimensions, such as application constraints, resource constraints, data residency constraints, economic measures, and/or any combination thereof, etc. In some cases, the deployment of applications must comply with the various dimensions, which can be referred to as deployment criteria (e.g., at least one deployment criterion). Further, the applications can be evaluated over time (e.g., continually, continuously, periodically, etc.) for appropriate fit and can be migrated when better or more appropriate execution environments are discovered. These and other advantages can be made possible by the policy-based scheduling module (i.e., meta-scheduler), which is configured to take into account information about applications as well as information about various constraints, criteria, and/or limitations (e.g., business constraints, data residency policies and/or criteria, resource limitations, etc.).

0029<figref idref="DRAWINGS">FIG. 1</figref> illustrates an example graphical representation <b>100</b> of an application design plan for which ranked deployment options can be provided, according to an embodiment of the present disclosure. In the example of <figref idref="DRAWINGS">FIG. 1</figref>, the graphical representation <b>100</b> can correspond to an application design plan, or blueprint, for a multi-tier software bundle (e.g., Linux, Apache, MySQL, Perl/PHP/Python (LAMP), etc.). In some embodiments, a blueprint, such as Blueprint: LAMP <b>102</b>, can correspond to a design-time plan that describes the logical composition of a potentially complex multi-tier application (or service). The blueprint can, for example, be created by one or more application (or service) developers. The blueprint can provide the ability for application developers to specify abstract resource requirements without coupling the application design to a specific cloud provider and without significant knowledge of the target environment at which the application is to be deployed. As shown in <figref idref="DRAWINGS">FIG. 1</figref>, the blueprint (e.g., Blueprint: LAMP <b>102</b>) can, for example, comprise design containers such as Web Tier <b>110</b>, Application Tier <b>120</b>, and Database Tier <b>130</b>.

0030In some implementations, a container (e.g., design container, design-time container, etc.) can comprise a collection of workloads and/or other containers. Containers can correspond to logical constructs used in forming a blueprint or application design plan. In some cases, a container can be associated with a defined startup ordering. For example, in a scenario with multiple workloads that depend on one another, the startup ordering can describe how a task associated with one workload is to be performed before a task associated with another workload.

0031Moreover, a container can be associated with a resource affinity. In some embodiments, affinities can specify that all workloads within a given container must be deployed on the same resource (e.g., same type and/or instance of resource), or conversely, cannot be deployed on the same resource. Examples of a resource can include, but are not limited to, a host, a cluster, a cloud, a network, etc. As such, network affinities can specify that workloads within network-affinity containers must be deployed on a particular network resource(s), whereas host affinities can specify that workloads within host-affinity containers must be deployed at a particular host(s), and so forth.

0032In some embodiments, a workload can be associated with a specification of the components to be installed on a virtual machine without necessarily coupling to a specific environment or a specific set of resources. The workload can also be associated with a specification of minimum resource requirements needed for the virtual machine without coupling to specific environments or resources. In some cases, data packaging, configuration management policies, service level agreement (SLA), and/or scaling policies, etc. can be leveraged to define these resource requirements in a stateless fashion. Furthermore, with regard to the resource requirements of workloads, there can be computational resource attributes in the form of tuples configured to describe the computational resource requirements of each workload. In some cases, a tuple can be represented as a multi-dimensional descriptor of attribute name and/or value pairs (e.g., required CPU, memory, network latency, bandwidth, etc.).

0033With reference now to the Network Affinity: Web Tier container <b>110</b>, as shown in the example of <figref idref="DRAWINGS">FIG. 1</figref>, the Network Affinity: Web Tier container <b>110</b> can comprise a Workload: Load Balancer <b>112</b>. The Workload: Load Balancer <b>112</b> can also include a Nginx component <b>114</b>. In some implementations, the Nginx component <b>114</b> can correspond to a reverse proxy server for various protocols, such as HTTP, HTTPS, SMTP, IMAP, and POP3. In some embodiments, the Nginx component <b>114</b> can perform the functions associated with a load balancer, a cache, and/or a web server, etc. A load balancer can be an example of a network service. In some cases, a network service can be associated with a logical representation of application requirements in a runtime environment. Other examples of network services can include firewalls, databases as services, and/or other application specific services.

0034Moreover, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, the Workload: Load Balancer <b>112</b> can be connected to the Workload: App <b>122</b>, which can be included with the Network Affinity: Application Tier <b>120</b>. In some instances, connections can represent network connection requirements between workloads (e.g., firewall rules, etc.). In some cases, a connection can specify a dependency between workloads such that the downstream end of the connection is blocked until all scripts have run and output variables are available. Scripts (and their attached binaries) can be associated with packages. A package can correspond to, for example, a bundle of scripts and attached binaries that automate the installation of an application (or service).

0035Continuing with the example of <figref idref="DRAWINGS">FIG. 1</figref>, the Workload: App <b>122</b> can utilize Apache <b>124</b> and/or PHP <b>126</b> to carry out various tasks. The Workload: App <b>122</b> can also be connected to the Workload: Database (Active) <b>134</b>, which can be included with the Host Affinity: Failover Group <b>132</b>. In some embodiments, the Host Affinity: Failover Group <b>132</b> can be associated with the task of switching to a redundant, backup, or standby component (e.g., application, server, system, hardware, network, etc.) upon the failure or abnormal termination of an previously active component. In this example, the Network Affinity: Database Tier <b>130</b> can comprise the Host Affinity: Failover Group <b>132</b>. Furthermore, as shown in <figref idref="DRAWINGS">FIG. 1</figref>, the Host Affinity: Failover Group <b>132</b> can also comprise the Workload Database (Backup) <b>136</b>. Accordingly, the graphical representation <b>100</b> illustrates the logical composition for the example Blueprint: LAMP <b>102</b> (including various components of the Blueprint: LAMP <b>102</b> such has containers, workloads, connections, etc.), which can be designed and created by one or more application developers.

0036The act of deploying a blueprint can map a logical application design to a set of available resources within a target environment. The blueprint can be analyzed or otherwise processed by the scheduling module (i.e., meta-scheduler) in order to determine and provide deployment options.

0037In some embodiments, based on information associated with (e.g., related to, descriptive of, included with, etc.) the blueprint and/or logical design, one or more deployment policies can be acquired (e.g., obtained, received, derived, etc.). The one or more deployment policies can be associated with design-time constraints which constrain the initial set of available cloud resources. Examples of constraints can include (but are not limited to) container resource affinities, workload resource requirements (e.g., minimum CPU and/or memory), application components, availability of required data/artifacts (e.g., packages), operating systems, required Service Level Agreements (SLA), etc. The deployment policies can also be associated with application lifecycle considerations, such as considerations about which Systems Development Life-Cycle (SDLC) stage (e.g., Development, Testing, Staging, Production, etc.) is being represented by a particular and/or present revision of the application. Moreover, the deployment policies can allow for an ability to globally, and/or on a hierarchical basis, define specific sets of cloud resources that can be included or excluded from evaluation for application blueprints deployed within a particular container hierarchy. Furthermore, the deployment policies can allow for the ability to specifically include or exclude sets of resources based on meta-data properties specified via the logical design. In one example, a “geographic” constraint can be enforced by requiring workloads to be tagged with a meta-data property (e.g., geographical, locational, etc.), such that providers or resources that do not match the “geographic” constraint can be filtered out.

0038Based on the evaluation of deployment policies, the policy-based scheduling module (i.e., meta-scheduler) can generate a set of ordered deployment options (e.g., a ranked deployment plan, a prioritized deployment plan, etc.). A more detailed discussion describing the generation of the ordered (e.g., ranked) set of deployment options is provided below with reference to <figref idref="DRAWINGS">FIG. 2</figref>.

0039<figref idref="DRAWINGS">FIG. 2</figref> illustrates an example tree data structure <b>200</b> configured to represent ranked deployment options, according to an embodiment of the present disclosure. In the example of <figref idref="DRAWINGS">FIG. 2</figref>, the tree <b>200</b> can represent a possible deployment plan including a plurality of possible deployment options determined by the policy-based scheduling module for the Blueprint: LAMP <b>102</b> in <figref idref="DRAWINGS">FIG. 1</figref>.

0040In some embodiments, the policy-based scheduling module can evaluate one or more deployment policies in order to determine (e.g., identify, select, etc.) the plurality of deployment options for each container and/or workload in the blueprint. The policy-based scheduling module can rank or sort the plurality of deployment options to generate a set of ordered deployment options (i.e., an ordered set of deployment options). To rank or sort the plurality of deployment options, the module can calculate a score or ranking metric for each deployment option, which will be discussed in more detail below.

0041As discussed above, in some implementations, in order to generate the ordered set of deployment options, the policy-based scheduling module can create a decision tree (e.g., tree <b>200</b>) to represent the plurality of deployment options determined based on analyzing the blueprint (which, in some cases, can comprise at least one container hierarchy). In one example, the decision tree can be created such that a node in the tree, representative of a container, corresponds to a decision point based on a set of available resources (or resource options) for the container's affinity (e.g. cloud, location, network, etc.). The children of the node can correspond to the available resources or resource options (e.g., possible deployment options that comply with constraints and policies). As shown in the example of <figref idref="DRAWINGS">FIG. 2</figref>, workloads can correspond to leaf nodes in the tree <b>200</b>. At the leaf-node level, cloud resources (e.g. provider, location, network, hardware model, etc.) can be specified, and cost and resource consumption values can be calculated for that specific set of resources or branch of the tree <b>200</b>.

0042In some cases, the policy-based scheduling module can cause cost and resource consumption metrics to be propagated from leaf nodes back up the tree <b>200</b>. The cost and resource consumption can be calculated for each deployment option by aggregating the cost and resource consumption metrics from each leaf node (e.g., representing a respective workload) up through the tree <b>200</b> to the root node. In some cases, each deployment option can correspond to a respective component and/or workflow associated with the blueprint, and each deployment option can be represented by a path from a respective leaf node to a root node.

0043As discussed previously, in order to rank or sort the plurality of deployment options, the scheduling module can calculate a score or ranking metric for each deployment option. In some embodiments, the capacity of each deployment option can be expressed as a multi-dimensional descriptor of available resource capacities, wherein for each resource type (r) (e.g., CPU, memory, cost, etc.), both the current utilization (u) and available capacity (c) are indicated in accordance with the expression: [r₁=u₁/c₁, r₂=u₂/c₂, . . . ]. In some instances, such as for metrics where capacity is not necessarily relevant (e.g., latency), a relative ranking value can be calculated by determining the ratio of the metric value to the maximum value of that metric encountered for any resource provider. For example, capacity can be set to the maximum value of the metric across all providers. Moreover, in some embodiments, the current utilization (u) and available capacity (c) can be scalar or quantitative values. In some implementations, the expression can be defined based on computational resource attribute metrics.

0044In addition, an expression can be defined such that given a multidimensional tuple, which describes the resource requirements [r₁=v₁, r₂=v₂, . . . ] of a given workload or set of workloads, can be used to compute the ranking or score for each deployment option. The policy-based scheduling module can compute the ranking (i.e., ranking metric, rank, score, etc.) by calculating, for example, the utilization (or rank) of each resource independently and then combining these into a single scalar ranking or score. In some instances, a set of weighting factors [r₁=w₁, r₂=w₂, . . . ] can also be applied to each of the respective utilizations.

0045In one example, the rank or score for a deployment option can be calculated based on the following expression: Rank_option=[(u₁+v₁)/c₁*w₁]+[(u₂+v₂)/c₂*w₂]+ . . . +[(u_n+v_n)/c_n*w_n]. In this example expression, the variable u can correspond to the utilization of a resource within the deployment option (e.g., 16 cores) and the variable c can correspond to the total capacity of the resource within the deployment option (e.g., 32 cores). The variable v can correspond to a requested resource capacity (e.g., 4 cores) and the variable w can correspond to a relative weight assigned to resource type. Information about the utilization and total capacity of a resource can be acquired from the resource, for example. Information about the requested resource capacity and the relative weight can be acquired from the application design plan and/or from the application developer(s). In some instances, the relative weight can have a default or preset value. In this example, the best (e.g., most preferred) rank or score can correspond to the lowest rank or score.

0046The ranking metric calculated for each deployment option can then be used by the scheduling module to sort each level of the tree <b>200</b>. The nodes in the tree <b>200</b> can be sorted from best fit to worst fit as defined by the ranking metrics calculated using the above expression and incorporating the relative weights assigned to the resource types. It is also contemplated that each of the resource weights can be adjusted by the end-user to evaluate tradeoffs in optimization for cost versus capacity or other metrics. The sorted (e.g., ranked, ordered) set of deployment options can then be presented to the end user. In the example of <figref idref="DRAWINGS">FIG. 2</figref>, the solid line paths in the tree <b>200</b> can represent the best-fit options based on the rank calculated for each of the nodes.

0047In <figref idref="DRAWINGS">FIG. 2</figref>, the tree <b>200</b> can comprise a root node that indicates that the tree <b>200</b> is representative of Blueprint LAMP <b>102</b> (in <figref idref="DRAWINGS">FIG. 1</figref>). In this example, the root node can have three child nodes, which can be associated with a design container level <b>202</b> of the tree <b>200</b>. The three child nodes can, for example, correspond to Web Tier <b>110</b>, Application Tier <b>120</b>, and Database Tier <b>130</b> (in <figref idref="DRAWINGS">FIG. 1</figref>). Each of the three nodes can have one or more child nodes, grandchild nodes, and so forth.

0048For illustrative purposes, the following example is described with respect to the Web Tier node in the design container level <b>202</b> of the tree <b>200</b> in <figref idref="DRAWINGS">FIG. 2</figref>. Although not discussed in this example, the Application Tier node and the Database Tier node (and their respective branches) can represent similar concepts. In one example, the Web Tier node can have two child nodes (in the upper deployment option level <b>204</b> of the tree <b>200</b>), and each of these two child nodes can have two child nodes of their own (in the lower deployment option level <b>206</b>). Each of the nodes in the lower deployment option level <b>206</b> can have a respective leaf node (in the design workload level <b>208</b>), which can represent a respective workload (e.g., Load Balancer). The Load Balancer workload can be deployed on each of the deployment options represented by the nodes in the lower deployment option <b>206</b>. However, the tree <b>200</b> can be sorted such that the child nodes of each parent node are ordered from highest rank (e.g., least costly) to lowest rank (e.g., most costly), with the exception of leaf nodes and the root node's children. In this example, the best ranked (e.g., lowest cost, most preferred, etc.) nodes (not including the leaf nodes and the root node's children) are visually represented as being left-most. Accordingly, a solid line path in the tree <b>200</b> representing an optimal option is shown to be generally on the left side of a respective tree portion. For example, with respect to the Web Tier container, the Load Balancer workload (represented by a leaf node) can be more optimally deployed on the Azure East option than on the Azure West option, and more optimally deployed using the Azure Public Network option than using the EC2 Public Network option.

0049Moreover, in some embodiments, the resulting deployment plan comprising the ordered (e.g., ranked) set of deployment options, as determined by the scheduling module, can be deployed without user interaction. For example, the policy-based scheduling module can deploy the resulting plan using, at least in part, the optimized (e.g., best fit, highest ranked, lowest cost, etc.) paths through the tree <b>200</b> at each decision point. This can result in an optimal deployment based on the current design and policy constraints that take into consideration the current capacity, utilization, and performance of the underlying infrastructure. Additionally or alternately, in some embodiments, users can choose to review the set of available options and modify or adjust the deployment plan to fit their specific requirements by selecting an alternate branch or path. It should be noted that the alternate branch or path still adheres to the design and policy constraints.

0050In addition to providing ranked deployment options that result in optimized application deployment in compliance with deployment polices, various embodiments of the present disclosure can also provide packaging constructs useful in distributing, installing, and configuring applications (or services) and their respective data within a cloud and platform agnostic framework. <figref idref="DRAWINGS">FIG. 3</figref> illustrates an example system <b>300</b> configured to store packages operable with ranked deployment options, according to an embodiment of the present disclosure.

0051In some embodiments, a package can be configured to be compatible or operable with a cloud management abstraction layer <b>302</b>. The package can, for example, comprise a set of scripts that support the management of a lifecycle of an application (e.g., install, start, stop, reconfigure, etc.) on a target platform. Each of the scripts can include a set of attachments to binaries and/or data required by the application. In some cases, these artifacts can be uploaded directly into the cloud management abstraction layer <b>302</b> and/or included via reference to an artifact source of record (e.g. external artifact repository <b>304</b>, software configuration management (SCM) system <b>306</b>, internal repository <b>308</b>, etc.). Various embodiments can enable the artifacts (e.g., packages, data, etc.) to be pre-staged or uploaded prior to use.

0052Pre-staging or (pre-)uploading the artifacts into repositories located in each of the cloud environments (e.g., cloud <b>310</b>, cloud <b>312</b>, etc.) can limit or reduce contention and utilization of expensive network links, can expedite access to the required artifacts when workloads are deployed into heterogeneous environments, and/or can cause the required artifacts to be securely available outside of firewalls in the case of public cloud environments (e.g., cloud <b>312</b>). In some embodiments, the pre-staging of data and/or artifacts into cloud environments prior to their use can be controlled based on a concept of a data residency policy. The data residency policy can work in conjunction with one or more deployment policies to control the pre-staging.

0053In some implementations, data residency policies can be evaluated when artifacts are defined and/or introduced into the cloud management system. The data residency policies can be evaluated to select (or determine) the environments where the associated data is “allowed” to reside. The selected environment should provide the ability to globally, and/or on a hierarchical basis, define specific sets of clouds, locations within clouds, and/or specific repositories that should be included and/or excluded as valid destinations for the pre-staging of application artifacts. Furthermore, in some instances, the selected environment should provide the ability to specifically include and/or exclude destinations based on meta-data properties specified on the packaging assets. In one example, a “geographic” constraint can be enforced by requiring packages and/or scripts to be tagged with a meta-data property. Then the data residency policy can filter out destinations that do not match this geographic constraint.

0054Based on the result of data residency policy evaluation, the artifacts can be replicated into the allowed environments. Deployment policies can then take into account the availability of the required artifacts when evaluating deployment plans and can filter out environments that do not satisfy the application requirements.

0055<figref idref="DRAWINGS">FIG. 4A</figref> illustrates an example method <b>400</b> for providing ranked deployment options, according to an embodiment of the present disclosure. It should be appreciated that there can be additional, fewer, or alternative steps performed in similar or alternative orders, or in parallel, within the scope of the various embodiments unless otherwise stated.

0056At step <b>402</b>, the example method <b>400</b> can receive information about an application (or service) design plan (or blueprint). The information about the application design plan can be received by the meta-scheduler (i.e., policy-based scheduling module). In some cases, the application design plan can be associated with at least one deployment criterion. The at least one deployment criterion can comprise deployment policies (as well as other constraints or limitations) that are to be satisfied for application deployment.

0057At step <b>404</b>, the example method <b>400</b> can identify one or more available network/infrastructure resources based on the information about the application design plan. In some embodiments, the one or more available network/infrastructure resources can be identified by the meta-scheduler.

0058A plurality of deployment options can then be determined based on the one or more available network/infrastructure resources, at step <b>406</b>. In some instances, the plurality of deployment options can be determined by the meta-scheduler. Moreover, the plurality of deployment options can be determined to be compliant with the at least one deployment criterion.

0059Step <b>408</b> can include ranking the plurality of deployment options to produce an ordered set of deployment options. In some cases, ranking the plurality of deployment options can be performed by the meta-scheduler. For example, the meta-scheduler can calculate a respective score, rank, or ranking metric, etc., for each of the plurality of deployment options. In some embodiments, the meta-scheduler can produce the ordered (e.g., ranked, sorted, prioritized, etc.) set of deployment options based on the ranking of the plurality of deployment options. The set of deployment options can be ordered, for example, based on the respective score, rank, or ranking metric calculated for each deployment option.

0060In some embodiments, the ordered set of deployment options can be included in a sorted (e.g., ranked, prioritized, ordered, etc.) deployment plan. The sorted deployment plan, including the ordered set of deployment options, can be represented in a tree data structure. The ordered set of deployment options (and/or the sorted deployment plan and/or the tree data structure) can be presented to an end user(s). The end user(s) can choose to proceed with application deployment based on the ordered set of deployment options.

0061<figref idref="DRAWINGS">FIG. 4B</figref> illustrates an example method <b>450</b> for providing ranked deployment options based on data residency, according to an embodiment of the present disclosure. Again, it should be appreciated that there can be additional, fewer, or alternative steps performed in similar or alternative orders, or in parallel, within the scope of the various embodiments unless otherwise stated.

0062The example method <b>450</b> can receive a data package associated with an application design plan, at step <b>452</b>. For example, the data package can include a bundle of scripts and associated binaries. Step <b>454</b> can include receiving information about at least one data residency criterion. The at least one data residency criterion can, for example, be associated with at least one data residency policy and/or at least one data residency constraint. At step <b>456</b>, the method <b>450</b> can determine a set of repositories that are compliant with the at least one data residency criterion. In some instances, the set of repositories can be associated with the one or more available network/infrastructure resources.

0063Step <b>458</b> can include providing the data package to at least a subset of the set of repositories. In some cases, the at least one deployment criterion can be dependent, at least in part, upon an availability of the data package at a repository associated with an available network/infrastructure resource.

0064Various other embodiments and/or applications are also possible. In one example scenario, one or more embodiments of the present disclosure can allow for the possibility of the creation of a marketplace for application workloads. Application owners can express and communicate application workload characteristics and requirements through a set of demand signals. The set of demand signals can be utilized by qualified application workload hosting providers (e.g., including internal IT) to match available application workload demand with available resource capacity within one or more suitable hosting environments. This can enable a plurality of qualified sell-side hosting providers to competitively bid for available flow of application workloads.

0065This example scenario can support the digital conveyance of advance signaling, forecasting, sourcing, capacity management, SKU matching, reservation confirmation, delivery validation, support operations, SLA management, and lifecycle event monitoring processes. The example scenario can also support the digital conveyance of KPI analytics, compliance validation reporting, inter-party dispute resolution, and exception handling process communications between any combination of buy-side enterprises, cloud service brokers, cloud service marketplaces, exchanges and other market-making functions, and a plurality of qualified sell-side hosting providers.

0066Furthermore, this example scenario can also extend to the access of information flows for engaging in the competitive bidding for flow of available application workloads as well as the supporting decision-making processes surrounding the application workload sourcing, fulfillment, and delivery processes of qualified hosting providers.

0067It is further contemplated that there can be many other uses, applications, and/or variations associated with the various embodiments of the present disclosure.

Abstraction Layer—Example Implementation

0068<figref idref="DRAWINGS">FIG. 5</figref> shows a diagram illustrating an example system <b>510</b> in accordance with an embodiment of the present disclosure. <figref idref="DRAWINGS">FIG. 5</figref> illustrates a cloud-computing environment <b>535</b> comprising one or more cloud-computing resources, a client network <b>531</b> comprising client computing devices <b>514</b> (e.g., desktops, laptops, smart mobile devices), and a cloud-computing platform <b>520</b> (i.e., cloud management abstraction layer, hybrid cloud management platform) in accordance with an embodiment of the present disclosure. In <figref idref="DRAWINGS">FIG. 5</figref>, cloud-computing platform <b>520</b> provides a system through which computing devices <b>514</b> residing on client network <b>531</b> (e.g., enterprise network) can access one or more cloud-computing services. A cloud-computing service can comprise a cloud-computing resource residing within the cloud-computing environment <b>535</b> and managed by the cloud-computing platform <b>520</b> to provide the cloud computing service. Depending on the embodiment, cloud-computing environment <b>535</b> may comprise one or more cloud providing networks that include cloud-computing resources (e.g., cloud services provided by public or private clouds, which may be external or internal to the enterprise that uses them) that can be utilized by users. Additionally, depending on the embodiment, platform <b>520</b> may reside on the client network <b>531</b> or separate from the client network <b>531</b>.

0069Cloud-computing environment <b>535</b> may comprise an internal cloud, an external cloud, a private cloud, or a public cloud (e.g., commercial cloud). In the example of <figref idref="DRAWINGS">FIG. 5</figref>, cloud-computing environment <b>535</b> comprises internal private cloud resource <b>538</b>, external private cloud resource <b>541</b>, and secure public cloud resource <b>544</b>. A private cloud may be implemented using a variety of cloud systems including, for example, Eucalyptus Systems, VMWare vSphere®, or Microsoft® HyperV. Providers of public clouds may include, for example, Amazon EC2®, Amazon Web Services®, Terremark®, Savvis®, or GoGrid®. Cloud-computing resources provided by these clouds may include, for example, storage resources (e.g., Storage Area Network (SAN), Network File System (NFS), and Amazon S3™), network resources (e.g., firewall, load-balancer, and proxy server), internal private resources, external private resources, secure public resources, infrastructure-as-a-services (IaaSs), platform-as-a-services (PaaSs), or software-as-a-services (SaaSs).

0070By using cloud-computing platform <b>520</b> to plan, build, manage, or use cloud-computing resources within a cloud-computing environment, users of platform <b>520</b> can be provided with standardized access to a variety of cloud-computing resources from disparate cloud-computing systems and providers without concerning themselves with the proprietary details of accessing or interfacing with such cloud-computing systems and providers. The platform <b>520</b> can be configured to take the workloads that are developed with the platform <b>520</b> and automatically provide the interfaces and access steps necessary to operate the workload on any particular platform or infrastructure element within a federation of cloud computing resources, such that the user is able to interact with the platform <b>520</b> to develop such workloads at a level of abstraction that allows the user to configure the logic of the workload (including conditional logic that allows interrelation of different workloads) and to embody the technical, operational, and business requirements of the workload in policies that are associated with the workload, without the user being required to access or understand the details of (or in some cases even know about the existence of) such particular platform or infrastructure elements. Additionally, users of platform <b>520</b> can access cloud-computing services through platform <b>520</b> on-demand and on a self-service basis through the standardized access. Users of cloud computing services offered by platform <b>520</b> may include end users, developers, partners, or administrators that reside on the client network <b>531</b>.

0071Platform <b>520</b> may comprise planner module <b>523</b>, manager module <b>526</b>, builder module <b>529</b>, and consumption module <b>532</b>. Planner module <b>523</b> can be configured to plan cloud-computing service provided by platform <b>520</b> by inventorying, profiling, characterizing and prioritizing computer workloads, such as programs, applets, calculations, applications, servers, or services. For example, with respect to software/application development, planner module <b>523</b> may model current applications and associated software-development life cycle (SDLC) phases to determine what infrastructure environments would be required or preferred. This may include defining security, privacy, management or other profiles for each SDLC phase of each application. The profiles, in turn, will identify existing infrastructure and systems that support the SDLC phases, and manage relationships between the infrastructure, systems and the applications. Profiles may also contain characteristics regarding the SDLC phases or attributes relevant to development, deployment or performance of infrastructure, systems, or workloads, such as latency, geography, responsiveness, bandwidth, storage capacity, processing speed, processing type, platforms involved (including operating system, file types, communication protocols, and the like), data involved, protocols used, and specific institutional requirements. In terms of prioritizing the cloud-computing services needed for the SDLC phases, planner <b>523</b> may first identify which SDLC computing environments and systems would be suitable for cloud computing or migration to cloud computing, and then prioritize the enablement and operability of newly developed or migrated computer workloads according to the SDLC phases. Subsequently, the characterizations determined by planner module <b>523</b> can be used by builder module <b>529</b> to build a cloud-computing service or to deploy a computer workload to a cloud-computing resource. In the planner module <b>523</b> or in other components of the platform <b>520</b> associated with the planner module <b>23</b> the user may have access to, or may create or modify, policy information relevant to the computer workloads with which the user can interact in the planner module <b>523</b>. The policy information may be stored in or associated with a meta model, which may enable the identification, characterization, and storage of a wide range of information, including policy information, that can be associated with a given workload. The metamodel data, including policy information, can be associated with the workload such that throughout the various components of the platform <b>520</b>, from planning through deployment to a cloud, the workflow can be handled in a manner that is consistent with the metamodel data, and in particular consistent with the policies that are applicable to that workload. In the planner module <b>523</b> the planner/user may thus plan the use of workloads in a manner that is consistent with technical, operational, and business requirements that are appropriate with such workload, as seen by association of the same with the workload, and the planner/user may modify or populate the policies associated with the workload, such that the metamodel data for that workload embodies and is consistent with the plans of the planner/user. Once associated with the workload, such policies and other metamodel data are stored by the platform <b>520</b> and may be used throughout the development and deployment cycle.

0072Builder module <b>529</b> can be configured to assemble, validate, and publish a cloud-computing service or computer workload for consumption (i.e., use) by a user. Builder module <b>529</b> may be configured to receive characterization information from planner module <b>523</b> and build a cloud-computing service or computer workload based on the information. For example, builder module <b>529</b> may be configured to assemble a cloud computing service based on the prioritized list of computer workloads provided by planner module <b>523</b>. Builder module <b>529</b> may be configured to create and edit scripts for loading computer workloads during installation, startup, runtime, and shutdown of cloud-computing services assembled by builder <b>529</b>. The scripts for the cloud-computing services may be verified and validated before the cloud-computing services are published for consumption (i.e., use). The script may have access to metamodel and policy information which may alter how the script uses the metamodel and policy information to make a decision. Additionally, builder module <b>529</b> may be configured to associate the computer workload with the appropriate cloud-computing service or resource (e.g., associate an application with an appropriate underlying virtual machine image or associate a computer workload with a specific network). As with the planner module <b>523</b>, in the builder module <b>529</b> the user/builder may have access to, or may create or modify, policy information relevant to the computer workloads with which the user can interact in the builder module <b>529</b>, such as the policy information stored in or associated with the above-referenced meta model, which may enable the identification, characterization, and storage of a wide range of information, including policy information, that can be associated with a given workload. In the builder module <b>529</b> the builder/user may thus build of workloads in a manner that is consistent with technical, operational, and business requirements that are appropriate with such workload, as seen by association of the same with the workload, and the builder/user may modify or populate the policies associated with the workload, such that the metamodel data for that workload embodies and is consistent with the plans of the planner/user. In embodiments, the builder module <b>529</b> may present options to the builder pre-filtered, such as in pre-populated scripts, filtered drop-down menus, that are dictated by or consistent with the policies and other metamodel data associated with a workload, omitting, blocking or hiding options that are inconsistent with such policies. For example, a workload that stores customer data could omit the option to store a social security number if a data privacy regulation prohibits storing such data in the business process to which the workload relates. Such automatic pre-filtering, pre-configuration, and blocking ensure consistency with the policies associated with the workload at the planning stage (or other stages) while also improving efficiency by removing development paths that might be pursued despite being prohibited. In embodiments, the metamodel provides a flexible structure to organize metadata and apply the same policies using a combination of system and user supplied metadata that may indicate use of the same policy, however may define the same policy in different ways. For example, in some embodiments, the system may consider a Tier 5 datacenter to be the most fault tolerant type of data center and a user may consider a Tier 1 data center to be the most tolerant. The metamodel allows a policy that requires provisioning in the most fault tolerant data center to be assigned Tier 5 or Tier 1 metadata, depending on the definition of the most fault tolerant data center in that specific operating environment.

0073Eventually, builder module <b>529</b> can publish a cloud-computing service for consumption by users. In some embodiments, the builder module <b>529</b> can publish the cloud-computing service to a consumption module <b>532</b> (e.g., store or storefront such as an application store, a service store, or a software stack store) where users can preview, select, and subscribe to a cloud-computing service for use. Further, in some embodiments, the builder module <b>529</b> can enter the cloud-computing service in repository <b>530</b> when it is ready and available for consumption by users. Embodiments may also be configured for the builder module <b>529</b> such that the development community can approve or disapprove of the cloud-computing service before publication.

0074Consumption module <b>532</b> is configured to allow a user to subscribe to, collaborate on, and assess a cloud-computing service published for consumption. For example, a user can preview cloud-computing services available for deployment to the virtual private cloud and consumption. Then, when a user wants to subscribe and invoke a cloud-computing service for usage, the user can invoke the cloud-computing service on a self-service, on-demand basis through the consumption module <b>532</b>. Consumption module <b>532</b> may list published available cloud-computing service at or near real-time, and allow a user to request updates and information on a listed cloud-computing service. In some embodiments, the consumption module <b>532</b> may allow users to collaborate on where, what, and how many cloud-computing services are deployed for consumption. In further embodiments, consumption module <b>532</b> may allow a user to comment on and rate cloud-computing services, or assess the cost associated with deploying and using a cloud-computing service. As noted above, as with the planning module <b>523</b> and the builder module <b>529</b>, the consumption module <b>532</b> has access to policy information and other metamodel data that is associated with each workload, such that the workload may be consumed only in a manner that is consistent with such policy information. Thus consumption policies related to permitted time, permitted sets of users, security, pricing, resource consumption rules, and a wide variety of other policies may be maintained by the consumption module based on the policies associated with the workload in the platform <b>520</b>.

0075Manager module <b>526</b> can be configured to provision one or more cloud-computing resources for a cloud-computing service or computer workload, manage one or more cloud-computing resources for the cloud-computing service or computer workload, and monitor one or more cloud-computing resources for the cloud-computing service or computer workload. For example, manager module <b>526</b> may provision one or more cloud-computing resources (e.g., provision one or more virtual machine instances) for a published cloud-computing service that is invoked from the consumption module <b>532</b>. Upon invoking the cloud-computing service, the manager module <b>526</b> may deploy and start the one or more cloud-computing resources to the virtual private cloud for the cloud-computing service.

0076With respect to control, manager module <b>526</b> may control the start, stop, or run-time of one or more cloud-computing resources (e.g., control start, stop, or run-time of virtual machine instance) for a cloud-computing service. Manager module <b>526</b> may further schedule the start and stop time windows for the one or more cloud-computing resources, or govern a service level, such as per a service level agreement (SLA), or a threshold associated with the one or more cloud-computing resources. Through its control, manager module <b>526</b> can govern the cloud-computing resource according to conditions, constraints, security policies, or non-security policies. Manager module <b>526</b> may also monitor the one or more cloud-computing resources, detect security intrusions, and monitor the consumption of cloud-computing services their associated cloud-computing resources in order to determine the costs accrued by a user. Aspects of cloud-computing resources monitored by manager module <b>526</b> include, for example, central processing unit (CPU) usage, memory usage, data storage usage, data input/output usage, application usage, workload usage, service usage, and other attributes of usage of a service or a computer workload.

0077In some embodiments, manager module <b>526</b> is configured such that a user can request a planner using the planner module <b>523</b> to change the design of a cloud-computing service. For example, a user may request that the cloud-computing service change or computer workload with respect to the cloud-computing resources utilized (e.g., change to a platform stack). As in the other components of the platform <b>520</b>, in the manager module <b>526</b> the user may have access to, or may create or modify, policy information or metamodel data relevant to the computer workloads with which the user can interact in the manager module <b>526</b>. The manager/user of the manager module <b>526</b> may thus manage the provisioning of infrastructure and platform elements such that usage will be consistent with the policies of the enterprise, including operational and business policies, as well as technical requirements. For example, provisioning to expensive infrastructure elements may be confined to workloads that satisfy business rules that distinguish between mission critical elements and other elements. The manager/user of the manager module <b>526</b> may be provided with access to the policies consistent with the metamodel framework, and in embodiments may be provided with pre-filtered options, such as in menu choices, decision trees, or the like, that are consistent with such policies. For example, a workload designated as non-critical in its metamodel data could automatically appear in the manager module with deployment options confined to relatively low cost clouds, while a mission-critical workload might appear with all different cloud options (or ones that are filtered to satisfy certain requirements as to low latency, bandwidth, storage capacity, guaranteed quality of service, or the like). As with other modules, the manager module <b>526</b> may thus enforce policy while streamlining workflow, improving both effectiveness and efficiency.

0078In some embodiments, the cloud-computing platform can also comprise a scheduling module <b>550</b>, as shown in <figref idref="DRAWINGS">FIG. 5</figref>. As discussed previously, the scheduling module <b>550</b> can be configured to place workloads across multiple environments to achieve optimal price, performance, and service levels while providing governance and control over security and compliance. In some implementations, the scheduling module <b>550</b> can comprise an interface or component configured to receive an application design plan(s). The scheduling module <b>550</b> can also comprise an interface or component configured to receive deployment criteria. The deployment criteria can, for example, be associated with one or more deployment policies and/or one or more deployment constraints. Furthermore, the scheduling module <b>550</b> can comprise one or more components or modules configured to identify available infrastructure resources and/or configured to determine a plurality of deployment options compliant with deployment criteria. In some instances, the scheduling module <b>550</b> can also comprise a ranking module or component configured to rank, sort, or order the plurality of deployment options to produce an ordered set of deployment options. Moreover, the scheduling module <b>550</b> can optionally comprise a tree generation module configured to generate a tree data structure representing (a deployment plan corresponding to) the ordered set of deployment options.

0079As discussed previously, in some cases, the scheduling module <b>550</b> can be implemented as software, hardware, or any combination thereof. In some embodiments, the scheduling module <b>550</b> can be implemented as an extension to a cloud (e.g., hybrid cloud environment) management abstraction layer (or module, component, system, platform, etc.), such as the cloud-computing platform <b>520</b>. The scheduling module can, for example, be implemented as an extension to a policy and governance model of the cloud-computing platform <b>520</b>. Moreover, in some embodiments, the scheduling module <b>550</b> can be implemented, in part or in whole, in one or more of the various modules included with the cloud-computing platform <b>520</b>. For example, in some cases, the scheduling module <b>550</b> can be implemented, in part or whole, in the manager module <b>526</b>.

0080<figref idref="DRAWINGS">FIG. 6</figref> shows a diagram illustrating an example management module <b>626</b> (e.g., management module <b>526</b> in <figref idref="DRAWINGS">FIG. 5</figref>) in further detail. As illustrated, management module <b>626</b> comprises governor module <b>603</b> configured to govern operation of a cloud-computing services and its associated cloud-computing resources, provisioning module <b>606</b> configured to provision cloud-computing resources for a cloud-computing service, and monitoring module <b>612</b> configured to facilitate the various monitoring functions of management module <b>626</b>.

0081In embodiments, the present disclosure may provide for a policy-driven infrastructure as a service (IaaS) event bus, which can be comprised of a policy engine, metamodel, reporting system, and workflow engine; and allows for the creation of business policies, such that said business policies can be reflected into a dynamic information technology environment and expressed across internal and external information technology infrastructure, regardless of operating system, programming language, middleware solution, application platform, or cloud provider, by making use of abstraction layers. The workflow engine provides an integration point between the IaaS event bus and workflow management. The abstraction layers allow for integration with application programming interfaces made available by different vendors, business models, technical models, eventing and altering channels and monitoring systems in a vendor agnostic manner. In embodiments the abstraction layer could be a cloud-computing provider. A cloud computing provider may be VMWare, Baremetal, Amazon EC2, Savvis, TerreMark, Microsoft HyperV, and the like. In other embodiments, there may be multiple layers of abstraction in an abstraction layer.

0082The policy engine allows policies to be created through an easy to use visual interface that allows users that do not necessarily have information technology skills or other programming skills to author and assign policies to workloads. The policies can be expressed via languages such as XML, and the like. In some embodiments of the present disclosure a policy could be an event policy. An event policy supports matching one or more events that are temporally related and generate a notification action when matches occur. An event can be defined as either a threshold condition or matching constraints specified as rules. A rule can be comprised of one or more match constraints and each match constraint must be satisfied, by a logical “and” operation, within a specified sliding time window in order for the notification actions to be invoked. A match specifies the set of conditions that must be satisfied to match an event. Each condition specifies a property of an event or object contained by the event, which is matched against a set of one or more values using the supplied comparison operation If multiple values are supplied for a condition then the result is a logical “or” operation of the property being compared and against each value individually. Any of the event properties or properties of objects contained within the event structure may be used to refine the match criteria. For example, an auto-scaling policy may be created to add more web and database servers according to a ration if a business application becomes heavily loaded, in order to reduce the load on that application. In another example, an auto-scaling policy with business awareness may be created that deploys additional business topologies according to an algorithm if revenue per hour exceeds a threshold.

0083The metamodel allows the system to abstract business user definition from technical definition and allows an enterprise to track information about information technology resources that were unknown when the system was created. By abstracting the business user definition from the technical definition, the metamodel allows business users to define data classes consistent with their enterprise nomenclature, while still being able to map them consistently to the internal system. For example a Tier 4 data center is common technical classification of a data center that generally has the highest uptime, however some enterprises refer to Tier 4 data centers as Tier 1 and the metamodel would allow Tier 1 and Tier 4 to be used interchangeably, depending on the definition used by a specific enterprise. This provides a benefit to the enterprise by eliminating the need to write specific policies for each instance or the need to customize each abstraction layer for individual instances. By tracking information about IT resources that were unknown when the system was created, the metamodel allows business users to arbitrarily define elements of data to track and create policy after the system was built, also allowing the users to track a specific piece of information that is defined for any resources that are managed by the system. Resources could be networks, storage, servers, workloads, topologies, applications, business units, and the like.

0084In other further embodiments, the policy-driven infrastructure as a service may also include additional components. Additional components may be reporting, auditing, and federated identify management systems.

0085In embodiments, the present disclosure may provide for a visual policy editor, which provides an easy-to-use graphical user interface to a feature-rich and extensible policy engine, using a visual programming language and policies, eliminating the need for the user to write complex code to define, assign, and enforce policies. The graphical user interface allows the user to author policies using a visual drag-and-drop interface or an XML editor. The visual programming language functions could be loops, variables, branching, switching, pulling of attributes, code execution within a policy, and the like. For example the visual programming language could access an external pricing engine that contains live pricing information, then make a decision on the next step of the execution process, based on the information it receives from the pricing engine. In some embodiments, policies can be enforced at an object level. Objects could be organizational groups, individual projects, different deployment environments, and the like. Policies could be access control policies, firewall policies, event-based policies and the like. Access control policies could include packages, scripts, and the like. Access control policies could be defined by cloud or other service providers, network attributes, network geographic location, security policies, and the like. Firewall policies may include port and network ACL lists that are applied as policies and applied at container level to ensure conformance to corporate standards for port opening/closing. Event based policies relate to service level management and could include compound threshold rules that trigger an action, lifecycle event management, compound event sequences, signature detection, and policy stacking, and the like. For example, a policy could be defined to restrict deployment of a computing workload to private internal clouds in a specific country.

0086In embodiments, the present disclosure may provide for automated processes to support a continuous integration cycle to migrate a computing workload from a development environment to an operational environment. The continuous integration cycle may include maintaining a code repository, automating the build process, self-testing the build process, automatically deploying the build, and the like. The policies and metamodels defined and assigned to the computing workload environment follow the build from its creation using the Builder Module through to its publication into the Consumption module. This capability allows the enterprise to greatly reduce the time required to develop, test, deploy and update a computing workload. Continuous integration may also include ensuring the modernization, patch management, conforming configuration of deployed cloud-computing services. The embodiments may provide this service as DevToOps policy allowing centrally defined service definition that deployed cloud-compute services can compare against and either update themselves when their configuration no longer matches, warn administrators of non-conformance, rewrite themselves back to conformance when configurations of the cloud-compute services are made arbitrarily, and the like.

0087As noted before, various embodiments of the present disclosure provide standardized access, management, or control to different types of cloud-computing resources on a self-service, on-demand basis without the user needing to know the specific instructions or details for accessing, managing, or controlling those different target cloud-computing resources.

0088In some implementations, in order to translate a standard management action for a cloud-computing service to instructions for its cloud-computing resource and/or instructions for a computer workload to be executed on a cloud-computing resource, some management modules may comprise a cloud model data store <b>609</b> that maps the management action to the appropriate cloud-computing resources. Subsequently, the management action can be translated to one or more instructions for a target cloud-computing resource and/or a computer workload operating thereon. For example, a topology is an example of a cloud service, where a topology can be comprised of a number of individual virtual machines orchestrated together. A common management action to perform on a topology is to start it. This simple topology start action within the management layer gets turned into a number of individual instructions that get passed down into the cloud service bus <b>615</b>, such as (1) calculate the Start Up order for topology, (2) initiate ordered startup one VM at a time, (3) as VM's come up, attach volumes that are associated with the VM, (4) install any packages and software onto the VM's, and (5) once all machines are up and running the topology status changes to running.

0089Cloud service bus <b>615</b> may be utilized to parse management instructions received from the manager module <b>626</b>, transform the management instructions to instructions compatible with the target cloud-computing resource, and route the management instruction to the targeted cloud-computing resource. In some embodiments, the cloud service bus <b>615</b> can then route, via a connection module(s) <b>618</b>, the instructions to the application program interface (API) <b>621</b> for a target cloud-computing resource from an external commercial cloud resource(s) <b>627</b>, or to the virtual machine manager (VMM) (e.g., hypervisor) <b>624</b> for a target cloud-computing resource from an internal private cloud resource(s) <b>630</b>.

Hardware Implementation

0090The foregoing processes and features can be implemented by a wide variety of machine and computer system architectures and in a wide variety of network and computing environments. <figref idref="DRAWINGS">FIG. 7</figref> illustrates an example of a computer system <b>700</b> that may be used to implement one or more of the embodiments described herein in accordance with an embodiment of the invention. The computer system <b>700</b> includes sets of instructions for causing the computer system <b>700</b> to perform the processes and features discussed herein. The computer system <b>700</b> may be connected (e.g., networked) to other machines. In a networked deployment, the computer system <b>700</b> may operate in the capacity of a server machine or a client machine in a client-server network environment, or as a peer machine in a peer-to-peer (or distributed) network environment. In an embodiment of the invention, the computer system <b>700</b> may be a component of the networking system described herein. In an embodiment of the present disclosure, the computer system <b>700</b> may be one server among many that constitutes all or part of a networking system.

0091The computer system <b>700</b> can include a processor <b>702</b>, a cache <b>704</b>, and one or more executable modules and drivers, stored on a computer-readable medium, directed to the processes and features described herein. Additionally, the computer system <b>700</b> may include a high performance input/output (I/O) bus <b>706</b> or a standard I/O bus <b>708</b>. A host bridge <b>710</b> couples processor <b>702</b> to high performance I/O bus <b>706</b>, whereas I/O bus bridge <b>712</b> couples the two buses <b>706</b> and <b>708</b> to each other. A system memory <b>714</b> and one or more network interfaces <b>716</b> couple to high performance I/O bus <b>706</b>. The computer system <b>700</b> may further include video memory and a display device coupled to the video memory (not shown). Mass storage <b>718</b> and I/O ports <b>720</b> couple to the standard I/O bus <b>708</b>. The computer system <b>700</b> may optionally include a keyboard and pointing device, a display device, or other input/output devices (not shown) coupled to the standard I/O bus <b>708</b>. Collectively, these elements are intended to represent a broad category of computer hardware systems, including but not limited to computer systems based on the x86-compatible processors manufactured by Intel Corporation of Santa Clara, Calif., and the x86-compatible processors manufactured by Advanced Micro Devices (AMD), Inc., of Sunnyvale, Calif., as well as any other suitable processor.

0092An operating system manages and controls the operation of the computer system <b>700</b>, including the input and output of data to and from software applications (not shown). The operating system provides an interface between the software applications being executed on the system and the hardware components of the system. Any suitable operating system may be used, such as the LINUX Operating System, the Apple Macintosh Operating System, available from Apple Computer Inc. of Cupertino, Calif., UNIX operating systems, Microsoft® Windows® operating systems, BSD operating systems, and the like. Other implementations are possible.

0093The elements of the computer system <b>700</b> are described in greater detail below. In particular, the network interface <b>716</b> provides communication between the computer system <b>700</b> and any of a wide range of networks, such as an Ethernet (e.g., IEEE 802.3) network, a backplane, etc. The mass storage <b>718</b> provides permanent storage for the data and programming instructions to perform the above-described processes and features implemented by the respective computing systems identified above, whereas the system memory <b>714</b> (e.g., DRAM) provides temporary storage for the data and programming instructions when executed by the processor <b>702</b>. The I/O ports <b>720</b> may be one or more serial and/or parallel communication ports that provide communication between additional peripheral devices, which may be coupled to the computer system <b>700</b>.

0094The computer system <b>700</b> may include a variety of system architectures, and various components of the computer system <b>700</b> may be rearranged. For example, the cache <b>704</b> may be on-chip with processor <b>702</b>. Alternatively, the cache <b>704</b> and the processor <b>702</b> may be packed together as a “processor module”, with processor <b>702</b> being referred to as the “processor core”. Furthermore, certain embodiments of the invention may neither require nor include all of the above components. For example, peripheral devices coupled to the standard I/O bus <b>708</b> may couple to the high performance I/O bus <b>706</b>. In addition, in some embodiments, only a single bus may exist, with the components of the computer system <b>700</b> being coupled to the single bus. Furthermore, the computer system <b>700</b> may include additional components, such as additional processors, storage devices, or memories.

0095In general, the processes and features described herein may be implemented as part of an operating system or a specific application, component, program, object, module, or series of instructions referred to as “programs”. For example, one or more programs may be used to execute specific processes described herein. The programs typically comprise one or more instructions in various memory and storage devices in the computer system <b>700</b> that, when read and executed by one or more processors, cause the computer system <b>700</b> to perform operations to execute the processes and features described herein. The processes and features described herein may be implemented in software, firmware, hardware (e.g., an application specific integrated circuit), or any combination thereof.

0096In one implementation, the processes and features described herein are implemented as a series of executable modules run by the computer system <b>700</b>, individually or collectively in a distributed computing environment. The foregoing modules may be realized by hardware, executable modules stored on a computer-readable medium (or machine-readable medium), or a combination of both. For example, the modules may comprise a plurality or series of instructions to be executed by a processor in a hardware system, such as the processor <b>702</b>. Initially, the series of instructions may be stored on a storage device, such as the mass storage <b>718</b>. However, the series of instructions can be stored on any suitable computer readable storage medium. Furthermore, the series of instructions need not be stored locally, and could be received from a remote storage device, such as a server on a network, via the network interface <b>716</b>. The instructions are copied from the storage device, such as the mass storage <b>718</b>, into the system memory <b>714</b> and then accessed and executed by the processor <b>702</b>. In various implementations, a module or modules can be executed by a processor or multiple processors in one or multiple locations, such as multiple servers in a parallel processing environment.

0097Examples of computer-readable media include, but are not limited to, recordable type media such as volatile and non-volatile memory devices; solid state memories; floppy and other removable disks; hard disk drives; magnetic media; optical disks (e.g., Compact Disk Read-Only Memory (CD ROMS), Digital Versatile Disks (DVDs)); other similar non-transitory (or transitory), tangible (or non-tangible) storage medium; or any type of medium suitable for storing, encoding, or carrying a series of instructions for execution by the computer system <b>700</b> to perform any one or more of the processes and features described herein.

0098For purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the description. It will be apparent, however, to one skilled in the art that embodiments of the disclosure can be practiced without these specific details. In some instances, modules, structures, processes, features, and devices are shown in block diagram form in order to avoid obscuring the description. In other instances, functional block diagrams and flow diagrams are shown to represent data and logic flows. The components of block diagrams and flow diagrams (e.g., modules, blocks, structures, devices, features, etc.) may be variously combined, separated, removed, reordered, and replaced in a manner other than as expressly described and depicted herein.

0099Reference in this specification to “one embodiment”, “an embodiment”, “other embodiments”, “one series of embodiments”, “some embodiments”, “various embodiments”, or the like means that a particular feature, design, structure, or characteristic described in connection with the embodiment is included in at least one embodiment of the disclosure. The appearances of, for example, the phrase “in one embodiment” or “in an embodiment” in various places in the specification are not necessarily all referring to the same embodiment, nor are separate or alternative embodiments mutually exclusive of other embodiments. Moreover, whether or not there is express reference to an “embodiment” or the like, various features are described, which may be variously combined and included in some embodiments, but also variously omitted in other embodiments. Similarly, various features are described that may be preferences or requirements for some embodiments, but not other embodiments.

0100It should also be appreciated that the specification and drawings are to be regarded in an illustrative sense. It can be evident that various changes, alterations, and modifications can be made thereunto without departing from the broader spirit and scope of the disclosed technology.

0101Moreover, the language used herein has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based hereon. Accordingly, the disclosure of the embodiments of the invention is intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.