WO2024188551A1

WO2024188551A1 - Service orchestrator

Info

Publication number: WO2024188551A1
Application number: PCT/EP2024/053218
Authority: WO
Inventors: Claudia CRISTINA; Simon BEDDUS; Fadi El-Moussa
Original assignee: British Telecommunications Public Limited Company
Priority date: 2023-03-10
Filing date: 2024-02-08
Publication date: 2024-09-19

Abstract

A service orchestrator is provided together with a method for orchestrating a service and computer system and programs for the same. The service orchestrator comprises a repository for storing dynamic inventory information representing a plurality of resources that are available for orchestration by the service orchestrator. The service orchestrator further comprises a service governor configured to accept a service orchestration request specifying a service to be implemented by the service orchestrator. The service orchestrator further comprises a service designer configured to: determine one or more implementation steps for implementing the service, at least one of the implementation steps being associated with a respective precondition; monitor the repository to determine whether the respective precondition for each of the at least one implementation steps have been satisfied; and generate a respective configuration of resources from the plurality of resources for implementing each of the one or more implementation steps. The respective configuration for each of the at least one implementation steps are generated in response to determining that the respective precondition for that implementation step have been satisfied. The service orchestrator further comprises a service coordinator for orchestrating the resources according to the configurations determined by the service designer.

Description

Service Orchestrator

Field of the Invention

The present invention relates to service orchestration.

Background to the Invention

Orchestration systems are increasingly being used to enable automatic configuration, coordination and management of the resources required to deliver services to end users. Such resources may include, for example, any or all of the network, computing and storage resources required to deliver the service. As services become more complex, they may make use of such resources in many different locations, including in the cloud, within the core network itself or at the network edge. Typically, orchestration systems are dedicated to orchestrating a specific type of resource and/or resources in a specific location (such as in the cloud or at the edge). Accordingly, many networks and IT systems will employ a wide range of different (or disparate) orchestration systems, possibly dispersed across various locations (e.g at the network edge), in order to manage the many different types of resources across various locations.

Summary of the Invention

In a first aspect of the invention, there is provided a service orchestrator comprising: a repository for storing dynamic inventory information representing a plurality of resources that are available for orchestration by the service orchestrator; a service governor configured to accept a service orchestration request specifying a service to be implemented by the service orchestrator; a service designer configured to: determine one or more implementation steps for implementing the service, at least one of the implementation steps being associated with a respective precondition; monitor the repository to determine whether the respective precondition for each of the at least one implementation steps have been satisfied; and generate a respective configuration of resources from the plurality of resources for implementing each of the one or more implementation steps, wherein the respective configuration for each of the at least one implementation steps are generated in response to determining that the respective precondition for that implementation step have been satisfied; and a service coordinator for orchestrating the resources according to the configurations determined by the service designer.

The service designer may determine a plurality of implementation steps for implementing the service, each of the implementation steps for implementing a respective portion of the service. Each of the implementation steps may be associated with a respective precondition.

The respective precondition for one or more of the implementation steps may be the availability of a specific resource or type of resource for orchestration.

The service coordinator may be configured to: monitor an implementation of each of the implementation steps to detect an implementation failure; and in response to detecting an implementation failure for a service implementation step, cause the service designer to determine a different configuration of resources for implementing that service implementation step; and orchestrate the resources according to the different configuration for that service implementation step. The implementation failure may comprise either or both of: a failure occurring during orchestration of the resources to implement the implementation step; and a failure occurring after the successful implementation of the implementation step.

The service orchestrator may be a composite service orchestrator for orchestrating services across a plurality of disparate orchestration systems, each of the disparate orchestration systems being associated with a respective set of resources that it is able to orchestrate, wherein: the repository is configured to receive updates on the resources available via each of the disparate orchestration systems such that the dynamic inventory information represents the resource availability across all of the disparate orchestration systems; the service designer is configured to use resources from at least two of the disparate orchestration systems to implement the service; and the service coordinator is configured to orchestrate the resources via the at least two disparate orchestration systems.

In a second aspect of the invention, there is provided a method for orchestrating a service comprising: receiving a service orchestration request specifying a service to be implemented; determining one or more implementation steps for implementing the service, at least one of the implementation steps being associated with a respective precondition; monitoring a plurality of resources that are available for orchestration to determine whether the respective precondition for each of the at least one implementation steps have been satisfied; generating a respective configuration of resources from the plurality of resources for implementing each of the one or more implementation steps, wherein the respective configuration for each of the at least one implementation steps are generated in response to determining that the respective precondition for that implementation step have been satisfied; and orchestrating the resources according to the determined configurations. A plurality of implementation steps may be determined, each of the implementation steps for implementing a respective portion of the service, optionally wherein each of the implementation steps is associated with a respective precondition.

The method may further comprise: monitoring an implementation of each of the implementation steps to detect an implementation failure; and in response to detecting an implementation failure for an implementation step: determining a different configuration of resources for implementing that implementation step; and orchestrating the resources according to the different configuration for that service implementation step. The implementation failure may comprise either or both of: a failure occurring during orchestration of the resources to implement the implementation step; and a failure occurring after the successful implementation of the implementation step.

