Systems and methods for configuring and managing computing resources to provide highly-scalable services

One embodiment of the present invention sets forth a cloud computing environment that includes a service cloud and one or more services accessing the service cloud. The service cloud includes multiple resources of different types that support the execution of the services accessing the service cloud. Each resource and service in the cloud computing environment is configured via a centralized configuration service. In addition, resource allocation and predictive performance monitoring engines allocate resources and monitor the resources allocated to the services accessing the service cloud.

BACKGROUND OF THE INVENTION

1. Field of the Invention

The present invention relates generally to online commerce and, more specifically, to systems and methods for configuring and managing computing resources to provide highly-scalable services.

2. Description of the Related Art

The advent of cloud-based computing architectures has allowed for the rapid and scalable deployment of services, such as virtual stores, media outlets, and other online services. In general, a cloud-based architecture includes a set of resources such as processors, operating systems, software and other components that can be combined to form systems on which services can be deployed.

A user can request the instantiation of specific set of resources from a management system to deploy a service. For example, a user may wish to set up and instantiate a virtual server from the cloud to create a storefront to market products or services on a temporary basis, for instance, to sell tickets to an upcoming sports or musical performance. In a typical cloud-based architecture, the user needs to be aware of the specific resources that are needed to deploy a service from the initial stages of service development. The service is often developed in a manner that is closely dependent or coupled to the specific resources on which the service is to be deployed. In addition, to deploy a service, the user typically configures the specific resources based on the configuration requirements of the service.

One drawback to such cloud-based architectures is that the user spends a considerable amount of time on the infrastructure level details, such as configuration, when deploying the service in the cloud. In addition, since the service is developed according to the specific resources and not in a generic manner, the development cycles for developing services that can be deployed on such cloud-based architectures is undesirably long.

As the foregoing illustrates, what is needed in the art is a mechanism for deploying and managing services in a cloud with minimal effort from service developers.

SUMMARY OF THE INVENTION

One embodiment of the present invention sets forth a computer-implemented method for allocating one or more resources to a service that accesses a cloud computing environment. The method includes the steps of, based on configuration information associated with the service, determining one or more resource types necessary for the service to operate, identifying one or more performance requirements specified by the service, where each performance requirement is associated with a different performance metric, and allocating a set of resources included in the cloud computing environment to the service based on the one or more performance requirements, where at least a first resource in the set of resources is of a first resource type included in the one or more resource types.

Advantageously, the cloud computing environment described herein allows service developers to simply define the functionality of the service and describe the operating characteristics of the service. The allocation, configuration and management of the resources and the services are then autonomously performed by engines within the cloud computing environment.

DETAILED DESCRIPTION

FIG. 1illustrates a cloud computing environment100configured to implement one or more aspects of the invention. As shown, the cloud computing environment100includes a service cloud102, a service framework104, services106and a management platform108.

The service cloud102includes a collection of resources, such as hardware resources, platform resources and infrastructure resources, that are configured and managed by different engines within the service cloud102. The service cloud102also manages the allocation of the resources to services, such as service106, interacting with the service cloud102. Further, the service cloud102monitors the performance of the different resources included in the service cloud102as well as the services interacting with the service cloud102. In one embodiment, the service cloud102communicates with other collections of resources, such as an external cloud, to provide a wider array of resources that can be allocated to the services. Additional details of the service cloud102including the resource configuration, resource allocation and monitoring functionalities are set forth below in conjunction withFIG. 4.

The service framework104is an interface layer between the service106and the service cloud102. In one embodiment, the service framework104allows the service106interact to the service cloud102via an abstracted application program interface (API). The service106is designed and developed to seamlessly interact with the interface provided by the service framework104. Additional details of the service framework104are set forth below in conjunction withFIG. 3.

The service106is any application that interacts with the cloud service102to utilize processing capabilities and/or infrastructure and platform resources provided by the cloud service102. For example, the service106may be an entertainment distribution service, a news service or a financial management service. In one embodiment, the service106is distributed to one or more end-users via the cloud service102. The service106can be developed in any technically feasible fashion and in any software programming language as long as the service106is able to interact with the service framework104. Importantly, since the service106interacts only with the service framework104, the service106does not need to be developed with any knowledge of the specific functionalities and resources provided by the service cloud102. Additional details of the service framework104are set forth below in conjunction withFIG. 2.

