Dynamic construction of cloud services

Embodiments of the present invention provide systems and methods for constructing a plan for creating a cloud service. In one embodiment, a configurator receives a request for one or more services making up a cloud service, and a preliminary plan for the requested services is generated. A service provider determines that it is able to fulfill a requested service, and inserts a sub plan for fulfilling the requested service into the preliminary plan. A final plan is generated, which includes a sub plan from each service provider inserted into the preliminary plan.

BACKGROUND OF THE INVENTION

The present invention relates generally to the field of cloud services, and more particularly to dynamically constructing and executing a plan for creating a cloud service based on multiple services.

Service choreography and service orchestration are known concepts in the art for describing the collaboration of services in cloud management systems. Service choreography is demonstrated through the message-based interactions of a set of services, which work together to achieve a larger goal. Each of the services acts individually, on its own, and only the next actor needs to be known to build a cloud service.

Service orchestration implements a central orchestrator to control and steer the interactions between services. The orchestrator executes a plan to compose a cloud service, and the tasks and order of the plan are known at the time of implementation.

SUMMARY

According to one embodiment of the present invention, a method for constructing a plan for creating a cloud service is provided, the method comprising: A method for constructing a plan for creating a cloud service, the method comprising the steps of: receiving, at a configurator, a request for a cloud service, wherein the cloud service comprises one or more services, and wherein one or more service providers are configured to perform the one or more services; generating, by the configurator, a first plan, wherein the first plan comprises workflow steps representing the one or more services; sending, by the configurator, the first plan comprising a message associated with a first workflow step topic to a bus; determining whether a first service provider is able to execute the first workflow step topic; responsive to determining that the first service provider is able to execute the first workflow step topic, inserting, by the first service provider, a sub plan, into the first workflow step topic; and generating a final plan, wherein the final plan comprises one or more sub plans inserted into substantially all of the workflow steps of the first plan.

Another embodiment of the present invention provides a computer program product for constructing a plan for creating a cloud service, based on the method described above.

Another embodiment of the present invention provides a computer system constructing a plan for creating a cloud service, based on the method described above.

DETAILED DESCRIPTION

Embodiments of the present invention recognize the flexibility of a choreographic approach for realizing cloud services. Embodiments of the present invention provide a method which removes the requirement to know and maintain a final plan for each cloud service before the time of implementation and allows the updates of service providers without the need to modify the construction plan for the cloud service. Embodiments of the present invention provide methods and systems for dynamically constructing and executing a cloud service using a choreographic approach involving multiple actors, including log and trace information during the execution of the service to support failure analysis.

The present invention will now be described in detail with reference to the Figures.FIG. 1depicts a functional block diagram illustrating a configuring system, generally designated100, in accordance with an embodiment of the present invention. Modifications to configuring system100may be made by those skilled in the art without departing from the scope of the invention as recited by the claims. In an exemplary embodiment, configuring system100includes message bus110, service providers120A-D, orchestration engine130, and configurator140.

Message bus110is a central application service which provides for communication between the components of configuring system100, including each of service providers120A-D, orchestration service provider130, and configurator140.

Service providers120A-D define each service specification which is provided by configuring system100. Service providers120A-D are each configured to associate themselves with a particular category, provide a particular service, and fulfill requests. Service providers120A-D can be used to provide cloud services according to requests from a user. While there are four (4) service providers depicted inFIG. 1, configuring system100can include any supportable number of service providers.

Orchestration service provider130is a specialized service provider which is registered against the topic of complete construction of the final plan.

Configurator140is an engine which allows a user to configure a cloud service, by selecting from a pool of attached service providers. Configurator140is capable of generating a preliminary plan of a cloud service, based on service providers registered with the system. Configurator140can attach descriptions to messages, and communicate information to, and from, service providers120A-D, via message bus110.

FIG. 2Adepicts flowchart200illustrating operational steps for configuring a skeleton plan for creating a cloud service from a set of selected services, in accordance with an embodiment of the present invention.