The method may further comprise: receiving updates on a respective set of resources associated with each of a plurality of disparate orchestration systems that are available via each disparate orchestration system, wherein: the implementation of the service uses resources from at least two of the disparate orchestration systems; and the resources are orchestrated via the at least two disparate orchestration systems.

In a third aspect of the invention, there is provided a computer system comprising a processor and a memory storing computer program code for performing a method according to the second aspect.

In a fourth aspect of the invention, there is provided a computer program which, when executed by one or more processors causes the processors to carry out a method according to the second aspect.

Brief Description of the Figures

Embodiments of the present invention will now be described by way of example only, with reference to the accompanying drawings, in which:

Figure 1 is a block diagram of a computer system suitable for the operation of embodiments of the present invention.

Figure 2 is a block diagram of a service orchestrator according to embodiments of the invention. Figure 3 is a block diagram of a composite service orchestrator according to embodiments of the invention.

Figure 4 is a flowchart illustrating a method for orchestrating a service according to embodiments of the invention.

Figure 5 is a flowchart illustrating a method for orchestrating a service according to embodiments of the invention.

Detailed Description of Embodiments

Figure 1 is a block diagram of a computer system 100 suitable for the operation of embodiments of the present invention. The system 100 comprises: a storage 102, a processor 104 and an input/output (I/O) interface 106, which are all communicatively linked over one or more communication buses 108.

The storage (or storage medium or memory) 102 can be any volatile read/write storage device such as a random access memory (RAM) or a non-volatile storage device such as a hard disk drive, magnetic disc, optical disc, ROM and so on. The storage 102 can be formed as a hierarchy of a plurality of different storage devices, including both volatile and nonvolatile storage devices, with the different storage devices in the hierarchy providing differing capacities and response times, as is well known in the art.

The processor 104 may be any processing unit, such as a central processing unit (CPU), which is suitable for executing one or more computer programs (or software or instructions or code). These computer programs may be stored in the storage 102. During operation of the system, the computer programs may be provided from the storage 102 to the processor 104 via the one or more buses 108 for execution. One or more of the stored computer programs, when executed by the processor 104, cause the processor 104 to carry out a method according to an embodiment of the invention, as discussed below (and accordingly configure the system 100 to be a system 100 according to an embodiment of the invention).

The input/output (I/O) interface 106 provides interfaces to devices 110 for the input or output of data, or for both the input and output of data. The devices 110 may include user input interfaces, such as a keyboard 110a or mouse 110b as well as user output interfaces such as a display 110c. Other devices, such a touch screen monitor (not shown) may provide means for both inputting and outputting data. The input/output (I/O) interface 106 may additionally or alternatively enable the computer system 100 to communicate with other computer systems via one or more networks 112. It will be appreciated that there are many different types of I/O interface that may be used with computer system 100 and that, in some cases, computer system 100 may include more than one I/O interface. Furthermore, there are many different types of device 100 that may be used with computer system 100. The devices 110 that interface with the computer system 100 may vary considerably depending on the nature of the computer system 100 and may include devices not explicitly mentioned above, as would be apparent to the skilled person. For example, in some cases, computer system 100 may be a server without any connected user input/output devices. Such a server may receive data via a network 112, carry out processing according to the received data and provide the results of the processing via a network 112.

It will be appreciated that the architecture of the system 100 illustrated in figure 1 and described above is merely exemplary and that other computer systems 100 with different architectures (such as those having fewer components, additional components and/or alternative components to those shown in figure 1) may be used in embodiments of the invention. As examples, the computer system 100 could comprise one or more of: a personal computer; a laptop; a tablet; a mobile telephone (or smartphone); a domestic or enterprise router; a server; or indeed any other computing device with sufficient computing resources to carry out a method according to embodiments of this invention.

Figure 2 is a block diagram illustrating an exemplary service orchestrator 200 according to embodiments of the invention. The service orchestrator 200 comprises a repository 210, a service governor 220, a service designer 230 and a service coordinator 240. The service orchestrator 200 is associated with a plurality of resources 250 which it is able to orchestrate. That is to say, the service orchestrator 200 is able to configure the plurality of resources 250 in order to implement a service as will be familiar to the skilled person.

The repository 210 is arranged to store dynamic inventory information for the plurality of resources 250 that are available for orchestration by the service orchestrator 200. Any suitable storage means, such as a database may be used to store the dynamic inventory information. In some cases, this dynamic inventory information may be obtained by the service orchestrator 200 directly by detecting (or otherwise retrieving) the status of the resources 250 and storing that information in the repository. In other cases, this dynamic inventory information may be pushed to the repository by the resources 250 themselves, or by agents (not shown) acting as intermediaries to retrieve the information from the resources and provide it for storage in the repository. The dynamic inventory information may include information relating to the performance of the resource, its current configuration, or both. For example, the dynamic inventory information for a compute resource may include information such as CPU usage, network ports, traffic, running applications, virtual infrastructure managers (e.g. hypervisors and/or docker), existing orchestration systems and so on. Of course, this is just an example and it will be appreciated by those skilled in the art, there is a wide range of information that may be collected representing the availability of a resource and that the information may vary depending on the type of resource. In any case, the repository 210 provides an overview of the resources 250 that are available for orchestration at any given time to allow identification of appropriate resources that could be used to implement a service.

