Patent ID: 12248971

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.1illustrates an example scenario100in which repeated use of computing resources can be implemented, according to an embodiment of the present disclosure. The example scenario100can include a repeated use module (e.g., component, unit, system, etc.)102. In some embodiments, the repeated use module102can 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 module102can 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 module102can provide access to a low-level resource such as IaaS104, a high-level resource such as SaaS108, as well as one or more intermediate-level or middle-level resources such as PaaS106.

In the example ofFIG.1, the repeated use module104can be configured to provide User A110with access to the low-level resource (e.g., IaaS104). The low-level resource can provide infrastructure, an operating system (OS), and/or other low-level features. User A110can consume or utilize the low-level resource to build, create, or develop a middle-level resource (e.g., PaaS106). For instance, User A110can 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 A110can “publish” (e.g., make available, provide, offer, release, etc.) the middle-level resource via the repeated use module102. The repeated use module102can then provide access to the middle-level resource for consumption.

Continuing with the example ofFIG.1, User B112can search for, find, and/or identify the middle-level resource (e.g., PaaS106) via the repeated use module102. User B112can consume the middle-level resource and use it to develop a high-level resource (e.g., SaaS108). For example, User B112can 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., SaaS108), such as an application, service, program, software, etc. User B112can publish and offer the generated high-level resource via the repeated use module102. For example, User B112can republish (or publish) the high-level resource back into the repeated use module102(or into a service catalog associated with the repeated use module102). The repeated use module102(or associated service catalog) can enable the high-level resource to be available for consumption. User C114can, for example, consume the high-level resource.

Accordingly, the example scenario100ofFIG.1can illustrate how the repeated use module102is configured to provide the ability to link publishing/republishing steps together, such as by publishing IaaS104, (re-)publishing PaaS106, and (re-)publishing SaaS108.