In step202, service providers120A-D are registered with configurator140. In this exemplary embodiment, service providers120A-D are registered to the system by connecting to message bus110and onboarding with configurator140. Each of service providers120A-D registers itself against a set of topics, and provides a data structure which each service provider in the same category is able to recognize and understand. For example, a TSAM service provider and an OpenStack service provider may both register themselves against the topic “compute service required.”

In step204, a user configures a particular cloud service. In this exemplary embodiment, a user configures a particular cloud service by selecting one or more services and submitting the service selections to configurator140. The one or more services can be atomic services, one or more complex services, or a combination of both atomic services and complex services.

In step206, configurator140generates a skeleton plan from the set of selected services. In this exemplary embodiment, configurator140uses information gathered from each service provider during the registration (step202) and generates a rough description of the cloud service by ordering the selected services, based on the category of each service. For example, an ordering of selected services can be: (1) compute service, (2) network service, (3) storage service, (4) operating system (OS) monitoring service, (5) database service, and (6) database (DB) monitoring service (described further inFIG. 3A).

FIG. 2Bdepicts flowchart220illustrating operational steps for constructing a final plan from a skeleton plan received from the selected services, in accordance with an embodiment of the present invention.

In step222, configurator140places the generated skeleton plan (from step206ofFIG. 2A) on message bus110. In this exemplary embodiment, configurator140attaches the generated skeleton plan to a message and places the message on message bus110, using the topic of the first service provider. For example, the message can include the topic of “compute service required” with the message content (e.g., AIX 7.1®, XL t-shirt size) including the skeleton plan, and relevant information for the next step(s) can be subsequently derived from the skeleton plan.

In step224, a service provider retrieves the skeleton plan. In this exemplary embodiment, a first service provider who is registered against the topic of the message, retrieves the message from message bus110. For example, the OpenStack service provider, which is registered against the topic “compute service required” can retrieve the message from message bus110. In this exemplary embodiment, the message is distributed to each service provider who is registered to handle a particular topic. For example, both the OpenStack service provider and the TSAM service provider, which are registered against the “compute service required” topic, can retrieve the message from message bus110.

In step226, a service provider fulfills the request contained in the message. In this exemplary embodiment, the first service provider to receive the message and is able to handle the enclosed request will fulfill the request. For example, if the message is received by both the OpenStack service provider and the TSAM service provider, the TSAM service provider can indicate first that it is able to handle the message request, and then processes the request.

In step228, the service provider fulfilling the request inputs the node with their sub plan. In this exemplary embodiment, the service provider which is handling the message request replaces the general topic placeholder node of the skeleton plan and inserts the specific steps (i.e., sub plan) required to fulfill the particular service. For example, the TSAM service provider can replace the “compute service” placeholder node with the specific steps (i.e., sub plan) required to create the “compute service”, such as, (a) get network configuration, (b) create disk, and (c) create VM (described in further detail with respect toFIG. 3A).

In step230, the service provider which fulfilled the request creates a new message and places the message on message bus110. In this exemplary embodiment, the service provider which fulfilled the last request reads the next step from the skeleton plan message and creates a new message, containing the information for a request for the next service provider. For example, after the TSAM compute service provider fulfills the “compute service” request, the TSAM compute service provider can read that the next step in the request is “network service.” The TSAM compute service provider can then create a new message that includes the topic of “network service required” with the message content (e.g., customer and back-up VLN, one service IP) including the updated plan (step228) and the relevant information for the next step(s). After the creation of the new message, the service provider places the message back to message bus110, for further retrieval and access by other service providers.

In step232, the service provider determines whether the plan construction is complete. The plan construction is complete when the service provider fulfilling a request determines that the next node in the plan is an “end” node, indicating that there are no further steps to fulfill and that the plan construction is complete (i.e., final plan is constructed). If, in step232, the service provider determines that the plan construction is not complete, then, in step224, the next service provider retrieves the skeleton plan from message bus110, and the operational steps continue as described above for each additional service provider.