The service governor 220 is configured to accept a service orchestration request 260. The service orchestration request 260 specifies a service that an entity providing the request 260 would like to have implemented by the service orchestrator 200.

The service designer 230 generally operates to create an implementation (or design) of the service using the available resources 250. To do so, the service designer 230 refers to the dynamic inventory information stored in the repository 210 to determine a configuration of available resources 250 that satisfies the service design request 260. The operation of the service designer 230 will be discussed in more detail below.

The service coordinator 240 generally operates to implement the service according to the implementation (or design) that was determined by the service designer 230. In particular, it orchestrates the resources 250 to configure them in the manner that was determined by the service designer 230 to satisfy the service design request 260. The operation of the service coordinator 240 will also be discussed in more detail below.

Figure 3 is a block diagram illustrating an exemplary composite service orchestrator 300 for orchestrating services across a plurality of disparate (or heterogeneous) orchestration systems 310 according to embodiments of the invention. The composite service orchestrator 300 shown in figure 3 is the same as the service orchestrator 200 shown in figure 2. However, the resources 250 that are orchestrated by the composite service orchestrator 300 are themselves under the control of a number of other service orchestration systems 310. That is to say, there are multiple sets of resources 250(1 ), 250(2) and 250(3) that may each be orchestrated via a respective orchestration system 310(1 ), 310(2) and 310(3) (i.e. each of the orchestration systems 310(1 ), 310(2) and 310(3) is associated with a respective set of resources that it is able to orchestrate).

The repository 210 of the composite service orchestrator 300 is configured to receive updates about the resources 250 available for orchestration via each of the disparate orchestration systems 310. Accordingly, the dynamic inventory information stored in the repository 210 represents all of the resources 250 that are available for orchestration across all of the disparate orchestration systems 310. In some cases, these updates may be retrieved by the composite service orchestrator itself. In other cases, these updates may be pushed to the composite service orchestrator either by the disparate orchestration systems 310 or by software agents (not shown) installed locally to each of the disparate orchestration systems 310. Such software agents may be configured to retrieve the information from the orchestration systems 310 and/or the resources 250 and send it to the repository 210 of the composite service orchestrator for storage.

The service coordinator 240 of the composite service orchestrator 300 is configured to orchestrate the resources 250 via the disparate orchestration systems 310 in order to configure the necessary resources 250 to implement the service according to a design determined by the service designer 230. That is to say, the service coordinator 240 communicates with each of the disparate orchestration systems 310 that is in control of resources that are needed to implement the service and instructs them to orchestrate their respective resources 250 into the desired configuration. In some cases, this communication between the service coordinator 240 and the disparate orchestration systems 310 may be effected through the use of software agents (not shown) installed locally to the disparate orchestration systems 310. Such software agents may be configured to receive instructions from the service coordinator 240 and, based on the received instructions, in turn instruct one or more of the disparate orchestration system(s) 310 that they are associated with.

In some cases, some or all of the disparate orchestration systems 310 may accept orchestration requests from other entities, other than the composite service orchestrator 300. That is to say, such disparate orchestration systems 310 may utilise their associated resources 250 fulfilling orchestration requests that have not been made by the composite service orchestrator 300, meaning that those resources may be unavailable for use in implementing a service by the composite service orchestrator. In such cases, it will be appreciated that the availability of the resources may change very dynamically, as resources are consumed during the orchestration of resources on behalf of other entities (and equally when resources are freed up during the tear-down of previously orchestrated resources when they are no longer needed by those other entities).

Accordingly, through this multi-layered orchestration approach, the composite service orchestrator 300 is enabled to orchestrate an implementation for a service that uses resources 250 from multiple different types of orchestration systems 310. This can improve the utilisation of the available resources within a modern network or IT systems in which many different types of orchestration systems 310 are typically present to orchestrate different types of resources in different locations. It can also allow for the orchestration of more complex services by enabling a single service orchestrator (i.e. the composite service orchestrator 300) to configure the many different types of resources in many different types of locations that may be needed for a more complex service.

The operation of the service orchestrator 200 illustrated in figure 2, as well as that of the composite service orchestrator 300 illustrated in figure 3, will now be discussed further in conjunction with figures 4 and 5.

Figure 4 is a flowchart illustrating a method 400 for orchestrating a service as performed jointly by the service governor 220 and the service designer 230 according to embodiments of the invention. The method 400 starts with an operation 410.