The management platform108allows service and network administrators to monitor the performance of resources within the service cloud102as well as the services interacting with the service cloud102. The management platform108also allows service and network administrators to perform various management tasks when needed. For example, a service administrator, via the management platform108, may be able to view any captured log data that indicates performance characteristics services interacting with the service cloud102. As another example, a service administrator, via the management platform108, may view or modify configuration information associated with a service interacting with the service cloud102.

Although, in the above description, the cloud computing environment100is shown with one service106and one service framework104, persons skilled in the art will recognize that the architecture ofFIG. 1contemplates only an exemplary embodiment of the invention. Other embodiments may include any number of services106and any number of service frameworks104. Thus,FIG. 1is in no way intended to limit the scope of the present invention in any way.

FIG. 2is a more detailed illustration of the service106ofFIG. 1, according to one embodiment of the invention. As shown, the service106includes an identity token202, a system definition204, a virtual internet protocol (IP) address206, external dependencies208, performance requirements210and service functionality code212.

The identity token202within the service106is a unique key assigned to the service106by the service cloud102. Based on the identity token202, the service106is authenticated with the service cloud102and is able to receive configuration information from the service cloud102via the service framework104. In one embodiment, two or more instances of the service106are interacting with the service cloud102. In such an embodiment, a different identity token202is assigned to each instance of the service106.

As previously described herein, the service106interacts only with the service framework104and does not have any knowledge of the specific functionalities and resources provided by the service cloud102. Instead, the service106defines the types of resources that are needed by the service106to operate and to be accessed by end-users. The system definition204included in the service106defines the type of system the service106needs to operate. More specifically, the system definition204specifies the hardware requirements as well as the operating system requirements for operating the service106. Any other system-level requirements or specifications associated with the service106are included in the system definition204. The virtual IP address206specifies a virtual IP address associated with the service106. The virtual IP address206is a public-facing address that can be used by end-users to access the service106.

The external dependencies208included in the service106specify the types of external resources that are needed for the service106to operate. These external resources are external to the system on which the service206operates. External resources specified by the service106in the external dependencies208may include specific data stores, application servers, legacy systems, federation servers, virtualization servers, etc.

The performance requirements210included in the service106specify thresholds related to specific performance metrics that the service106should meet when the service106operates. The performance requirements210may specify different thresholds for data throughput, latency and resource utilization. As described below, the service cloud102allocates resources to the service106based on the performance requirements210.

The service functionality code212is software code that defines the function of the service106. The service functionality code212can be written in any technically feasible manner and in any programming language. When the service106interacting with the service cloud102is accessed by end-users, the service functionality code212is executed to provide the end-users with the functionality associated with the service106.

FIG. 3is a more detailed illustration of the service framework104ofFIG. 1, according to one embodiment of the invention. As shown, the service framework104includes an authorization layer302, a configuration layer304and a logging and metrics collection layer306.

As previously described herein, the service framework104is an interface layer between the service106and the service cloud102. More specifically, the service106is developed such that any interactions between the service106and the service cloud102are performed via the different layers included in the service framework104. The authorization layer302interfaces between the service106and the service cloud102when the service106needs to be authorized. In operation, the service106, via the authorization layer302, transmits the identity token202to the service cloud102and receives, again, via the authorization layer302, an indication whether the authorization with the service cloud102based on the identity token202was successful.

The configuration layer304interfaces between the service106and the service cloud102when the service106needs to receive configuration information associated with the service106. As will be discussed in greater detail below, configuration information associated with each service, such as the service106, is stored in the service cloud102. Among other information, the configuration information associated with the service106includes the back-end resource configuration associated with the service106. When the service106is ready to receive the associated configuration information, a request is transmitted to, the service cloud102via the configuration layer304. In response, the service106receives the associated configuration information, again, via the configuration layer304.

The logging and metrics collection layer306interfaces between the service106and the service cloud102to collect operating details associated with the service106. The operating details collected by the logging and metrics collection layer306include logs and metrics associated with the performance of the service106, end-user and resource usage patterns associated with the service106, periodic environment snapshots, etc. The operating details collected by the logging and metrics collection layer306are stored in and analyzed by the service cloud102as described in greater detail below.

