SYSTEMS AND METHODS FOR PROVIDING REPEATED USE OF COMPUTING RESOURCES

Abstract

Systems, methods, and non-transitory computer-readable media can provide access to a first-level computing resource via a service catalog. In some instances, the first-level computing resource can be created by a first entity. Moreover, a second-level computing resource can be received. In some cases, the second-level computing resource can be created by a second entity based, at least in part, on the first-level computing resource. Access to the second-level computing resource can be provided via the service catalog. Relational information associated with the first-level computing resource and the second-level computing resource can be tracked.

Description

CROSS-REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No. 14/213,540, filed Mar. 14, 2014, entitled “SYSTEMS AND METHODS FOR PROVIDING REPEATED USE OF COMPUTING RESOURCES,” which is a continuation-in-part of U.S. patent application Ser. No. 13/842,413, filed Mar. 15, 2013 (now U.S. Pat. No. 9,489,647, issued Nov. 8, 2016), entitled “SYSTEM AND METHOD FOR A CLOUD COMPUTING ABSTRACTION WITH SELF-SERVICE PORTAL”, which is a continuation-in-part of U.S. patent application Ser. No. 13/354,275, filed Jan. 19, 2012 (now U.S. Pat. No. 9,069,599, issued Jun. 30, 2015), 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 which is a continuation-in-part of U.S. patent application Ser. No. 13/009,774 (“the '774 application”) filed Jan. 19, 2011 (now U.S. Pat. No. 8,931,038, issued Jun. 1, 2015) entitled “SYSTEM AND METHOD FOR A CLOUD COMPUTING ABSTRACTION LAYER”; the '774 application claims priority to U.S. Provisional Patent App. No. 61/296,405 filed on Jan. 19, 2010, entitled “ENTERPRISE CLOUD SYSTEM AND METHOD”, and is a continuation-in-part of U.S. patent application Ser. No. 12/488,424 entitled “CLOUD COMPUTING GATEWAY, CLOUD COMPUTING HYPERVISOR, AND METHODS FOR IMPLEMENTING SAME” filed Jun. 19, 2009 (now U.S. Pat. No. 8,514,868, issued Aug. 20, 2013), and published as U.S. Publication No. 20100027552 on Feb. 4, 2010, and 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”; each of which is hereby incorporated herein by reference in its entirety.

FIELD OF THE INVENTION

The present technology relates to the field of computing resources. More particularly, the present technology relates to systems and techniques for providing repeated use of computing resources.

BACKGROUND

The use of computing resources, such as cloud computing resources, is becoming increasingly commonplace. Users of cloud computing services can utilize computing resources provided by the cloud computing services to perform a wide variety of tasks, such as providing infrastructure, platforms, or applications (e.g., software, services). In one example, entities such as corporations can utilize cloud computing to provide low-level infrastructure offerings. In another example, entities can utilize cloud computing to provide middle-level platform offerings. In a further example, entities such as application developers can utilize cloud environments to provide high-level application offerings.

In some cases, computing resources can be provided via service catalogs (or self-service portals). Service catalogs can provide users with access to computing resources (or other offerings) that are available for consumption or utilization. With respect to conventional approaches, there is usually a limited number of entities who build or create the computing resources, but a larger number of entities who consume or utilize the computing resources. As a result, under conventional approaches, the spectrum of available computing resources can be limited and the process of developing or providing these computing resources can be costly, time-consuming, and inefficient. These and other concerns can create challenges for and reduce the overall experience associated with building and utilizing computing resources.

SUMMARY

Various embodiments of the present disclosure can include systems, methods, and non-transitory computer readable media configured to provide access to a first-level computing resource via a service catalog. In some instances, the first-level computing resource can be created by a first entity. Moreover, a second-level computing resource can be received. In some cases, the second-level computing resource can be created by a second entity based, at least in part, on the first-level computing resource. Access to the second-level computing resource can be provided via the service catalog. Relational information associated with the first-level computing resource and the second-level computing resource can be tracked.

In one embodiment, the second-level computing resource can be associated with a higher-level than the first-level computing resource, and the third-level computing resource can be associated with a higher-level than the second-level computing resource.

In one embodiment, each of the first-level computing resource, the second-level computing resource, and the third-level computing resource can correspond to at least one of an Infrastructure-as-a-Service (IaaS) offering, a Platform-as-a-Service (PaaS) offering, or a Software-as-a-Service (SaaS) offering.

In one embodiment, at least two of the first entity, the second entity, or the third entity can correspond to a single entity.

In one embodiment, the relational information can includes at least one of financial information, licensing information, service-level agreement (SLA) information, or configuration information.

In one embodiment, one or more payments can be received from a fourth entity that accesses the third-level computing resource. The one or more payments can be allocated to the first entity, the second entity, and the third entity based on the relational information associated with the first-level computing resource, the second-level computing resource, and the third-level computing resource.

In one embodiment, the relational information can indicate a first portion of the one or more payments to be allocated to the first entity, a second portion of the one or more payments to be allocated to the second entity, and a third portion of the one or more payments to be allocated to the third entity.

In one embodiment, a marketplace configured to facilitate one or more interactions among users of the service catalog can be provided.

In one embodiment, a computing system can be associated with an abstraction layer of a cloud management system. The computing system can be configure to provide for repeated use of computing resources.

Many 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

FIG. 1 illustrates an example scenario in which repeated use of computing resources can be implemented, according to an embodiment of the present disclosure.

FIG. 2 illustrates an example scenario in which repeated use of computing resources can be implemented, according to an embodiment of the present disclosure.

FIG. 3 illustrates an example scenario in which repeated use of computing resources can be implemented and relational information can be tracked, according to an embodiment of the present disclosure.

FIG. 4 illustrates an example system implementation configured to provide repeated use of computing resources, according to an embodiment of the present disclosure.

FIG. 5 illustrates an example method implementation for providing repeated use of computing resources, according to an embodiment of the present disclosure.

FIG. 6 illustrates an example method implementation for providing repeated use of computing resources, according to an embodiment of the present disclosure.

FIG. 7 shows a diagram illustrating an example system in accordance with an embodiment of the present disclosure.

FIG. 8 shows a diagram illustrating an example management module in accordance with an embodiment of the present disclosure.

FIG. 9 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.

The 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 Repeated Use of Computing Resources

It is becoming more commonplace to consume or utilize cloud computing resources. For example, users often consume cloud-based information technology (IT) resources using a self-service portal or service catalog. In some instances, the cloud-based IT resources can be categorized as Infrastructure-as-a-Service (IaaS), Platform-as-a-Service (PaaS), or Software-as-a-Service (SaaS). In general, IaaS, PaaS, and SaaS resources can differ with respect to the “completeness” of the resource. For example, IaaS is usually associated with delivery of low-level operating system instances and resources, whereas PaaS is associated with delivery of a middle-ware environment and resources, which can be suitable for deploying application code. Moreover, SaaS is usually associated with delivery of high-level, full-featured, ready-to-use applications (e.g., software, services, programs, etc.).

In some embodiments, higher-level offerings can be built (e.g., created, generated, developed, etc.) based on lower-level offerings. For instance, one can build a PaaS offering by starting with an IaaS resource and then adding and configuring middle-ware software to the IaaS resource to create the PaaS offering. Similarly, one can build a SaaS application based on a PaaS resource or offering.

Under conventional approaches, self-service portals or service catalogs can operate in a somewhat restricted fashion. With respect to conventional approaches to providing offerings (or computing resources), there can be a relatively small number of entities who create or build offerings and a relatively larger number of entities who consume or utilize offerings.

Various embodiments of the present disclosure can provide for repeated use (e.g., recursive consumption and/or publication) of computing resources or offerings, such as cloud computing resources or offerings. The disclosed technology can provide a self-service portal or service catalog configured to allow for a layered creation of offerings by a relatively larger number of users or entities. In some cases, a user can identify and consume a low-level offering (e.g., IaaS) and use it to build a middle-level offering (e.g., PaaS) by adding and configuring middle-ware software components. The middle-level offering can then be “republished” back into (or made available at) the self-service portal or service catalog for consumption by other users. Further, a middle-level offering, such as the middle-level offering built based on the low-level offering, can be consumed and used to create a high-level offering (e.g., SaaS). The high-level offering can also be republished back into the self-service portal or service catalog for subsequent consumption or utilization. Relational information associated with the low-level, middle-level, and/or high-level offerings can also be tracked, such as for payment allocation and/or licensing purposes. Accordingly, the disclosed technology can, for example, provide an improved approach to consuming and publishing computing resources (e.g., repeatedly or recursively), allow for a larger number of entities to build and offer computing resources, and permit a wider variety of computing resources to be published and available.

FIG. 1 illustrates an example scenario 100 in which repeated use of computing resources can be implemented, according to an embodiment of the present disclosure. The example scenario 100 can include a repeated use module (e.g., component, unit, system, etc.) 102. In some embodiments, the repeated use module 102 can be implemented in, integrated with, or can correspond to a service catalog, which can reside, in part or in whole, within an abstraction layer of a cloud management system/platform. The repeated use module 102 can be configured to automate and facilitate repeated use (e.g., recursive consumption and/or publication) of computing resources or offerings. For example, the repeated use module 102 can provide access to a low-level resource such as IaaS 104, a high-level resource such as SaaS 108, as well as one or more intermediate-level or middle-level resources such as PaaS 106.

In the example of FIG. 1, the repeated use module 104 can be configured to provide User A 110 with access to the low-level resource (e.g., IaaS 104). The low-level resource can provide infrastructure, an operating system (OS), and/or other low-level features. User A 110 can consume or utilize the low-level resource to build, create, or develop a middle-level resource (e.g., PaaS 106). For instance, User A 110 can add middleware and/or other middle-level functionality, such as web servers, applications servers, storage systems, databases, etc., to the low-level resource in order to create the middle-level resource. Subsequently, User A 110 can “publish” (e.g., make available, provide, offer, release, etc.) the middle-level resource via the repeated use module 102. The repeated use module 102 can then provide access to the middle-level resource for consumption.

Continuing with the example of FIG. 1, User B 112 can search for, find, and/or identify the middle-level resource (e.g., PaaS 106) via the repeated use module 102. User B 112 can consume the middle-level resource and use it to develop a high-level resource (e.g., SaaS 108). For example, User B 112 can start with the middle-level resource and deploy application code with respect to the middle-level resource to generate a high-level resource (e.g., SaaS 108), such as an application, service, program, software, etc. User B 112 can publish and offer the generated high-level resource via the repeated use module 102. For example, User B 112 can republish (or publish) the high-level resource back into the repeated use module 102 (or into a service catalog associated with the repeated use module 102). The repeated use module 102 (or associated service catalog) can enable the high-level resource to be available for consumption. User C 114 can, for example, consume the high-level resource.

Accordingly, the example scenario 100 of FIG. 1 can illustrate how the repeated use module 102 is configured to provide the ability to link publishing/republishing steps together, such as by publishing IaaS 104, (re-)publishing PaaS 106, and (re-)publishing SaaS 108.

In some instances, each of User A 110, User B 112, and User C 114 can correspond to an entity, such as a corporation, company, enterprise, organization, group, individual, virtual unit, etc., or any combination thereof, or to any number of persons associated with the entity. In one example, User A 110, User B 112, and User C 114 can all correspond to the same entity. In another example, at least two of User A 110, User B 112, and User C 114 can correspond to the same entity. In a further example, User A 110, User B 112, and User C 114 can correspond to different entities.

In some cases, the consumption of low-level resources (e.g., low-level offerings, low-level services, etc.) and the republishing of higher-level resources (e.g., resources having a higher-level than low-level resources) built on the low-level resources can occur within a single entity. For instance, the consumers, publishers, and/or users of the resources can correspond to different departments within an entity. In one example, an IT department of a company can create a PaaS offering using IaaS resources. Then application developers (e.g., business units) of the company can create a SaaS offering based on the PaaS offering created by the company's IT department.

FIG. 2 illustrates an example scenario 200 in which repeated use of computing resources can be implemented, according to an embodiment of the present disclosure. In some cases, the consumption and republishing of computing resources or offerings can, for example, occur among different entities, such as organizations, using a (global) self-service portal or service catalog. For instance, as shown in the example scenario 200 of FIG. 2, Entity A 210 can create and offer/publish an IaaS resource 204 via a repeated use module 202 (or via a service catalog associated with the repeated use module 202). Entity B 212 can (find and) consume the IaaS resource 204 and use it to create a PaaS offering 206. Entity B 212 can subsequently offer or (re-)publish the PaaS offering 206 back at the repeated use module 202 (or service catalog). Entity C 214 can (identify and) consume the PaaS offering 206 published by Entity B 212 and can use it to create a SaaS offering 208. Entity C 214 can (re-)publish the SaaS offering 208 back at the repeated use module 202 (or service catalog). Entity D 216 can then consume the SaaS offering 208 published by Entity C 214.

Furthermore, the disclosed technology can provide for the tracking, recording, and/or maintenance of relational information associated with various uses and/or users of the computing resources or offerings. FIG. 3 illustrates an example scenario 300 in which repeated use of computing resources can be implemented and relational information can be tracked, according to an embodiment of the present disclosure. In some embodiments, relational information can refer to information associated with the relationships between various computing resources or offerings provided by a repeated use module 302 (or service catalog) and/or the relations between their consumers, publishers, and/or users. In some instances, relational information can include (but is not limited to) information about money flow or finances (e.g., real money, virtual money, internal budget, etc.) associated with the various uses (e.g., consumption, publication, republication, etc.) and/or users (e.g., consumers, publishers, republishers, etc.) of the computing resources or offerings.

For instance, consumption of a low-level resource can “cost” a given amount. A publisher or developer of a middle-level resource can create the middle-level resource based on the low-level resource, and can offer the created middle-level resource for sale. The publisher or developer of the middle-level resource can consider the given cost of the low-level resource as a “cost of goods sold.” The publisher or developer of the middle-level level can accordingly price the middle-level resource to cover the given cost of the low-level resource. In addition, a publisher or developer of a high-level resource can create the high-level resource based on the middle-level resource. The high-level resource publisher or developer can also consider the price paid for the middle-level resource as a “cost of goods sold.” As such, the high-level resource publisher or developer can price its offered high-level resource to cover the cost of the middle-level resource (which incorporates the cost of the low-level resource). When a high-level resource consumer pays for the high-level resource, the price paid can cover the costs associated with all of the high-level, middle-level, and low-level resources. Various embodiments of the present disclosure can track (e.g., record, maintain, etc.) relational information, including financial information, associated with various uses and/or users of the computing resources and can allocate or distribute finances appropriately based on the financial information.

In FIG. 3, the illustrated example scenario 300 can involve a repeated use module 302 (and/or a service catalog associated with the repeated use module 302). Entity A 310 can create and publish an IaaS resource 304 via the repeated use module 302 (or service catalog). In this example, Entity A 310 can decide to charge $15 for the IaaS resource 304.

Continuing with the example, Entity B 312 can find the IaaS resource 304 and decide to consume or use the IaaS resource 304 to create a PaaS resource 306. Entity B 312 can decide to charge $35 for building the PaaS resource 306, which is built based on the $15 IaaS resource 304, and thus resulting in a total of $50 for the PaaS resource 306 built on the IaaS resource 304. Entity B 312 can offer and republish the PaaS resource 306 back at the repeated use module 302 (or service catalog).

Subsequently, in this example, Entity C 314 can identify the PaaS resource 306 and decide to consume or use the PaaS resource 306 to create a SaaS resource 308. Entity C 314 can decide to charge $50 for building the SaaS resource 308, which is built based on the $35 PaaS resource 306 and the $15 IaaS resource 304, and thus resulting in a total of $100 for the SaaS resource 308 (incorporating the PaaS resource 306 and the IaaS resource 304). Entity C 314 can then offer and republish the SaaS resource 308 back at the repeated use module 302 (or service catalog).

Finally, in this example, Entity D 316 can decide to purchase the SaaS resource 308 and pay $100. As discussed previously, the repeated use module 302 can track the relational information, including financial information, associated with the SaaS resource 308, the PaaS resource 306, and the IaaS resource 304 (and/or the relational information associated with Entity A 310, Entity B 312, and Entity C 314). Accordingly, the repeated use module 302 can automatically allocate (and/or distribute) the $100 paid by Entity D 316 in the appropriate amounts to Entity A 310, Entity B 312, and Entity C 314. In this example, 50% of the $100 (or $50) can be given to Entity C 314, 35% of the $100 (or $35) can be given to Entity B 312, and 15% of the $100 (or $15) can be given to Entity A 310.

Moreover, in some cases, other types of relational information can be tracked by the repeated use module 302. For example, in addition to financial information, the repeated use module 302 can be configured to track and apply other types of relational information including (but not limited to) licensing information, service-level agreement (SLA) information, configuration information, and/or other similar types of information. Further, constraints related to the relational information can be applied by the repeated use module 302.

With respect to licensing information as an example, the repeated use module 302 can receive and enforce licensing terms as constraints with respect to an IaaS resource, a PaaS resource, a SaaS resource 108, or any other level of computing resource. For example, an entity that publishes a resource may offer the resource subject to specified licensing terms to consumers of the resource. The licensing terms can limit access to the resource based on any number and any types of constraints, such as number of seats, usage restrictions, geographic restrictions, tiered pricing structures, time duration, competitive exclusions, etc. The repeated use module 302 may enforce these constraints before or during consumption of the resource by any entity. For example, if the license terms provide that a consuming entity may not exceed a predetermined number of seats, then the repeated use module 302 may determine how many users associated with the entity are using the resource and cease access for users that exceed the permitted number of seats.

As another example, the license terms on which the resource can be offered to an entity may provide for usage restrictions. In this regard, if the license terms prohibit the combination of an offered resource with certain other resources (e.g., incompatible software, open source software with copyleft, etc.), then the repeated use module 302 can prohibit such combination by a consuming entity.

As yet another example, the license terms for the resource published by an entity can exclude competitors of the entity from accessing the resource. In this case, the repeated use module 302, upon determining that a competitor to the entity seeks access to the resource, can deny the competitor access to the resource.

In a similar manner, the repeated use module 302 may apply constraints associated with SLAs and configuration information in the publication and consumption of resources.

FIG. 4 illustrates an example system implementation configured to provide repeated use of computing resources, according to an embodiment of the present disclosure. In FIG. 4, the example system implementation can correspond to a repeated use module 400. The repeated use module 400 can correspond to the repeated use module 102 of FIG. 1, the repeated use module 202 of FIG. 2, the repeated use module 302 of FIG. 3, and/or the repeated use module 750 of FIG. 7. The repeated use module 400 can, for example, comprise a consumption mechanism (or component, feature, unit, module, etc.) 402, a publication mechanism 404, a tracking mechanism 406, and a controller mechanism 408. The controller mechanism 408 can be configured to manage or control the various tasks of the repeated use module 400, such as facilitating the interactions or communications among the consumption mechanism 402, the publication mechanism 404, and/or the tracking mechanism 406. The controller mechanism 408 can also apply constraints relating to relational information in the publication and consumption of resources, as discussed herein.

In some embodiments, the consumption mechanism 402 can be configured to perform operations associated with the consumption of computing resources or offerings. For example, the consumption mechanism 402 can be configured to facilitate providing access to various computing resources or offerings for consumption.

In some embodiments, the publication mechanism 404 can be configured to perform operations associated with the publishing (or republishing) of computing resources or offerings. For example, the publication mechanism 404 can be configured to facilitate receiving various developed/created computing resources or offerings to be offered and/or (re-)published.

In some embodiments, the tracking mechanism 406 can be configured to perform operations associated with tracking, recording, and/or maintaining information (e.g., relational information) associated with various computing resources and/or users. For example, the tracking mechanism 406 can be configured to facilitate tracking relational information including (but not limited to) financial information, licensing information, service-level agreement (SLA) information, and/or configuration information. In some embodiments, the tracking mechanism 406 can also be configured to facilitate receiving one or more payments and allocating (and/or distributing) the one or more payments appropriately based on the relational information.

FIG. 5 illustrates an example method implementation 500 for providing repeated use of computing resources, 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. At step 502, the example method implementation 500 can provide access to a first-level computing resource via a service catalog. In some instances, the first-level computing resource can be created by a first entity.

Step 504 can include receiving a second-level computing resource. In some implementations, the second-level computing resource can be created by a second entity based, at least in part, on the first-level computing resource. Moreover, access to the second-level computing resource can be provided via the service catalog, at step 506.

Then, the example method implementation 500 can track relational information associated with the first-level computing resource and the second-level computing resource, at step 508. In some embodiments, the relational information can include (but is not limited to) at least one of financial information, licensing information, service-level agreement (SLA) information, and/or configuration information, etc., as discussed previously.

FIG. 6 illustrates an example method implementation 600 for providing repeated use of computing resources, according to an embodiment of the present disclosure. Again, 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. The example method 600 can receive a third-level computing resource, at step 602. In some embodiments, the third-level computing resource can be created by a third entity based, at least in part, on the second-level computing resource.

The example method 600 can provide access to the third-level computing resource via the service catalog, at step 604. Step 606 can include tracking relational information associated with the first-level computing resource, the second-level computing resource, and the third-level computing resource.

Furthermore, in some embodiments, one or more payments can be received from a fourth entity that accesses the third-level computing resource. The one or more payments can be allocated (and/or distributed) to the first entity, the second entity, and the third entity based on the relational information associated with the first-level computing resource, the second-level computing resource, and the third-level computing resource.

In some cases, as discussed previously, the relational information can indicate a first portion of the one or more payments to be allocated to the first entity, a second portion of the one or more payments to be allocated to the second entity, and a third portion of the one or more payments to be allocated to the third entity. In some instances, each of the first, second, and third portions can include a specified amount, a proportion, and/or a percentage.

Moreover, many other variations or applications are possible. In some embodiments, one or more intermediate-level resources (e.g., published/offered middle-level resources) can be optional. For instance, low-level resources such as IaaS can be used directly to create high-level resources such as SaaS. In one example, a developer or creator can start with a low-level resource, add desired functionality to the low-level resource, and generate a high-level resource (e.g., application, service, etc.).

In some embodiments, the service catalog or self-service portal can operate or work with various entities and allow for consumption and/or (re-)publishing at multiple levels.

In some embodiments, the various entities can correspond to different corporate entities. In some embodiments, the various entities can correspond to different departments or portions of a single entity. In some embodiments, the various entities can correspond to a single entity.

In some embodiments, the service catalog or self-service portal can handle the money flow or licensing agreements between all parties in a single-party or multi-party chain of publishers.

Various other embodiments and/or applications are also possible. In one example scenario, the disclosed technology can allow for the creation of a marketplace or exchange for facilitating interactions among users (e.g., consumers, publishers, etc.) of computing resources or offerings.

It 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

FIG. 7 shows a diagram illustrating an example system 710 in accordance with an embodiment of the present disclosure. FIG. 7 illustrates a cloud-computing environment 735 comprising one or more cloud-computing resources, a client network 731 comprising client computing devices 714 (e.g., desktops, laptops, smart mobile devices), and a cloud-computing platform 720 (i.e., cloud management abstraction layer, hybrid cloud management platform) in accordance with an embodiment of the present disclosure. In FIG. 7, cloud-computing platform 720 provides a system through which computing devices 714 residing on client network 731 (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 735 and managed by the cloud-computing platform 720 to provide the cloud computing service. Depending on the embodiment, cloud-computing environment 735 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 720 may reside on the client network 731 or separate from the client network 731.

Cloud-computing environment 735 may comprise an internal cloud, an external cloud, a private cloud, or a public cloud (e.g., commercial cloud). In the example of FIG. 7, cloud-computing environment 735 comprises internal private cloud resource 738, external private cloud resource 741, and secure public cloud resource 744. 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).

By using cloud-computing platform 720 to plan, build, manage, or use cloud-computing resources within a cloud-computing environment, users of platform 720 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 720 can be configured to take the workloads that are developed with the platform 720 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 720 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 720 can access cloud-computing services through platform 720 on-demand and on a self-service basis through the standardized access. Users of cloud computing services offered by platform 720 may include end users, developers, partners, or administrators that reside on the client network 731.

Platform 720 may comprise planner module 723, manager module 726, builder module 729, and consumption module 732. Planner module 723 can be configured to plan cloud-computing service provided by platform 720 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 723 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 723 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 723 can be used by builder module 729 to build a cloud-computing service or to deploy a computer workload to a cloud-computing resource. In the planner module 723 or in other components of the platform 720 associated with the planner module 23 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 723. 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 720, 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 723 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 720 and may be used throughout the development and deployment cycle.

Builder module 729 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 729 may be configured to receive characterization information from planner module 723 and build a cloud-computing service or computer workload based on the information. For example, builder module 729 may be configured to assemble a cloud computing service based on the prioritized list of computer workloads provided by planner module 723. Builder module 729 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 729. 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 729 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 723, in the builder module 729 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 729, 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 729 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 729 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.

Eventually, builder module 729 can publish a cloud-computing service for consumption by users. In some embodiments, the builder module 729 can publish the cloud-computing service to a consumption module 732 (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 729 can enter the cloud-computing service in repository 730 when it is ready and available for consumption by users. Embodiments may also be configured for the builder module 729 such that the development community can approve or disapprove of the cloud-computing service before publication.

Consumption module 732 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 732. Consumption module 732 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 732 may allow users to collaborate on where, what, and how many cloud-computing services are deployed for consumption. In further embodiments, consumption module 732 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 723 and the builder module 729, the consumption module 732 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 720.

Manager module 726 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 726 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 732. Upon invoking the cloud-computing service, the manager module 726 may deploy and start the one or more cloud-computing resources to the virtual private cloud for the cloud-computing service.

With respect to control, manager module 726 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 726 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 726 can govern the cloud-computing resource according to conditions, constraints, security policies, or non-security policies. Manager module 726 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 726 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.

In some embodiments, manager module 726 is configured such that a user can request a planner using the planner module 723 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 720, in the manager module 726 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 726. The manager/user of the manager module 726 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 726 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 726 may thus enforce policy while streamlining workflow, improving both effectiveness and efficiency.

In some embodiments, the cloud-computing platform can also comprise a repeated use module 750, as shown in FIG. 7. The repeated use module 750 can be configured to facilitate or provide for the repeated use (e.g., recursive consumption and/or publication) of computing resources or offerings. In some implementations, the repeated use module 750 can correspond to the repeated use module 102 of FIG. 1, the repeated use module 202 of FIG. 2, the repeated use module 302 of FIG. 3, and/or the repeated use module 400 of FIG. 4.

In some cases, the repeated use module 750 can be implemented as software, hardware, or any combination thereof. In some embodiments, the repeated use module 750 can be implemented in, integrated with, or can correspond to a service catalog or a self-service portal. In some embodiments, the repeated use module 750 can be implemented as or reside with (at least a portion of) the cloud computing platform 720. Moreover, in some embodiments, the repeated use module 750 can be implemented, in part or in whole, in one or more of the various modules included with the cloud computing platform 720. For example, the repeated use module 750 can be implemented, in part or in whole, in a scheduling module of the cloud computing platform 720 and/or in the manager module 726 of the cloud computing platform 720.

FIG. 8 shows a diagram illustrating an example management module 826 (e.g., management module 726 in FIG. 7) in further detail. As illustrated, management module 826 comprises governor module 803 configured to govern operation of a cloud-computing services and its associated cloud-computing resources, provisioning module 806 configured to provision cloud-computing resources for a cloud-computing service, and monitoring module 812 configured to facilitate the various monitoring functions of management module 826.

In 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, middle-ware 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.

The 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.

The 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.

In 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.

In 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.

In 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.

As 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.

In 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 809 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 815, 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.

Cloud service bus 815 may be utilized to parse management instructions received from the manager module 826, 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 815 can then route, via a connection module(s) 818, the instructions to the application program interface (API) 821 for a target cloud-computing resource from an external commercial cloud resource(s) 827, or to the virtual machine manager (VMM) (e.g., hypervisor) 824 for a target cloud-computing resource from an internal private cloud resource(s) 830.

Hardware Implementation

The 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. FIG. 9 illustrates an example of a computer system 900 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 900 includes sets of instructions for causing the computer system 900 to perform the processes and features discussed herein. The computer system 900 may be connected (e.g., networked) to other machines. In a networked deployment, the computer system 900 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 900 may be a component of the networking system described herein. In an embodiment of the present disclosure, the computer system 900 may be one server among many that constitutes all or part of a networking system.

The computer system 900 can include a processor 902, a cache 904, 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 900 may include a high performance input/output (I/O) bus 906 or a standard I/O bus 908. A host bridge 910 couples processor 902 to high performance I/O bus 906, whereas I/O bus bridge 912 couples the two buses 906 and 908 to each other. A system memory 914 and one or more network interfaces 916 couple to high performance I/O bus 906. The computer system 900 may further include video memory and a display device coupled to the video memory (not shown). Mass storage 918 and I/O ports 920 couple to the standard I/O bus 908. The computer system 900 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 908. 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.

An operating system manages and controls the operation of the computer system 900, 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.

The elements of the computer system 900 are described in greater detail below. In particular, the network interface 916 provides communication between the computer system 900 and any of a wide range of networks, such as an Ethernet (e.g., IEEE 802.3) network, a backplane, etc. The mass storage 918 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 914 (e.g., DRAM) provides temporary storage for the data and programming instructions when executed by the processor 902. The I/O ports 920 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 900.

The computer system 900 may include a variety of system architectures, and various components of the computer system 900 may be rearranged. For example, the cache 904 may be on-chip with processor 902. Alternatively, the cache 904 and the processor 902 may be packed together as a “processor module”, with processor 902 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 908 may couple to the high performance I/O bus 906. In addition, in some embodiments, only a single bus may exist, with the components of the computer system 900 being coupled to the single bus. Furthermore, the computer system 900 may include additional components, such as additional processors, storage devices, or memories.

In 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 900 that, when read and executed by one or more processors, cause the computer system 900 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.

In one implementation, the processes and features described herein are implemented as a series of executable modules run by the computer system 900, 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 902. Initially, the series of instructions may be stored on a storage device, such as the mass storage 918. 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 916. The instructions are copied from the storage device, such as the mass storage 918, into the system memory 914 and then accessed and executed by the processor 902. 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.

Examples 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 900 to perform any one or more of the processes and features described herein.

For 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.

Reference 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.

It 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.

Moreover, 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.

Claims

1. A computer-implemented method comprising:

providing, by a computing system, access to an Infrastructure-as-a-Service (IaaS) resource via a service catalog, the IaaS resource being created by a first entity, and associated with a first cost;

receiving, by the computing system, a Platform-as-a-Service (PaaS) resource, the PaaS resource being created by a second entity based, at least in part, on the IaaS resource;

providing, by the computing system, access to the PaaS resource via the service catalog, the PaaS resource associated with a second cost;

receiving, by the computing system, a Software-as-a-Service (SaaS) resource, the SaaS resource being created by a third entity based, at least in part, on the PaaS resource;

providing, by the computing system, access to the SaaS resource via the service catalog, the SaaS resource associated with a third cost; and

tracking, by the computing system, relational information associated with the IaaS resource, the PaaS resource, and the SaaS resource, wherein, tracking the relational information associated with the IaaS resource, the PaaS resource, and the SaaS resource comprises tracking financial relational information, such that access of the SaaS resource by a fourth user results in allocation of the first cost to the first entity, the second cost to the second entity, and the third cost to the third entity, and access of the PaaS resource by the fourth user results in allocation of the first cost to the first entity, and the second cost to the second entity.

2. The computer-implemented method of claim 1, wherein the relational information further includes at least one of licensing information, service-level agreement (SLA) information, or configuration information.

3. The computer-implemented method of claim 1, further comprising:

providing a marketplace configured to facilitate one or more interactions among users of the service catalog.

4. The computer-implemented method of claim 1, wherein the computing system is associated with an abstraction layer of a cloud management system.

5. A system comprising:

at least one processor; and

a memory storing instructions that, when executed by the at least one processor, cause the system to perform: providing access to an Infrastructure-as-a-Service (IaaS) resource via a service catalog, the IaaS resource being created by a first entity, and associated with a first cost; receiving a Platform-as-a-Service (PaaS) resource, the PaaS resource being created by a second entity based, at least in part, on the IaaS resource; providing access to the PaaS resource via the service catalog, the PaaS resource associated with a second cost; receiving a Software-as-a-Service (SaaS) resource, the SaaS resource being created by a third entity based, at least in part, on the second-level computing resource; providing access to the SaaS resource via the service catalog, the SaaS resource associated with a third cost; and tracking relational information associated with the IaaS resource, the PaaS resource, and the SaaS resource, wherein tracking the relational information associated with the IaaS resource, the PaaS resource, and the SaaS resource comprises tracking financial relational information, such that access of the SaaS resource by a fourth user results in allocation of the first cost to the first entity, the second cost to the second entity, and the third cost to the third entity, and access of the PaaS resource by the fourth user results in allocation of the first cost to the first entity, and the second cost to the second entity.

6. A non-transitory computer-readable storage medium including instructions that, when executed by at least one processor of a computing system, cause the computing system to perform:

providing access to an Infrastructure-as-a-Service (IaaS) resource via a service catalog, the IaaS resource being created by a first entity, and associated with a first cost;

receiving a Platform-as-a-Service (PaaS) resource, the PaaS resource being created by a second entity based, at least in part, on the IaaS resource;

providing access to the PaaS resource via the service catalog, the PaaS resource associated with a second cost;

receiving a Software-as-a-Service (SaaS) resource, the SaaS resource being created by a third entity based, at least in part, on the second-level computing resource;

providing access to the SaaS resource via the service catalog, the SaaS resource associated with a third cost; and

tracking relational information associated with the IaaS resource, the PaaS resource, and the SaaS resource, wherein tracking the relational information associated with the IaaS resource, the PaaS resource, and the SaaS resource comprises tracking financial relational information, such that access of the SaaS resource by a fourth user results in allocation of the first cost to the first entity, the second cost to the second entity, and the third cost to the third entity, and access of the PaaS resource by the fourth user results in allocation of the first cost to the first entity, and the second cost to the second entity.