At operation 410, the method 400 waits to receive a service orchestration request 260. As already discussed, this request 260 is received by the service governor 220 and specifies a service that is to be implemented. The request is received from an entity on whose behalf the service is to be orchestrated. For example, the request 260 may be received directly from a user. As another example, the request 260 may be received from an automated system. The service orchestration request 260 provides a blueprint for implementing the service. That is to say it outlines the key components that are required elements for the service. For example, the service orchestration request may specify endpoints, components, connections, routes and/or credentials to be used for the service.

As a first example, the service orchestration request 260 may specify that a particular application should be installed on a specific node.

As a second example, the service orchestration request 260 may specify to connect a particular type of sensor to a specific cloud endpoint using a particular type of adapter using specified credentials and a certain security policy.

These two examples will continue to be discussed throughout the remainder of the description in order to illustrate the operation of the invention. It will be appreciated that operation of the invention is not limited to such examples and that there is a wide range of service orchestration requests (as well as forms in which those service orchestration requests may be conveyed) that can be received by the service governor 220 at operation 410.

In addition to specifying the key components for service, the service orchestration request

260 may, optionally, also include additional constraints on its implementation. For example, the request 260 may include geographical constraints, such as by requiring that resources must be located in a particular country, such as the UK. Additionally, or alternatively, the request 260 may include security constraints, such as requiring that an application is only deployed to devices which use an encrypted file system. Additionally, or alternatively, the request 260 may include reliability constraints, such as by requiring that an application is only deployed to devices that have a CPU usage lower than 70%.

Having received the service orchestration request 260 at operation 410, the service governor 220 provides the service request to the service designer 230 and the method 400 proceeds to an operation 420.

At operation 420, performed by the service designer 230, the method 400 determines one or more implementation steps for implementing the service specified in the request 260. In doing so, the service designer 230 evaluates the request 220 to check whether all the components are available before proceeding, The service designer 230 identifies those components that are not currently available and breaks down the implementation of the service into one or more implementation steps that can be designed and implemented separately from each other. Although in some simple cases, only a single service implementation step may be determined, it is generally anticipated that more than one service implementation step will be determined, especially as the complexity of the service (and therefore the complexity of its implementation) increases. Any suitable technique for dividing the implementation into a plurality of service implementation steps may be used. For example, a dependency analysis may be performed to identify groups of resources 250 that need to be orchestrated before other groups of resources can be orchestrated. Those groups of resources 250 that need to be orchestrated first may form a first service implementation step, whilst those resources 250 that need to be orchestrated later might form a second or subsequent service implementation step. Where composite service orchestration is being performed across a plurality of disparate service orchestrators 310, another technique that may be employed in addition or alternatively to dependency analysis to determine service implementation steps is to group together resources 250 according to the individual disparate service orchestrator 310 that they are associated with. For example, a first service implementation step might comprise orchestrating all resources 250(1) needed for the service implementation that are associated with the first service orchestrator 310(1) whilst a second service implementation step might comprise orchestrating all resources 250(2) needed for the service implementation that are associated with the second service orchestrator 310(2). A further consideration when breaking down the implementation of the service into one or more implementations steps may be to identify a portion of the service that can be implemented straight away based on current resource availability and other portions of the service that will need to wait for other resources to be available. In addition, or as an alternative to, these techniques, in some cases, the service implementation request 260 itself may also indicate different portions of the service that can be implemented in separate implementation steps.

The service designer 230 need not specify all the implementation steps for implementing the service specified in the request 260 at the same time. Further implementation steps may be determined in one or more further iterations of the method 400 that are carried out once an initial set of implementation steps have been implemented. For example, the service designer may keep a record of partially handled service requests - that is, service requests for which only some of the necessary implementation steps have been specified and for which further implementation steps will need to be specified in order to fully implement the service. This record may include an indication as to when the service designer 230 should specify further implementation steps for that service request (e.g. once one or more of the initial implementation steps have been implemented). This will be discussed further below with reference to figure 5.

In determining the implementation steps for implementing the service, the service designer 230 also identifies a precondition for implementing each step. The precondition indicates the conditions that should be present before the step is implemented. Of course, where one of the steps can be implemented straight away, that step need not be associated with a precondition. However, the remaining steps, that are not implemented straight away, will have a precondition associated with them. For example, the precondition for implementation of a step may be the availability of a specific resource, or of a specific type of resource, for orchestration. Additionally or alternatively, the precondition for implementation of a step may be the successful orchestration of one or more other implementation steps.

Returning to continue the first example previously discussed above, for example, the service designer 230 may review the service orchestration request 260 specifying that a particular application should be installed on a specific node. In doing so, the service designer 230 may determine, based on the information available in the dynamic inventory 210, that the specific node to which the particular application should be installed does not currently have sufficient capacity to deploy the application. The service designer 230 may then create a service implementation step for deploying the application to that node with a precondition being that the node has a sufficient amount of capacity available for the application to be deployed. Similarly, returning to the second example previously discussed above, the service designer 230 may review the service orchestration request 260 specifying that a particular type of sensor should be connected to a specific cloud endpoint using a particular type of adapter with specified credentials and a certain security policy. In doing so, the service designer 230 may determine, based on the information available in the dynamic inventory 210, that no instances of that type of sensor are currently available. The service designer 230 may also determine that none of the remainder of the service should be orchestrated until the type of sensor is available. Accordingly, the service designer may define a single service implementation step for the service with a precondition that a sensor of the particular type is available for orchestration.