FIG. 4is a more detailed illustration of the service cloud102ofFIG. 1, according to one embodiment of the invention. As shown, the service cloud102includes a configuration engine402, a token store404, a configuration store406, a resource allocation engine, a logging and metrics engine410, a predictive engine412, platform resources414and hardware resources416.

As previously described herein, the service cloud102provides an infrastructure of resources to services, such as the service106, that interact with the service cloud102. The services interacting with the service cloud102utilize the processing capabilities and functionalities of the resources to operate and distribute service functionality to end-users. The service cloud102includes several management engines, the configuration engine402, the resource allocation engine408and the predictive engine412, that manage and monitor the infrastructure of resources provided by the service cloud102to facilitate the efficient and reliable operation of the services interacting with the service cloud102. For exemplary purposes only, the specific operation of the management engines included in the service cloud102are described below with respect to the service106.

The infrastructure of resources provided by the service cloud102includes the platform resources414and the hardware resources416. Platform resources414include operating system resources, virtual machine resources, database resources, etc. Hardware resources416include servers, routers, storage space, etc. Each platform resource414and hardware resource416is associated with a resource type and a unique identity token, such as identity token418associated with platform resource414(0) and identity token420associated with hardware resource416(0). A resource type associated with a resource indicates the specific functionalities or processing capabilities of the resource. For example, a resource type associated with a platform resource indicates that the platform resource is a database from a specific vendor. As another example, a resource type associated with a hardware resource indicates that the hardware resource is a server having a certain processing power. Resources associated with the same resource type can be co-located or sparsely located, can belong to different organizations, and can be purchased from different vendors.

The platform resources414and the hardware resources416, or portions thereof, are allocated to different services that interact with the service cloud102by the resource allocation engine408. For a particular service, the resource allocation engine408allocates resources included in the service cloud102based on the resource requirements specified by the service. When allocating resources to the service106, the resource allocation engine408first identifies the system definition204, the external dependencies208and the performance requirements210specified by the service106. As previously described herein, the service106, via the system definition204, the external dependencies208and the performance requirements210, specifies the types of resources that are needed by the service106to operate efficiently. The resource allocation engine408then identifies one or more platform resources414and/or one or more hardware resources416(referred to herein as “the identified resources”) that match the types of resources specified by the service106. For example, the system definition204may specify that the service106requires a particular type of operating system, and the resource allocation engine408identifies a platform resource414that is an operating system of the particular type specified by the system definition204.

From the identified resources, the resource allocation engine408selects the particular resources that meet the performance requirements specified by the performance requirements210of the service106. When selecting the particular resources, the resource allocation engine408, based on the performance requirements210, may implement one of several resource allocation algorithms. When the performance requirements210specify that resource availability should be maximized, the resource allocation engine408performs resource allocation according to a location sparsity algorithm. With location sparsity algorithms, resources within the identified resources that are sparsely located relative to each other are typically selected. One implementation of the location sparsity algorithm is described below in conjunction withFIG. 7B. When the performance requirements specify that latency across the service106should be minimized, the resource allocation engine408performs resource allocation according to a location density algorithm. With location density algorithms, resources within the identified resources that are close in proximity relative to each other are typically selected. One implementation of the location density algorithm is described below in conjunction withFIG. 7C.

Another resource allocation algorithm that may be implemented by the resource allocation engine408is the load balancing algorithm. With load balancing algorithms, resources are typically allocated such that resources associated with the same resource type have balanced utilization levels. In addition, the performance requirements210may specify that only resources having a utilization level below a pre-determined threshold are to be allocated to the service106. In such a scenario, any identified resources that do not have a utilization level below the pre-determined threshold are not be allocated to the service106. In other embodiments, any other technically feasible resource allocation algorithms can be implemented by the resource allocation engine408to allocate resources based on the performance requirements210specified by the service106.

As the service106operates on resources allocated by the resources allocation engine408, the logging and metrics engine410collects operating details associated with the allocated resources and the service106. The operating details associated with the allocated resources include performance metrics associated with the platform resources414and the hardware resources416, environment snapshots of service cloud102, resource utilization levels, failure logs, etc. The logging and metrics engine410stores the collected operating details in the logs and metrics store411. In addition, the logging and metrics engine410receives operating details collected by the service106via the service framework104, as previously described herein. The operating details collected by the service106are also stored in the logs and metrics store411.