If, in step232, the service provider determines that the plan construction is complete, then, in step234, the last service provider to fulfill its request creates a message to indicate that the plan construction is complete. The message is placed on message bus110for future retrieval and execution of the final plan (FIG. 2C). In some embodiments, validation and optimization of the final plan is completed before the final plan is executed. The final plan can be optimized by combining multiple sub plans to be executed by one service provider into a single task. This optimization can be performed by orchestration service provider130(i.e., final plan inspection and optimization before the final plan execution) or by one of service providers120A-D (i.e., final plan inspection at the time of sub plan injection). Once a final plan is created, the final plan is cached to support multiple executions without the need to recreate that same plan. In another embodiment, a central plan construction service can be implemented, where a ‘getPlanFragment’ call is issued to each service provider, and each service provider returns its sub plan to inject into the skeleton plan. There is no specific knowledge about any of the service providers and no ability to translate the data map and dependencies into plan tasks.

Accordingly, by performing the operational steps ofFIG. 2B, a complete detailed final service plan is constructed, using sub plans obtained from each relevant service provider.

FIG. 2Cdepicts a flowchart illustrating operational steps of orchestration service provider130for executing the constructed final plan, in accordance with an embodiment of the present invention.

In step242, orchestration service provider130retrieves the message indicating the plan construction is complete (step234ofFIG. 2B) from message bus110. In this exemplary embodiment, orchestration service provider130is registered against the “plan construction complete” topic and knows to retrieve the message.

In step244, orchestration service provider130retrieves the constructed final plan and information associated with the final plan, from the message.

In step246, orchestration service provider130implements the generated final plan, along with log information. In this exemplary embodiment, orchestration service provider130generates transitions between each of the services, in order to aid in determining at which point an error has occurred, if the final plan execution fails at some point. The transitions act as a checkpoint, at which all the information is processed and logged before moving on to the next service. In this manner, orchestration service provider130contains the logs and traceability information for each checkpoint, and is better able to identify at which step of a sub plan an error may have occurred.

In step248, orchestration service provider130executes the generated final plan. In this exemplary embodiment, orchestration service provider130executes the final plan as one process instance, and calls each service provider interface in the order specified in the final plan, along with the logging information at each transition (described in further detail inFIG. 3B). The message containing the final plan acts as a “per-thread-storage,” eliminating the need to refer back to the central control when there is an error or failure, improving the overall performance of the system.

Accordingly, by performing the operational steps ofFIG. 2C, the constructed final plan for a cloud service can be executed without being completely known before the time of implementation. Further, each service provider and the sub plan of each service provider can be updated, without the need to update the cloud service.

FIG. 3Adepicts a block diagram of an example of completed final plan construction with sub plan information, in accordance with an embodiment of the present invention. Blocks302,304,306,308,310, and312each represent a category of services. For example, in a particular plan, block302represents compute services, block304represents network services, block306represents storage services, block308represents OS monitoring services, block310represents database services, and block312represents DB monitoring services. Sub plan301A-D represents the specific steps required of the service represented by block302to complete the service. For example, where block302represents compute services, sub plan301A is ‘get network configuration,’ sub plan301B is ‘create disk,’ sub plan301C is ‘create VM,’ and sub plan301D is ‘OS deployment and config.’ Similarly, sub plans303A-B,305A-C,307A-B,309A-B, and311A-B each contain the specific steps required of the services represented by blocks304,306,308,310, and312, respectively.

FIG. 3Bdepicts a block diagram of an example of a generated final plan with transition points to log error information, in accordance with an embodiment of the present invention. As depicted in bothFIGS. 3A and 3B, sub plans301A-D each represent the specific steps required to complete a particular service. Transitions320,330,340,350, and360are each checkpoints, placed between each set of sub plans. For example, transition320is placed between sub plans301A-D (each corresponding to one category of services) and sub plans303A-B (each corresponding to a second category of services). Similarly, each of transitions330,340,350, and360are placed between a sub plan, each sub plan corresponding to a different category of services.