It will be appreciated that these examples have been kept simple in order to more clearly explain the operation of the invention. Although the discussion of these examples is kept to a single service implementation step, the skilled person would understand how they can be extended to the use of multiple service implementation steps. For example, in the first example, a second service implementation step could be to connect the application to a specific cloud service via a suitable data link that has a precondition of the first implementation step being successfully orchestrated (i.e. an instance of the particular application being installed on the specific node). Similarly, the second example discussed above could be broken into two steps with the resources being orchestrated to use the credentials and security policy subsequent to the sensor being connected to the cloud endpoint using the particular type of adapter. Indeed, as will be apparent from the discussion of the invention at various places in this description, the operation of the service designer 230 is generally iterative. Accordingly, what is defined as a single service implementation step during a first iteration of the method 400 may subsequently be broken up into more implementation steps when the design of that implementation step is determined in a subsequent iteration. Conceptually, therefore, the definition of a single service implementation step to implement the service may be considered to be similar to defining an initial implementation step for a smaller portion of the service (e.g. adopting the sensor in the second example) and defining the remainder of the service as a partially handled service request to be further processed when the trigger condition for the initial implementation step has been satisfied.

Having determined one or more service implementation steps having preconditions for their implementations at operation 420, the method 400 proceeds to an operation 430.

At operation 430, performed by the service designer 230, the method 400 adds the implementation step(s) to a register of implementation steps that need to be implemented together with an indication of the precondition for implementing each of those implementation step. The method 400 then proceeds to an operation 440.

At operation 440, the method 400 determines whether it should continue. If so, the method 400 returns to operation 410 to await another orchestration request 260. Otherwise, the method 400 ends. In general, it is anticipated that method 400 will be run continuously to handle service orchestration requests 260 as they arise. In such cases, the method 400 may continue until a stop signal is received (for example). However, this need not be the case, and in some instance a single iteration of method 400 may be performed to handle a single orchestration request 260.

Figure 5 is a flowchart illustrating a method 500 for orchestrating a service as performed jointly by the service designer 230 and service coordinator 240 according to embodiments of the invention. The method 500 starts with an operation 510.

At operation 510, performed by the service coordinator 240, the method 500 determines whether there are any pending implementation steps with preconditions. That is to say, whether there are any implementation steps that have been produced by the service designer 230 and stored in the repository (i.e. at operation 430 of the method 400 illustrated in figure 4). If so, the method 500 proceeds to an operation 520. Otherwise, the method 500 waits until an implementation step is provided by the service designer 230.

At operation 520, performed by the service coordinator 240, the method 500 monitors the repository 210 to detect any changes to the resources that are available for orchestration by the system 200. The method then proceeds to an operation 530. As will be appreciated, in some cases, at operation 520, the method 500 may simply wait a predetermined amount of time before proceeding to operation 530. By waiting the predetermined amount of time, the method 500 allows time for changes to the resource availability to occur without necessarily actively checking that anything has changed in that regard. In other cases, the method 500 may actively check whether resource availability (as indicated by the repository 210) has changed before proceeding to operation 530.

At operation 530, performed by the service coordinator 240, the method 500 determines whether the respective precondition for any of the pending service implementation steps provided by the service designer 230 have been satisfied. If so, the method 500 proceeds to an operation 540. Otherwise the method 500 reiterates steps 520 and 530 until a precondition for a pending service implementation step is satisfied. Returning to the first example previously discussed above, for example, the service coordinator 240 may monitor the specific node to which the application is to be deployed (during operation 520) and determine (during operation 530) that the precondition for the service implementation step to deploy the application to the node is satisfied when the load of the node drops below a particular level such that the node has a sufficient amount of capacity available for the application to be deployed.

Similarly, returning to the second example previously discussed above, the service coordinator 240 may monitor the network for instances of the type of sensor (during operation 520) and determine (during operation 530) that the precondition for implementing the service implementation step is satisfied when an instance of the type of sensor becomes available for orchestration.

At operation 540, the method 500 generates a design for the implementation step (i.e. the implementation step whose precondition is now satisfied). That is to say, now that the precondition for implementation has been satisfied, the service coordinator 240 requests that the service designer 230 generates a configuration of resources 250 for implementing the portion of the service represented by the service implementation step. To do so, the service designer 230 refers to the repository 210 to identify a set of resources 250 that are suitable for implementing the portion of the service and determines an appropriate configuration of those resources 250 in order to implement the portion of the service to which the service implementation step relates. This configuration of resources 250 may be referred to as a design for the service implementation step. As part of generating the design, the service designer 230 generate scripts in order to implement the services. The scripts are generated such that, when they are processed by an appropriate entity, they will result in the orchestration of the resources 250 according to the design (i.e. it will configure the identified set of resources 250 in the determined manner).