In some instances, each of User A110, User B112, and User C114can 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 A110, User B112, and User C114can all correspond to the same entity. In another example, at least two of User A110, User B112, and User C114can correspond to the same entity. In a further example, User A110, User B112, and User C114can 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.2illustrates an example scenario200in 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 scenario200ofFIG.2, Entity A210can create and offer/publish an IaaS resource204via a repeated use module202(or via a service catalog associated with the repeated use module202). Entity B212can (find and) consume the IaaS resource204and use it to create a PaaS offering206. Entity B212can subsequently offer or (re-)publish the PaaS offering206back at the repeated use module202(or service catalog). Entity C214can (identify and) consume the PaaS offering206published by Entity B212and can use it to create a SaaS offering208. Entity C214can (re-)publish the SaaS offering208back at the repeated use module202(or service catalog). Entity D216can then consume the SaaS offering208published by Entity C214.

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.3illustrates an example scenario300in 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 module302(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.

InFIG.3, the illustrated example scenario300can involve a repeated use module302(and/or a service catalog associated with the repeated use module302). Entity A310can create and publish an IaaS resource304via the repeated use module302(or service catalog). In this example, Entity A310can decide to charge $15 for the IaaS resource304.

Continuing with the example, Entity B312can find the IaaS resource304and decide to consume or use the IaaS resource304to create a PaaS resource306. Entity B312can decide to charge $35 for building the PaaS resource306, which is built based on the $15 IaaS resource304, and thus resulting in a total of $50 for the PaaS resource306built on the IaaS resource304. Entity B312can offer and republish the PaaS resource306back at the repeated use module302(or service catalog).

Subsequently, in this example, Entity C314can identify the PaaS resource306and decide to consume or use the PaaS resource306to create a SaaS resource308. Entity C314can decide to charge $50 for building the SaaS resource308, which is built based on the $35 PaaS resource306and the $15 IaaS resource304, and thus resulting in a total of $100 for the SaaS resource308(incorporating the PaaS resource306and the IaaS resource304). Entity C314can then offer and republish the SaaS resource308back at the repeated use module302(or service catalog).

Finally, in this example, Entity D316can decide to purchase the SaaS resource308and pay $100. As discussed previously, the repeated use module302can track the relational information, including financial information, associated with the SaaS resource308, the PaaS resource306, and the IaaS resource304(and/or the relational information associated with Entity A310, Entity B312, and Entity C314). Accordingly, the repeated use module302can automatically allocate (and/or distribute) the $100 paid by Entity D316in the appropriate amounts to Entity A310, Entity B312, and Entity C314. In this example, 50% of the $100 (or $50) can be given to Entity C314, 35% of the $100 (or $35) can be given to Entity B312, and 15% of the $100 (or $15) can be given to Entity A310.

Moreover, in some cases, other types of relational information can be tracked by the repeated use module302. For example, in addition to financial information, the repeated use module302can 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 module302.

With respect to licensing information as an example, the repeated use module302can receive and enforce licensing terms as constraints with respect to an IaaS resource, a PaaS resource, a SaaS resource108, 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 module302may 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 module302may 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 module302can 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 module302, 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 module302may apply constraints associated with SLAs and configuration information in the publication and consumption of resources.

FIG.4illustrates an example system implementation configured to provide repeated use of computing resources, according to an embodiment of the present disclosure. InFIG.4, the example system implementation can correspond to a repeated use module400. The repeated use module400can correspond to the repeated use module102ofFIG.1, the repeated use module202ofFIG.2, the repeated use module302ofFIG.3, and/or the repeated use module750ofFIG.7. The repeated use module400can, for example, comprise a consumption mechanism (or component, feature, unit, module, etc.)402, a publication mechanism404, a tracking mechanism406, and a controller mechanism408. The controller mechanism408can be configured to manage or control the various tasks of the repeated use module400, such as facilitating the interactions or communications among the consumption mechanism402, the publication mechanism404, and/or the tracking mechanism406. The controller mechanism408can also apply constraints relating to relational information in the publication and consumption of resources, as discussed herein.

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

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

In some embodiments, the tracking mechanism406can 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 mechanism406can 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 mechanism406can 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.5illustrates an example method implementation500for 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 step502, the example method implementation500can 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.

Step504can 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 step506.

Then, the example method implementation500can track relational information associated with the first-level computing resource and the second-level computing resource, at step508. 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.6illustrates an example method implementation600for 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 method600can receive a third-level computing resource, at step602. 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 method600can provide access to the third-level computing resource via the service catalog, at step604. Step606can 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.7shows a diagram illustrating an example system710in accordance with an embodiment of the present disclosure.FIG.7illustrates a cloud-computing environment735comprising one or more cloud-computing resources, a client network731comprising client computing devices714(e.g., desktops, laptops, smart mobile devices), and a cloud-computing platform720(i.e., cloud management abstraction layer, hybrid cloud management platform) in accordance with an embodiment of the present disclosure. InFIG.7, cloud-computing platform720provides a system through which computing devices714residing on client network731(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 environment735and managed by the cloud-computing platform720to provide the cloud computing service. Depending on the embodiment, cloud-computing environment735may 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, platform720may reside on the client network731or separate from the client network731.

Cloud-computing environment735may comprise an internal cloud, an external cloud, a private cloud, or a public cloud (e.g., commercial cloud). In the example ofFIG.7, cloud-computing environment735comprises internal private cloud resource738, external private cloud resource741, and secure public cloud resource744. 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 platform720to plan, build, manage, or use cloud-computing resources within a cloud-computing environment, users of platform720can 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 platform720can be configured to take the workloads that are developed with the platform720and 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 platform720to 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 platform720can access cloud-computing services through platform720on-demand and on a self-service basis through the standardized access. Users of cloud computing services offered by platform720may include end users, developers, partners, or administrators that reside on the client network731.

Platform720may comprise planner module723, manager module726, builder module729, and consumption module732. Planner module723can be configured to plan cloud-computing service provided by platform720by 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 module723may 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, planner723may 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 module723can be used by builder module729to build a cloud-computing service or to deploy a computer workload to a cloud-computing resource. In the planner module723or in other components of the platform720associated with the planner module23the 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 module723. 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 platform720, 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 module723the 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 platform720and may be used throughout the development and deployment cycle.

Builder module729can be configured to assemble, validate, and publish a cloud-computing service or computer workload for consumption (i.e., use) by a user. Builder module729may be configured to receive characterization information from planner module723and build a cloud-computing service or computer workload based on the information. For example, builder module729may be configured to assemble a cloud computing service based on the prioritized list of computer workloads provided by planner module723. Builder module729may be configured to create and edit scripts for loading computer workloads during installation, startup, runtime, and shutdown of cloud-computing services assembled by builder729. 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 module729may 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 module723, in the builder module729the 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 module729, 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 module729the 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 module729may 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 module729can publish a cloud-computing service for consumption by users. In some embodiments, the builder module729can publish the cloud-computing service to a consumption module732(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 module729can enter the cloud-computing service in repository730when it is ready and available for consumption by users. Embodiments may also be configured for the builder module729such that the development community can approve or disapprove of the cloud-computing service before publication.

Consumption module732is 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 module732. Consumption module732may 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 module732may allow users to collaborate on where, what, and how many cloud-computing services are deployed for consumption. In further embodiments, consumption module732may 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 module723and the builder module729, the consumption module732has 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 platform720.

Manager module726can 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 module726may 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 module732. Upon invoking the cloud-computing service, the manager module726may 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 module726may 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 module726may 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 module726can govern the cloud-computing resource according to conditions, constraints, security policies, or non-security policies. Manager module726may 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 module726include, 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 module726is configured such that a user can request a planner using the planner module723to 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 platform720, in the manager module726the 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 module726. The manager/user of the manager module726may 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 module726may 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 module726may thus enforce policy while streamlining workflow, improving both effectiveness and efficiency.

In some embodiments, the cloud-computing platform can also comprise a repeated use module750, as shown inFIG.7. The repeated use module750can 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 module750can correspond to the repeated use module102ofFIG.1, the repeated use module202ofFIG.2, the repeated use module302ofFIG.3, and/or the repeated use module400ofFIG.4.

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

FIG.8shows a diagram illustrating an example management module826(e.g., management module726inFIG.7) in further detail. As illustrated, management module826comprises governor module803configured to govern operation of a cloud-computing services and its associated cloud-computing resources, provisioning module806configured to provision cloud-computing resources for a cloud-computing service, and monitoring module812configured to facilitate the various monitoring functions of management module826.

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 store809that 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 bus815, 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 bus815may be utilized to parse management instructions received from the manager module826, 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 bus815can then route, via a connection module(s)818, the instructions to the application program interface (API)821for a target cloud-computing resource from an external commercial cloud resource(s)827, or to the virtual machine manager (VMM) (e.g., hypervisor)824for 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.9illustrates an example of a computer system900that may be used to implement one or more of the embodiments described herein in accordance with an embodiment of the invention. The computer system900includes sets of instructions for causing the computer system900to perform the processes and features discussed herein. The computer system900may be connected (e.g., networked) to other machines. In a networked deployment, the computer system900may 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 system900may be a component of the networking system described herein. In an embodiment of the present disclosure, the computer system900may be one server among many that constitutes all or part of a networking system.

The computer system900can include a processor902, a cache904, 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 system900may include a high performance input/output (I/O) bus906or a standard I/O bus908. A host bridge910couples processor902to high performance I/O bus906, whereas I/O bus bridge912couples the two buses906and908to each other. A system memory914and one or more network interfaces916couple to high performance I/O bus906. The computer system900may further include video memory and a display device coupled to the video memory (not shown). Mass storage918and I/O ports920couple to the standard I/O bus908. The computer system900may optionally include a keyboard and pointing device, a display device, or other input/output devices (not shown) coupled to the standard I/O bus908. 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, California, and the x86-compatible processors manufactured by Advanced Micro Devices (AMD), Inc., of Sunnyvale, California, as well as any other suitable processor.

An operating system manages and controls the operation of the computer system900, 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 system900are described in greater detail below. In particular, the network interface916provides communication between the computer system900and any of a wide range of networks, such as an Ethernet (e.g., IEEE 802.3) network, a backplane, etc. The mass storage918provides 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 memory914(e.g., DRAM) provides temporary storage for the data and programming instructions when executed by the processor902. The I/O ports920may be one or more serial and/or parallel communication ports that provide communication between additional peripheral devices, which may be coupled to the computer system900.

The computer system900may include a variety of system architectures, and various components of the computer system900may be rearranged. For example, the cache904may be on-chip with processor902. Alternatively, the cache904and the processor902may be packed together as a “processor module”, with processor902being 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 bus908may couple to the high performance I/O bus906. In addition, in some embodiments, only a single bus may exist, with the components of the computer system900being coupled to the single bus. Furthermore, the computer system900may 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 system900that, when read and executed by one or more processors, cause the computer system900to 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 system900, 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 processor902. Initially, the series of instructions may be stored on a storage device, such as the mass storage918. 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 interface916. The instructions are copied from the storage device, such as the mass storage918, into the system memory914and then accessed and executed by the processor902. 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 system900to 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.