The predictive engine412is a learning-based engine that analyzes the operational details stored in the logs and metrics store411. In the analysis, the predictive engine412identifies inefficiencies and usage patterns across the service cloud102and predicts future utilization levels of the resources based on pre-determined trends and other historic data. In addition, the predictive engine412compares current patterns with pre-determined trends to determine the likelihood of certain events, such as failures, across the service cloud102. Based on the analysis, the predictive engine412performs one or more remedial operations to improve the overall performance of the service cloud102as well the performance of the services interacting with the service cloud102. The specific operation of the predictive engine412is described in greater detail below in conjunction withFIG. 5.

To realize the functionality of the service cloud102described above, each of the resources and the services (referred to herein as “the entities”) included in and interacting with the service cloud102needs to be configured with the associated configuration information. In addition, the resource allocation engine408and the predictive engine412described above need access to the configuration information associated with each of the entities to facilitate the efficient operation of the service cloud102. For a particular entity, the associated configuration information specifies the different functionalities, properties and architectural dependencies associated with the entity. For example, the configuration information associated with a database platform resource specifies the different properties associated with the database, such as access control information, table sizes, etc. The configuration information associated with the database platform resource also specifies the storage hardware resource that stores the data associated with the database.

The configuration engine402in conjunction with the token store404and the configuration store406provide a centralized configuration mechanism for configuring each of the entities. The configuration information associated with each entity is populated and maintained in the configuration store406by the configuration engine402. Within the configuration store406, configuration information associated with a particular entity is identified by the unique identity token associated with the particular entity. The configuration engine402receives requests for configuration information from different entities and, in response, retrieves the associated configuration information from the configuration store406and transmits the retrieved configuration information to the associated entities.

In operation, when an entity becomes a part of the service cloud102or interacts with the service cloud102, the configuration engine402identifies and generates configuration information associated with the entity for transmission to the entity. When an entity first requests configuration information, the configuration engine402identifies the entity type associated with the entity and then generates configuration information for the entity based on default configuration information corresponding to the entity type. The default configuration information is stored in the configuration store406. The configuration engine402also assigns an identity token to the entity that uniquely identifies the entity in the cloud computing environment100. The identity token is stored in the token store404.

For subsequent requests for configuration information transmitted by the particular entity, the configuration engine402first extracts the identity token included in the request. The configuration engine402next validates the identity token included in the request. To validate the identity token, the configuration engine402determines whether a record corresponding to the extracted identity token exists within the token store404. The identity token is validated when a record corresponding to the identity token exists within the token store404and the entity associated with the identity token is authorized to receive configuration as specified by the record corresponding to the extracted identity. Once the identity token is validated, the configuration engine402retrieves the configuration information associated with the entity from the configuration store406based on the identity token. Again, within the configuration store406, configuration information associated with a particular entity is identified by the unique identity token associated with the particular entity. The configuration information is then transmitted to the requesting entity.

In one embodiment, the configuration engine402performs a validation operation on an entity that requests to become a part of the service cloud102or interact with the service cloud102. To perform the validation operation, the configuration engine402validates the entity against other entities already a part of the service cloud102that have the same entity type. The validation operation may also be performed using a set of pre-defined validation metrics.

In another embodiment, the configuration engine402also stores a hierarchy of configuration information. When a request is received for a particular type of resource, the configuration engine402is configured to resolve the request using the hierarchy of configuration information to identify the particular entity in the service cloud to which the request is to be transmitted.

FIG. 5is a more detailed illustration of the predictive engine412ofFIG. 4, according to one embodiment of the invention. As shown,FIG. 5includes a log/metric analyzer503, templates/patterns504and an operations layer506.

As previously described herein, the predictive engine412is a learning-based engine that analyzes the operational details stored in the logs and metrics store411and, based on the analysis, performs different remedial operations when necessary. The log/metric analyzer502included in the predictive engine412analyzes the operational details collected by the log/metrics engine410to identify inefficiencies and usage patterns across the service cloud102. More specifically, the log/metric analyzer502identifies the types of transactions occurring across the different resources included in the service cloud102. The log/metric analyzer502also identifies load imbalances across resources of the same resource type and identifies resources that are allocated to services and are under utilized by those services. In addition, the log/metric analyzer502determines whether any of the performance metrics collected by the logging and metrics engine410are significantly above or below pre-defined thresholds.