In some cases, the scripts may be intended to be processed directly by the service coordinator 240. That is to say, the scripts represent the intended design in a way that enables the service coordinator 240 to determine how the resources 250 need to be configured in order to implement the service implementation step according to that design.

In other cases, the scripts may be intended to be processed by a managing entity, such as an orchestration system for the resources 250. Accordingly, each script may be expressed in a respective language that is appropriate for the entity by which it is to be processed. A set of rules may be specified to allow the service designer 230 to determine an appropriate language for generating each script. Where the resources 250 are managed by multiple different orchestration systems, as is the case for the composite service orchestrator 300 described above, a language in which each script is expressed may be different from one or more of the other generated scripts. Specifically, the language for each script may be one that can be processed by each orchestration system that is intended to process that script. Alternatively, where local software agents are present for each of the disparate orchestration systems 310 in the composite service orchestrator 300, the service designer 230 may utilise a form of intermediate scripting language that is understood by those software agents. The software agents may then receive the scripts in that intermediate scripting language and convert the script into one or more final scripts, each of the final scripts being expressed in a respective scripting language that is understood by each of the disparate orchestration systems with which they are associated. This approach can reduce the complexity for script generation within the service designer 230.

Returning to continue the first example previously discussed above, for example, the service designer 230 may generate a script to instruct the specific node to retrieve and install the particular application.

Similarly, returning to the second example previously discussed above, the service designer 230 may generate a script for an edge orchestration system to instruct the edge orchestration system to adopt the sensor, deploy a software adapter of the particular type, configure the adapter to connect to the specific cloud endpoint using the specified credentials and apply the certain security policy to the adapter. As will be appreciated from the preceding discussion, this could be broken down into several implementation steps each with their own precondition (e.g. the security policy could be applied to the adapter in a separate implementation step preconditioned on the deployment of the adapter whilst the connection to the cloud endpoint could be performed as another implementation step preconditioned on the successful application of the security policy).

Having generated the design for the implementation step, the method proceeds to an operation 550.

At operation 550, performed by the service coordinator 240, the method 500 orchestrates the resources 250 based on the generated design. That is to say, the method 500 causes the resources 250 required for implementing the portion of the service that is associated with the implementation step to be configured in the manner determined by the service designer 240. In some cases, operation 550 may involve the service coordinator 240 interpreting a script that was produced by the service designer 230 representing the design. Accordingly, the service coordinator 240 may use the script to determine what adjustments need to be made to the configuration of individual resources 250 in order to implement the portion of the service represented by the service implementation step.

In other cases, operation 550 may involve the service coordinator 240 providing one or more scripts that have been produced by the service designer 230 to one or more service orchestration systems (or software agents associated with those orchestration systems as in some embodiments of the composite service orchestrator 300). Those service orchestration systems (and/or agents) may then interpret the scripts and configure their respective resources in order to implement the portion of the service represented by the service implementation step.

Returning to continue the first example previously discussed above, for example, the service coordinator 240 may provide the script to the specific node (or an orchestration system deployed on that node) to cause the specific node to process the script and thereby install the particular application.

Similarly, returning to the second example previously discussed above, the service coordinator 240 may provide the script to the edge orchestration system to cause the edge orchestration system to process the script and thereby adopt the sensor, deploy the software adapter, apply the certain security policy to the adapter and cause the sensor to establish a connection to the specific cloud endpoint using the specified credentials.

Having orchestrated the resources 250 to implement the portion of the service associated with the implementation step, the method 500 proceeds to an optional operation 560, or if optional operation 560 is not present, to an optional operation 570, or, if optional operation is not present, to an operation 580.

At optional operation 560, the method 500 may generate additional implementation steps for implementing further portions of the service. As previously discussed, the service designer 230 need not specify all the necessary implementation steps at once and may instead store a record of partially handled service requests. Accordingly, at operation 560, the method 500 may determine whether all steps for implementing the service have already been defined and, if not, the service coordinator 240 may cause the service designer 230 to determine further implementation steps for implementing the service. Similarly, the service designer 230 may, during the design of the implementation for a service implementation step, decide to split the step into multiple service implementation steps. That is to say, the service designer 230 may define a configuration of resources to implement part of the portion of the service to which the current service implementation step relates and may generate additional service implementation steps relating to the rest of the portion of the service to which the current service implementation step. The current service implementation step may then be redefined as relating to just that part of the portion of the service which has been implemented. Once generated by the service designer 230, these additional implementation steps will be added to the repository of implementation steps for implementation in future iterations of method 500. Having caused the service designer 230 to generate additional implementation steps, the method 500 proceeds to an optional operation 570 or, if operation 570 is not present, to an operation 580.

At optional operation 570, performed by the service coordinator 240, the method 500 may monitor the implementation of the service implementation step in order to detect an implementation failure for that implementation service step. The implementation failures that are monitored for may be failures occurring during orchestration of the resources to implement the portion of the service represented by the implementation step, failures occurring after orchestration (e.g. during the live operation of the service being orchestrated), or both. For example, an implementation failure during orchestration could occur as a result of a resource changing status between the design of an implementation step and the orchestration of the resources (e.g. due to a failure of the resource or the use of the resource by another system external to the service orchestrator 200). Similarly, an implementation failure after orchestration could occur, for example, due to a hardware failure of the resource occurring after the service has been orchestrated.

It will be appreciated that this monitoring may be carried in parallel to (or at least substantially in parallel to) the method 500. That is to say, at operation 570, the method 500 may initiate the monitoring of the service implementation step and then continue with the method 500 by proceeding to operation 580. The monitoring of the implementation step may then be performed whilst further iterations of the method 500 are performed in respect of other implementation steps. For example, the method 500 may spawn a separate process to carry out the monitoring.

When a failure of an implementation step is detected, the monitoring process of the service coordinator 240 can attempt to mitigate or overcome the failure of that implementation step by causing the service designer 230 to redesign the implementation of that implementation step. In doing so, the service designer 230 may refer to the repository 210 to identify what resources 250 are currently available (i.e. at the time of the redesign after the failure has happened) and can determine a configuration of those resources that is suitable for implementing the portion of the service associated with that service implementation step. The service coordinator 240 may then orchestrate those resources in the new configuration, as determined by the service designer 230, in order to re-implement the service implementation step so as to overcome (or at least mitigate) the failure. As part of the re-implementation of a service implementation step, the service coordinator 240 may roll back the previous implementation of the service step so as to free up any resources that are no longer required for the new implementation of the service step.

In some cases, the new implementation of the service implementation step may make use of a different set of resources 250 including at least some resources 250 that were not included in the original implementation. In other cases, the new implementation may simply involve a re-configuration of the same set of resources as was used in the previous implementation. Either way, through the determination and orchestration of a different configuration of resources 250 to implement the portion of the service represented by the service implementation step, the service designer 230 and service coordinator 240 can overcome (or at least mitigate) the failure.

Due to the step-wise nature in which the service is orchestrated by the service orchestrator 200, any failures in implementation can be dealt with more efficiently. This is because individual implementation steps (representing discrete portions of the service) can be re-designed and re-orchestrated in response to any failures without needing to re-design and re-orchestrate the entire service.

Returning to continue the second example previously discussed above, if, for example, the implementation of the service of this example were broken down into several implementation steps in the manner previously suggested (such that the connection of the sensor to the cloud endpoint is its own implementation step), the service coordinator 240 may monitor the implementation of that service implementation step (i.e. the connection of the sensor to the cloud endpoint) to detect any implementation failures (e.g. a loss of connectivity between the sensor and the cloud endpoint). The service coordinator 240 may then request that the service designer 230 design a different implementation of this service step. The service designer 230 may then generate a different configuration resources to mitigate the issue. For example, the service designer 230 may make use of different network resources 250 to provide a different path for communication between the sensor and the cloud endpoint. In any case, having initiated the monitoring of the implementation step, the method 500 proceeds to operation 580.

At operation 580, the method 500 determines whether it should continue operating. That is to say, whether the method 500 should perform another iteration by returning to operation 510. In general, it is anticipated that method 500 will be performed continuously, such that it implements implementation steps as and when possible. For example, in such cases, the method 500 may return to operation 510 to wait for new implementation steps to be defined by the service designer 230. In such cases, the method 500 may determine to continue operating (at operation 580) until a stop signal is received. Of course, this isn’t necessary and in some cases the method 500 may be instantiated for the sole purpose of orchestrating the implementation steps associated with a single service orchestration request 260, in which case, once all implementation steps required to implement that service have been implemented, the method 500 may determine that it should stop.

As described above, the service orchestrator 200 of the present invention provides a flexible and efficient way of orchestrating a service that is well suited to more dynamic environments, such as those encountered when orchestrating services involving loT devices which may require orchestration of a very large number of resources across multiple locations (e.g. edge, core network and cloud) using multiple diverse orchestration systems (such as enabled by the composite service orchestrator 300). Through the step-wise implementation of the service and the use of trigger conditions to separately orchestrate individual parts of the service at appropriate times, the service orchestrator 200 can optimise resource usage by preventing reservation of resources until they are needed (e.g. until other portions of the service have been successfully orchestrated).