The log/metric analyzer502also performs trend analysis by correlating the operational details gathered by the logging and metrics engine410with templates and/or patterns specified by the templates/patterns504. The templates/patterns504specify different trends that have been identified during the operation of the service cloud102. The templates/patterns504may be associated with specific resources, resource types, and/or services. The templates/patterns504may specify trends that are associated with capacity spikes and drop-offs, events that are associated with imminent failures, etc. The templates/patterns504may be identified by the predictive engine412over time or may be specified by network/service administrators via the management platform108described above.

The operations layer506processes the analysis performed by the log/metric analyzer502to determine whether any remedial operations need to be performed by the predictive engine412. A remedial operation is any action taken by the predictive engine412to correct inefficiencies and/or problems identified by the log/metric analyzer502or to avoid future inefficiencies and/or problems identified by log/metric analyzer based on the trend analysis. In some embodiments, the operations layer506determines whether remedial operations are needed based on cost-metrics and quality-metrics identified for a particular service interacting with the service cloud102. In some cases, the cost of providing a better performing service may be greater than the cost-metric identified for the service. In such cases, remedial operations may not be performed. In other cases, the quality of a service may not increase proportionally to the cost of increasing the performance of the service. In such cases, remedial operations may not be performed.

As another example, based on the analysis performed by log/metric analyzer502, the operations layer502determines that a certain event indicating a failure has occurred and, therefore, performs one or more pre-emptive actions to avoid that failure. As another example, based on the trend analysis performed by log/metric analyzer502, the operations layer502predicts that the usage of a certain service will spike and, therefore, allocates extra resources to the service. As yet another example, based on the analysis performed by log/metric analyzer502, the operations layer502determines that a particular resource is underperforming and, therefore, alerts the network/system administrator, via the management platform108, to address the issue.

In such a manner, the predictive engine412monitors the performance of the service cloud102and the services106interacting with the service cloud102. In monitoring the performance, the predictive engine412also develops knowledge with respect to correlations between certain patterns and trends and certain events. This knowledge is valuable in effectively scaling the resources allocated to services and allowing the service cloud102to be elastic and flexible.

FIG. 6is a flow diagram of method steps for configuring an entity within the cloud computing environment, according to one embodiment of the invention. Although the method steps are described in conjunction with the systems forFIGS. 1-5, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

The method600begins at step602, where the configuration engine402receives a request for configuration information from an entity. Again, for a particular entity, the associated configuration information specifies the different functionalities, properties and architectural dependencies associated with the entity. The configuration information associated with each entity is maintained and populated by the configuration engine402in the configuration store406. The entity, therefore, does not need to maintain any configuration information.

At step604, the configuration engine402extracts the identity token from the request. As previously described herein, each entity in the cloud computing environment100is associated with a unique identity token. When transmitting a request for configuration information, the entity includes the identity token associated with the entity in the request so the entity can be identified and authorized.

At step606, the configuration engine402validates the identity token. To validate the identity token, the configuration engine402determines whether a record corresponding to the extracted identity token exists within the token store404. The identity token is validated when a record corresponding to the identity token exists within the token store404and the entity associated with the identity token is authorized to receive configuration as specified by the record corresponding to the extracted identity.

At step608, the configuration engine402retrieves the configuration information associated with the entity from the configuration store406based on the identity token. At step610, the configuration engine402transmits the retrieved configuration information to the requesting entity.

FIG. 7Ais a flow diagram of method steps for allocating resources to a service, according to one embodiment of the invention. Although the method steps are described in conjunction with the systems forFIGS. 1-5, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

The method700begins at step702, where the resource allocation engine408identifies the resource types needed by the service. In one embodiment, the resource types needed by the service are defined in system requirements and external dependencies specified by the service. At step704, the resource allocation engine408identifies the performance requirements associated with the service. Again, the performance requirements associated with the service specify thresholds related to specific performance metrics that the service should meet when the service operates. The performance requirements may specify different thresholds for performance metrics such as data throughput, latency and resource utilization.