Insofar as embodiments of the invention described are implementable, at least in part, using a software-controlled programmable processing device, such as a microprocessor, digital signal processor or other processing device, data processing apparatus or system, it will be appreciated that a computer program for configuring a programmable device, apparatus or system to implement the foregoing described methods is envisaged as an aspect of the present invention. The computer program may be embodied as source code or undergo compilation for implementation on a processing device, apparatus or system or may be embodied as object code, for example. Suitably, the computer program is stored on a carrier medium in machine or device readable form, for example in solid-state memory, magnetic memory such as disk or tape, optically or magneto-optically readable memory such as compact disk or digital versatile disk etc., and the processing device utilises the program or a part thereof to configure it for operation. The computer program may be supplied from a remote source embodied in a communications medium such as an electronic signal, radio frequency carrier wave or optical carrier wave. Such carrier media are also envisaged as aspects of the present invention. It will be understood by those skilled in the art that, although the present invention has been described in relation to the above-described example embodiments, the invention is not limited thereto and that there are many possible variations and modifications which fall within the scope of the invention. The scope of the present invention includes any novel features or combination of features disclosed herein. The applicant hereby gives notice that new claims may be formulated to such features or combination of features during prosecution of this application or of any such further applications derived therefrom. In particular, with reference to the appended claims, features from dependent claims may be combined with those of the independent claims and features from respective independent claims may be combined in any appropriate manner and not merely in the specific combinations enumerated in the claims.

Claims

1 . A service orchestrator comprising: a repository for storing dynamic inventory information representing a plurality of resources that are available for orchestration by the service orchestrator; a service governor configured to accept a service orchestration request specifying a service to be implemented by the service orchestrator; a service designer configured to: determine one or more implementation steps for implementing the service, at least one of the implementation steps being associated with a respective precondition; monitor the repository to determine whether the respective precondition for each of the at least one implementation steps have been satisfied; and generate a respective configuration of resources from the plurality of resources for implementing each of the one or more implementation steps, wherein the respective configuration for each of the at least one implementation steps are generated in response to determining that the respective precondition for that implementation step have been satisfied; and a service coordinator for orchestrating the resources according to the configurations determined by the service designer.

2. The service orchestrator of claim 1 , wherein the service designer determines a plurality of implementation steps for implementing the service, each of the implementation steps for implementing a respective portion of the service.

3. The service orchestrator of claim 2, wherein each of the implementation steps is associated with a respective precondition.

4. The service orchestrator of any one of the preceding claims, wherein the respective precondition for one or more of the implementation steps is the availability of a specific resource or type of resource for orchestration.

5. The service orchestrator of any one of the preceding claims, wherein the service coordinator is configured to: monitor an implementation of each of the implementation steps to detect an implementation failure; and in response to detecting an implementation failure for a service implementation step, cause the service designer to determine a different configuration of resources for implementing that service implementation step; and orchestrate the resources according to the different configuration for that service implementation step.

6. The service orchestrator of claim 5, wherein the implementation failure comprises either or both of: a failure occurring during orchestration of the resources to implement the implementation step; and a failure occurring after the successful implementation of the implementation step.

7. The service orchestrator of any one of the preceding claims, wherein the service orchestrator is a composite service orchestrator for orchestrating services across a plurality of disparate orchestration systems, each of the disparate orchestration systems being associated with a respective set of resources that it is able to orchestrate, wherein: the repository is configured to receive updates on the resources available via each of the disparate orchestration systems such that the dynamic inventory information represents the resource availability across all of the disparate orchestration systems; the service designer is configured to use resources from at least two of the disparate orchestration systems to implement the service; and the service coordinator is configured to orchestrate the resources via the at least two disparate orchestration systems.

8. A method for orchestrating a service comprising: receiving a service orchestration request specifying a service to be implemented; determining one or more implementation steps for implementing the service, at least one of the implementation steps being associated with a respective precondition; monitoring a plurality of resources that are available for orchestration to determine whether the respective precondition for each of the at least one implementation steps have been satisfied; generating a respective configuration of resources from the plurality of resources for implementing each of the one or more implementation steps, wherein the respective configuration for each of the at least one implementation steps are generated in response to determining that the respective precondition for that implementation step have been satisfied; and orchestrating the resources according to the determined configurations.

9. The method of claim 8, wherein a plurality of implementation steps are determined, each of the implementation steps for implementing a respective portion of the service, optionally wherein each of the implementation steps is associated with a respective precondition.

10. The method of claim 8 or claim 9, wherein the respective precondition for one or more of the implementation steps is the availability of a specific resource or type of resource for orchestration.

11 . The method of any one of claims 8 to 10, further comprising: monitoring an implementation of each of the implementation steps to detect an implementation failure; and in response to detecting an implementation failure for an implementation step: determining a different configuration of resources for implementing that implementation step; and orchestrating the resources according to the different configuration for that service implementation step.

12. The method of claim 11 , wherein the implementation failure comprises either or both of: a failure occurring during orchestration of the resources to implement the implementation step; and a failure occurring after the successful implementation of the implementation step.

13. The method of any one of claims 8 to 12, further comprising: receiving updates on a respective set of resources associated with each of a plurality of disparate orchestration systems that are available via each disparate orchestration system, wherein: the implementation of the service uses resources from at least two of the disparate orchestration systems; and the resources are orchestrated via the at least two disparate orchestration systems.

14. A computer system comprising a processor and a memory storing computer program code for performing the method of any one of claims 8 to 13.

15. A computer program which, when executed by one or more processors causes the processors to carry out the method of any one of claims 8 to 13.