At step706, the resource allocation engine408determines whether, based on the performance requirements, the availability of the resources should be optimized. If, at step706, the resource allocation engine408determines that the availability of the resources should be optimized, then the method700proceeds to step708. At step708, the resource allocation engine408performs resource allocation according to a location sparsity algorithm. The details of one implementation of the location sparsity algorithm are described below in conjunction withFIG. 7B.

If, however, at step706, the resource allocation engine408determines that the availability of the resources need not be optimized, then the method700proceeds to step710. At step710, the resource allocation engine408determines whether, based on the performance requirements, the latency across the service should be minimized. If, at step710, the resource allocation engine408determines that the latency across the service should be minimized, then the method700proceeds to step712. At step712, the resource allocation engine408performs resource allocation according to a location density algorithm. The details of one implementation of the location density algorithm are described below in conjunction withFIG. 7C.

If, however, at step706, the resource allocation engine408determines that the latency across the service need not be minimized, then the method700proceeds to step714. At step714, the resource allocation engine408performs resource allocation according to a load balancing algorithm. For the load balancing algorithm, the resource allocation engine408allocates resources such that resources associated with the same resource type have a balanced utilization levels.

FIG. 7Bis a flow diagram of method steps for allocating resources to a service according to a location sparsity algorithm, according to one embodiment of the invention. Although the method steps are described in conjunction with the systems forFIGS. 1-5, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

At step716, for a particular resource type needed by the service as identified at step702, the resource allocation engine408determines the median utilization level across all resources associated with the particular resource type. At step718, the resource allocation engine408identifies one or more locations of specific resources that are below or at the median utilization level determined at step716. At step720, per location, the resource with the lowest utilization is allocated to the service. Steps716-720are then repeated for each resource type needed by the service. In such a fashion, the locations of the resources allocated to the service are spread out, hence increasing the likelihood of high availability across the resources and, thus, the service.

FIG. 7Cis a flow diagram of method steps for allocating resources to a service according to a location density algorithm, according to one embodiment of the invention. Although the method steps are described in conjunction with the systems forFIGS. 1-5, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

At step722, for a particular resource type needed by the service as identified at step702, the resource allocation engine408determines the median utilization level across all resources associated with the particular resource type. At step724, the resource allocation engine408identifies one or more locations of specific resources that are below or at the median utilization level determined at step716. At step726, the resource allocation engine408selects the location with the largest number of resources that are below or at the median utilization level. At step728, the resource allocation engine408allocates the resources in the selected location to the service. Steps722-728are then repeated for each resource type needed by the service. In such a fashion, the locations of the resources allocated to the service are co-located, hence increasing the likelihood of low latency across the resources and, thus, the service.

FIG. 8is a flow diagram of method steps for configuring an entity within the cloud computing environment, according to one embodiment of the invention. Although the method steps are described in conjunction with the systems forFIGS. 1-5, persons skilled in the art will understand that any system configured to perform the method steps, in any order, is within the scope of the invention.

The method800begins at step802, where the log/metric analyzer502included in the predictive engine412analyzes the operational details collected by the log/metrics engine410to identify inefficiencies and usage patterns across the operation of a service. More specifically, the log/metric analyzer502identifies the types of transactions occurring across the different resources allocated to the service. The log/metric analyzer502also identifies load imbalances across resources of the same resource type and identifies resources that are allocated to the service and are under utilized by those services. At step804, based on this analysis, the operations layer506included in the predictive engine412identifies modifications to resource allocations to the different services to rectify the inefficiencies identified by the log/metric analyzer502.

At step806, the log/metric analyzer502also performs trend analysis by correlating the operational details gathered by the logging and metrics engine410with templates and/or patterns specified by the templates/patterns504. The templates/patterns504specify different trends that have been identified during the operation of the service as well as the general operation of the service cloud102. The templates/patterns504may specify trends that are associated with capacity spikes and drop-offs, events that are associated with imminent failures, etc. At step808, the operations layer506processes the trend analysis performed by the log/metric analyzer502to determine whether any remedial operations need to be performed by the predictive engine412to avoid future problems, failures or inefficiencies.

Advantageously, the cloud computing environment described herein allows service developers to simply define the functionality of the service and describe the operating characteristics of the service. The allocation, configuration and management of the resources and the services are then autonomously performed by engines within the cloud computing environment.

In view of the foregoing, the scope of the present invention is determined by the claims that follow.