System and methods for auto-tuning elastic cloud native applications in production

Abstract

Methods and system to dynamically tune an application operating on a cloud computing infrastructure. The dynamic tuning generates a dependency graph based on the applications configurable parameters while operating on cloud computing infrastructure. One or more subgraphs are selected from the dependency graph which include a subset of the parameters of the dependency graph, and corresponding subgraph variations are created. The subgraphs and subgraph variants undergo a simulation used to identify a subset of the subgraphs with viable operation. This subset of subgraphs undergoes probabilistic modelling to generate a ranked set of configurations, which are then implemented in test replicas of the application and evaluated against the production replica. Once the test replicas are determined to outperform the production replica, they are implemented within the production replica.

Description

SYSTEM AND METHODS FOR AUTO-TUNING ELASTIC CLOUD NATIVE APPLICATIONS IN PRODUCTIONFIELD

[0001] The present application relates to systems and methods for auto-tuning elastic cloud native applications in production by identifying and optimizing parameter interdependencies.BACKGROUND

[0002] Cloud native applications have a vast number of possible configurable parameters while in operation over the cloud computing system, as they consist of multiple, small independent services that leverage cloud computing systems to increase efficiency, reduce cost and ensure availability. The vast number of configurable parameters require optimization for the efficient operations of the cloud native application.

[0003] Currently, the optimization of cloud native applications requires manual investigation of the possible configurable parameters, and their possible parametric and range interdependencies. This process is time consuming and prone to error owing to the large number of possible parametric configurations and relationships which have to be explored, resulting in less adequate performance and increased consumption of computing resources. Furthermore, the possible configurable parameters for the cloud native application are tested in a dedicated testing environment instead of in production. The lack of real time optimization while in production breeds further errors in optimization resulting in more inefficiencies.

[0004] As such, current approaches to optimizing cloud native applications cannot identify the critical configurable parameter per workload of the cloud native application automatically. Current approaches struggle to identify interdependencies of critical configuration parameters automatically parameter by parameter. As such, the current approaches to tuning and optimization of cloud native applications are time consuming, require manual oversight and are error prone.

[0005] BRIEF SUMMARY

[0006] In accordance with one aspect, the present application describes a computer-implemented method for dynamically configuring an application operating on a cloud computing infrastructure, the application having a set of configurable parameters. The method includes generating a dependency graph that maps dependencies between the parameters based on metrics for the application during operation on the cloud computing infrastructure, selecting at least one subgraph from the dependency graph, wherein the at least one subgraph includes a subset of the parameters in the dependency graph, creating one or more subgraph variants from the at least one subgraph by adding one or more parameters from the dependency graph that are not in the subset to the as least one subgraph or removing at least one parameter in the subset from the at least one subgraph, running a simulation for the at least one subgraph and each subgraph variant to generate respective probabilities of viable operation of the application and identifying a subset of the subgraphs based on their respective probabilities indicating viable operation, generating a ranked set of configurations by performing a Bayesian optimization on the subset of the subgraphs, implementing one of the ranked set of configurations using a test replica of the application to evaluate against one or more production replicas of the application operating on the cloud computing infrastructure; and determining that the one of the ranked set of configurations outperforms the one or more production replicas based on one or more performance metrics and, in response, implementing the one of the ranked set of configurations within the one or more production replicas of the application operating on the cloud infrastructure.

[0007] In some implementations, selecting the at least one subgraph includes selecting parameters linked by at least the N strongest dependency connections in the dependency graph.

[0008] In some cases, selecting the at least one subgraph includes pruning the dependency graph of a plurality of parameters on the basis that the plurality of parameters have the weakest dependencies.

[0009] In some implementations, creating one or more subgraph variants includes adding the one or more parameters from  the dependency graph through random selection of the one or more parameters or removing the at least one parameter based on random selection.

[0010] In some implementations, creating one or more subgraph variants includes adding the one or more parameters from the dependency graph based on the one or more parameters having a lowest strength connection with parameters in the subset of the parameters.

[0011] In some cases, creating one or more subgraph variants includes removing the at least one parameter based on random selection.

[0012] In some implementations, the simulation includes utilizing a counterfactual analysis algorithm to test for cause-and-effect relations between parameters.

[0013] In some cases, the probability of viable operation output from the simulation includes at least a fail result and a pass result.

[0014] In some implementations, creating the one or more subgraph variants includes, for at least one parameter in the subgraph variant, shrinking an associated parameter range.

[0015] In some cases, the method, further comprises, after implementation of the one of the ranked set of configurations within the one or more production replicas of the application, updating the dependency graph based on operation of the one or more production replicas.

[0016] In another aspect, there may be provided a computing system. The computing system may include a communication module and one or more processors coupled to the communication module. The computing system may include a memory coupled to the processor and storing processor-executable instructions which, when executed, configure the processor to carry out the operations of one or more of the methods described herein.

[0017] In another aspect, the present application describes a non-transitory computer-readable storage medium comprising computer-executable instructions which, when executed, configure a processor to carry out the operations of one or more of the methods described herein.

[0018] In a further aspect, the present application describes a computer program comprising instructions which, when executed by a computing device, are to cause the computing device to carry out of one or more of the methods described herein.

[0019] In yet a further aspect, the present application describes a computing device comprising means to perform the operations of one or more of the methods described herein.

[0020] Other aspects and features of the present application will be understood by those of ordinary skill in the art from a review of the following description of examples in conjunction with the accompanying figures.BRIEF DESCRIPTION OF THE DRAWINGS

[0021] Reference will now be made, by way of example, to the accompanying drawings in which:

[0022] FIG. 1 shows, in flowchart form, a simplified method for auto-tuning elastic cloud native applications in production;

[0023] FIG. 2 illustrates an example process of auto tuning a cloud application utilizing a dependency graph and search space partitioning;

[0024] FIG. 3 illustrates an example process of auto tuning a cloud application for multiple workloads utilizing a dependency graph and search space partitioning;

[0025] FIG. 4 shows, in flowchart form, one example method for generating a dependency graph and creating subgraphs which partition the search space;

[0026] FIG. 5 shows a flowchart of an example process for simulating the application based on dependency graph subgraphs and production replicas;

[0027] FIG. 6 shows a flowchart of an example process for identifying subgraph and subgraph variants with viable operations;

[0028] FIG. 7 shows, in flowchart form, one example method for creating subgraph variants based on multiple criteria;

[0029] FIG. 8 shows, in block diagram form, one simplified example of a computing device; and

[0030] FIG. 9 shows a simplified organization of software components stored in memory of the example computing device.

[0031] Like reference numerals are used in the drawings to denote like elements and features.DETAILED DESCRIPTION

[0032] Reference will first be made to FIG. 1, which shows, in flowchart form, a simplified method for auto-tuning elastic cloud native applications in production 100. In operation 110, a dependency graph of the configurable parameters of a cloud native application is generated. The dependency graph maps relationships between the parameters, performance metrics and workloads of the cloud native application while operating on the cloud computing infrastructure and is generated using an inference algorithm, such as do-calculus or Peter-Clark algorithm. The inference algorithm identifies the current workload of the cloud native application while in operation and tracks all configuration and application metrics related to the cloud native application from which the dependency graph is generated. In other words, the dependency graph is generated from the initial search space of the cloud native application.

[0033] In operation 120, a subgraph from the dependency graph is selected and subgraph variants based on the initial subgraph are created. The subgraph selected from the dependency graph includes a subset of the parameters in the dependency graph. In other words, the selection of the subgraph includes search space partitioning. In one example, the included subset of the parameters in the dependency graph are included based on a parameter criteria. In some embodiments, one or more subgraphs are selected. The subgraph variants are versions of the subgraph which have had the subset of the parameters in the dependency graph altered. In one example, the subset of the parameters in the dependency graph may be altered by adding one or more parameters from the dependency graph that are not in the subset of the parameters or removing at least one parameter in the subset from the at least one subgraph. In one example, the subset of the parameters in the dependency graph may be altered by adjusting the associated parameter range of one or more parameters in the subset of the parameters in the dependency graph.

[0034] In operation 130, the subgraph and subgraph variants are run through a simulation to identify a ranked set of viable configurations for the configurable parameters of the cloud native application. The simulation of the subgraph and subgraph variants generates respective probabilities of viable operation of the application. In one example, the simulation utilizes a counterfactual analysis algorithm or what-if analysis algorithm to test for cause-and-effect relations between parameters. In one example, the probability of viable operation output from the simulation includes at least a fail result and a pass result. Based on the respective probabilities indicating viable operation of the application, identify a subset of the subgraphs which may include the initial subgraph and subgraph variants. In some embodiments, the subset of subgraphs may only include subgraph variants with probabilities indicating viable operation as the initial subgraph may not have a respective probability indicating viable operation, The identification of the subset of the subgraphs allows for the coverage of the search space, or in other words, allows for the exploration of a large number of possible configurations and their respective viability. A ranked set of viable configurations is generated by performing probabilistic models on the subset of the subgraphs. In one example, the probabilistic models could include Gaussian process, Tree Parzen Estimators, Bayesian optimization or other such models. The use of probabilistic models utilizes the large number of possible configurations and their respective viability identified as part of the subset of the subgraphs to search for the best possible configuration for viability. In some embodiments, the ranked set of viable configurations is generated based on the respective probabilities indicating viable operation for a subset of the subgraphs. In some cases, the respective probabilities indicating viable operation may take the form of a viability score which ranges from 1 to 100 for each viable configuration, and the ranked set of configurations are generated based on the viability score.

[0035] The configurable parameters are the various different possible parameters of the various different microservices which are configurable to allow for the operation of the cloud native application on the cloud computing system. These configurable parameters can be related to processor usage, memory usage, memory storage, memory limit, server usage, or any other element of the various microservices forming the architecture of the cloud native application, which when altered, can alter the operations of the microservice associated with the configurable parameter, which alters the operations of the cloud native application. For example, a cloud native application may consist of three different microservices, microservice A, microservice B, and microservice C, which operate together on the cloud computer system to allow for the operation of the cloud native application. Example configurable parameters for this example could include thread pool size for microservice A, garbage collection for microservice B and memory limit for microservice C. These configurable parameters have some value associated with them which is alterable. For example, memory limit for microservice C may have a value range from 0 to 50. In some cases, these configurable parameters are independent parameters and are not affected by the values and inclusion of other configurable parameters while in other cases they are dependent parameters which are affected by the values and inclusion of other configurable parameters.

[0036] In operation 140, the ranked set of viable configurations are evaluated by implementing a test replica of the cloud native application running one of the ranked set of viable configurations against a production replica of the cloud native application running on the cloud computing infrastructure.

[0037] In operation 150, a determination is made regarding whether the test replica of the cloud native application running one of the ranked set of viable configurations outperforms the production replica of the cloud native application based on a performance metric. In some cases, the determination is based on one or more performance metrics. In some embodiments, if one of the ranked set of viable configurations does not outperform the production replica of the cloud native application based on one or more performance metrics, the configuration is discarded.

[0038] Operation 160 results in the implementation of one of the ranked set of the configurations within the production replica of the cloud native application once it is determined that the one of the ranked set of configurations outperforms the production replica of the cloud native application.

[0039] Cloud native applications often have a vast number of possible configuration parameters. Identifying the most critical configuration for the parameters and their associated parameter ranges that significantly impact performance, resource consumption or other vital performance metrics is challenging. Current approaches struggle with recognizing the critical configuration parameters per workload automatically for a cloud native application operating on cloud computing infrastructure. Furthermore, they struggle with optimizing the parameters and their associated parameter ranges and identifying the critical interdependency between the parameters,

[0040] The example method described above allows for the identification of critical configurations per workload for the parameters and their associated parameter ranges while the cloud native application operates on the cloud computing infrastructure. Furthermore, it allows for the recognition of the critical interdependencies of parameters and their associated parameter ranges per fluctuating workload in production.

[0041] FIG. 2 diagrammatically illustrates an example method of auto tuning a cloud application utilizing a dependency graph and search space partitioning 200. The dependency graph 202 is similar to the dependency graph generated in operation 110. The dependency graph 202 maps out the interdependencies of the configurable parameters of the application. The dependency graph 202 is generated using inference algorithms, such as do-calculus or Peter-Clark algorithm, which identifies the current workload of the cloud native application while in operation and tracks all configurable parameters and metrics related to the cloud native application from which the dependency graph is generated. As such, the dependency graph 202 is based of the initial search space for the application.

[0042] To allow for the exploration of the interdependencies of the configurable parameters and their associated parametric ranges for the application, the dependency graph 202 based on the initial search space undergoes search space partitioning  204. Search space partitioning 204 includes selecting at least one subgraph from the dependency graph 202 which include a subset of the configurable parameters in the dependency graph. In an example, selecting at least one subgraph from the dependency graph 202 is based on a criterion of the configurable parameters. In some cases, the criteria of the configurable parameters used to select at least one subgraph may include choosing configurable parameters which have the strongest interdependencies between each of the other configurable parameters. In some cases, the criteria of the configurable parameters used to select at least one subgraph may include pruning the dependency graph 202 of a plurality of configurable parameters on the basis that the plurality of configurable parameters have the weakest dependencies. In some cases, the criteria of the configurable parameters used to select at least one subgraph may include selecting configurable parameters from the dependency graph 202 which have the strongest interdependence with one or more performance metrics such as memory usage, server usage, or any other performance metric of the cloud native application.

[0043] The selected at least one subgraph from the dependency graph 202 undergoes what-if analysis 206 which allows for the further exploration of the interdependencies of configurable parameters from the dependency graph 202. The what-if analysis 206 includes generating variations of the search space partitioning 204, by creating subgraph variations by altering the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of replacing at least one configurable parameter in the subset of the configurable parameters with at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of adding at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of deleting at least one configurable parameter in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of altering the parameter range associated with at least one configurable parameter in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of a combination of replacing at least one configurable parameter in the subset of the configurable parameters with at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters, adding at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters, deleting at least one configurable parameter in the subset of the configurable parameters and altering the parameter range associated with at least one configurable parameter in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of altering the subset of the configurable parameters in some other manner.

[0044] By simulating and analysing the at least one subgraph with its subset of configurable parameters and subgraph variations and their respective altered subset of the configurable parameters as part of the what-if analysis 206, their respective probabilities of viable operation of the application are generated. Based on the respective probabilities of viable operation, at least one subset of subgraphs is identified which may include one or more of the at least one subgraph and the subgraph variations with viable configurations. Subgraph A 210 is a subgraph with a viable configuration included in the at least one subset of subgraphs. Subgraph N 212 is another subgraph with a viable configuration included in the at least one subset of subgraphs. In some examples, there could be possibly more subgraphs with viable configurations which are included in the at least one subset of subgraphs.

[0045] Subgraph A 210 and subgraph N 212, which are the subgraphs with viable configurations included in the subset of subgraphs, have probabilistic modelling 208 performed on them to calculate the likelihood of improvements for the application based on one or more performance metric. In some examples, the probabilistic modelling 208 is in the form of Bayesian optimization, Gaussian process, Tree Parzen Estimators or other probabilistic modelling algorithms.

[0046] The subset of subgraphs with viable configurations undergo ranking 214 based on the output of probabilistic modelling 208 which calculates the likelihood of improvements for the application based on one or more performance metric. Probabilistic modeling 208 may include implementing models such as Gaussian process, Tree Parzen Estimators, Bayesian optimization or other such models. The use of probabilistic modeling 208 may utilize the large number of possible  configurations and their respective viability identified as part of the subset of the subgraphs to search for the best possible configuration for viability. In some embodiments, the ranked set of viable configurations is generated based on the respective probabilities indicating viable operation for subset of the subgraphs. In some cases, the respective probabilities indicating viable operation may take the form of a viability score which ranges from 1 to 100 for each viable configuration, and ranked set of configurations are generated based on the viability score. Ranking 214 the subgraphs with viable configuration leads to a generation of a ranked set of configurations.

[0047] Exploration 216 consists of implementing the ranked set of configurations generated from ranking 214 in at least one test replica 218 of the application, and evaluating the performance of the test replica 218 based on one or more performance metrics against one or more production replicas 220. In one embodiment, the top ranked configuration from the ranked set of configurations is implemented in one test replica 218 and is evaluated against one or more production replicas 220. In one embodiment, two or more top ranked configurations from the ranked set of configurations are implemented in corresponding two or more test replicas 218 and are evaluated against one or more production replicas 220. In one embodiment, one or more configurations are randomly selected from the ranked set of configurations which are implemented in corresponding test replicas 218 and are evaluated against one or more production replicas 220. In one embodiment, the ranked set of configurations are serially implemented in corresponding multiple test replicas 218 starting from the top ranked configuration and are evaluated against one or more production replicas 220, with the serial implementation and evaluation of ranked set of configurations terminating if after a set number of configurations none of them are found to outperform the one or more production replicas 220.

[0048] If the at least one test replica 218 outperforms the production replicas 220 based on the one or more performance metrics, the ranked set of configurations implemented in at least one test replica 218 are implemented in the production replica. In one example, the test replica 218 may be implemented in production if it outperforms at least one of the production replicas 220. In another example, the test replica 218 may be implemented in production if it outperforms an average of the production replicas 220. In yet another example, the test replica 218 may be implemented in production if it outperforms all of the production replicas 220. Furthermore, the dependency graph 202 is updated based on the interdependencies of the configurable parameters learned from the ranked set of configurations.

[0049] FIG. 3 diagrammatically illustrates an example method of auto tuning a cloud application for multiple workloads utilizing a dependency graph and search space partitioning 300. FIG. 3 incorporates the illustrated process for FIG. 2 for the use of a cloud native application with multiple workloads.

[0050] The workload classifier 302 distinguishes and categorizes the different workloads undergone by the cloud native application on the cloud computing infrastructure while in production based on a time interval and one or more application metrics. As the different workloads may place varying demands on the cloud native application and the cloud computing infrastructure in production, the configurable parameters and / or their interdependencies or the strength and characteristics of those interdependencies may vary between the different workloads. This results in different workloads possibly having different critical configurable parameters, possibly having different interdependencies between the critical configurable parameters and possibly having different interdependencies for the parameter ranges associated with critical configurable parameters.

[0051] The varying demands of the different workloads while the cloud native application is in production and the associated varying configurable parameters may lead to a different dependency graph 304 for each different workload. In some examples, the dependency graph 304 may be unique per each workload as classified by the workload classifier 302. Workload A 306, Workload B 308 and Workload C 310 represent three different unique dependency graphs for each workload. In some cases, there may be more workloads and associated unique dependency graphs 304 or there may be less workloads and associated unique dependency graph with a minimum of one. The different dependency graphs 304 for each workload are based of the initial search space for the application per workload. The subsequent steps of the method are all applied per each different workload and associated dependency graph. For example, the subsequent steps will be completed for each Workload A 306,  Workload B 308 and Workload C 310.

[0052] Each different dependency graph such as Workload A 306, Workload B 308 and Workload C 310 undergo search space partitioning 312 by having at least one subgraph selected from each dependency graph 304 which include a subset of the configurable parameters in each different dependency graph associated with a workload. As only one of the workloads is active at a given time, the dependency graph being tuned while in production will correspond to the active workload. For example, if the cloud native application is in workload A 306 while in production, the dependency graph utilized for the tuning of the cloud native application will correspond to Workload A 306. In this example, once the cloud native application enters Workload B 308, exclusively the corresponding dependency graph for Workload B will be utilized for the tuning of the application. In an example, selecting at least one subgraph from each different dependency graph associated with a workload is based on a criterion. In some cases, the criteria of the configurable parameters used to select at least one subgraph may include choosing configurable parameters which have the strongest interdependencies between each of the other configurable parameters. In some cases, the criteria of the configurable parameters used to select at least one subgraph may include pruning the dependency graph 304 of a plurality of configurable parameters on the basis that the plurality of configurable parameters have the weakest dependencies. In some cases, the criteria of the configurable parameters used to select at least one subgraph may include selecting configurable parameters from the dependency graph 304 which have the strongest interdependence with one or more performance metrics such as memory usage, server usage, or any other performance metric of the cloud native application.

[0053] What-if analysis 314 consists of creating subgraph variants for the at least one subgraph per each workload and dependency graph by altering the subset of the configurable parameters included in the initial subgraph. In some cases, altering the subset of the configurable parameters could take the form of replacing at least one configurable parameter in the subset of the configurable parameters with at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of adding at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of deleting at least one configurable parameter in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of altering the parameter range associated with at least one configurable parameter in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of a combination of replacing at least one configurable parameter in the subset of the configurable parameters with at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters, adding at least one configurable parameter from the dependency graph not included in the subset of the configurable parameters, deleting at least one configurable parameter in the subset of the configurable parameters and altering the parameter range associated with at least one configurable parameter in the subset of the configurable parameters. In some cases, altering the subset of the configurable parameters could take the form of altering the subset of the configurable parameters in some other manner.

[0054] The respective probabilities of viable operation of the cloud native application are generated for each subgraph and subgraph variant per each workload and associated dependency graph by running a counterfactual analysis simulation as part of the what-if analysis 314. Based on the respective probabilities of viable operation for the cloud native application, at least one subset of subgraphs is identified which may include one or more of the at least one subgraph and the subgraph variations with viable configurations per each workload and associated dependency graph. Subgraph A 318 is a subgraph from the at least one subset of subgraphs with a viable configuration. Subgraph N 320 is another subgraph from the at least one subset of subgraphs with a viable configuration. In some embodiments, there are multiple subgraphs from the at least subset of subgraphs which are identified beyond just subgraph A 318 and subgraph N 320.

[0055] Subgraph A 318 and subgraph N 320, which are the subgraphs with viable configurations from the subset of subgraphs, have probabilistic modelling 316 performed on them to calculate the likelihood of improvements for the application based on one or more performance metric. The probabilistic modelling is performed for each of the subgraphs in the at least  one of the subset of subgraphs. In some examples, the probabilistic modelling 316 is in the form of Bayesian optimization, Gaussian process, Tree Parzen Estimators or other probabilistic modelling algorithms. Probabilistic modeling 316 may include implementing models such as Gaussian process, Tree Parzen Estimators, Bayesian optimization or other such models. The use of probabilistic modeling 208 may utilize the large number of possible configurations and their respective viability identified as part of the subset of the subgraphs to search for the best possible configuration for viability. In some embodiments, the ranked set of viable configurations is generated based on the respective probabilities indicating viable operation for subset of the subgraphs. In some cases, the respective probabilities indicating viable operation may take the form of a viability score which ranges from 1 to 100 for each viable configuration, and ranked set of configurations are generated based on the viability score.

[0056] The subgraphs with viable configurations undergo ranking 322 based on the output of probabilistic modelling 316 which calculates the likelihood of improvements for the application based on one or more performance metric per each workload and associated dependency graph. Ranking 322 the subgraphs with viable configuration leads to a generation of a ranked set of configurations per each workload and associated dependency graph.

[0057] Exploration 324 consists of implementing the ranked set of configurations generated from ranking 322 in at least one test replica 326 of the application, and evaluating the performance of the test replica 326 based on one or more performance metrics against one or more production replicas 328 per each workload and associated dependency graph.

[0058] If the at least one test replica 326 outperforms the one or more production replicas 328 based on the one or more performance metrics, the ranked set of configurations implemented in at least one test replica 326 are implemented in the production replica per each workload and associated dependency graph. Furthermore, each dependency graph 304 associated with a different workload is updated based on the interdependencies of the configurable parameters learned from the ranked set of configurations.

[0059] Reference will now be made to FIG. 4, which shows, in flowchart form, one example method 400 for generating a dependency graph and creating subgraphs which partition the search space. In operation 410, the cloud native application running on the cloud computing infrastructure provides a set of configurable parameters. In some examples, the configurable parameters are different based on the different workloads of the cloud native application.

[0060] Operation 420 results in the generation of a dependency graph that maps dependencies between the configurable parameters based on the metrics for the cloud native application during operations on the cloud computing infrastructure. In some cases, multiple dependency graphs are generated. In some cases, one or more dependency graphs are generated per each workload of the cloud native application.

[0061] In operation 430, at least one subgraph from the dependency graph is selected which includes a subset of the parameters in the dependency graph based on a criteria. In some cases, the criteria used to select a subset of parameters includes selecting parameters linked by at least the N strongest dependency connections in the dependency graph. In some cases, the criteria used to select a subset of parameters includes pruning the dependency graph of a plurality of parameters on the basis that the plurality of parameters have the weakest dependencies. In some cases, the criteria used to select a subset of parameters includes randomly selecting a plurality of parameters from the dependency graph. In some cases, the criteria used to select a subset of parameters from the dependency graph which have the strongest impact on a one or more performance metric of the cloud native application, such as memory usage, interval time, server usage, or some other metric. In some cases, the criteria used to select a subset of parameters includes a combination of the previously mentioned criteria are utilized. In some cases, other parametric criteria are used to select a subset of parameters. In some cases, multiple criteria are used to select multiple subsets of parameters for multiple subgraphs. In some cases, at least one subgraph from each dependency graph per workload is selected.

[0062] Operation 440 consists of creating one or more subgraph variants from the at least one subgraph by adding one or more parameters from the dependency graph that are not in the subset of the parameters in the dependency graph or removing at least one parameter in the subset from the at least one subgraph based on a criteria. In some cases, the criteria to remove or  add a parameter to the subset from the at least one subgraph may include random selection, selection based on parameter strength connection, or some other criteria. In some cases, creating one or more subgraph variants includes altering one or more parameters in the subset of parameters from the dependency graph. In some cases, altering one or more parameters in the subset of the parameters, includes replacing one or more of the parameters in the subset of the parameters with one or more parameters from the dependency graph which were not included in the subset of the parameters. In some cases, altering the parameters may be based on the configurable parameter originating from a specific microservice which forms the cloud native application. For example, in one case configurable parameters originating from a specific companies microservice focused on server to device communication which forms part of the cloud native application’s infrastructure may exclusively be altered.

[0063] In an example, altering one or more parameters includes altering the values of the parameters by either reducing the value or increasing the value in a given range based on the parameters having the strongest dependency on one or more performance metrics. In this example, the performance metrics may include memory usage, server usage, iteration interval or workload type among other metrics. In an example, altering one or more parameters includes altering the values of the parameters by either reducing the value or increasing the value in a given range based on the parameters having the weakest dependency on one or more performance metrics.

[0064] FIG. 5 shows a flowchart of an example process 500 for simulating the application based on dependency graph subgraphs and production replicas.

[0065] In operation 510, one or more subgraphs and each subgraph variant is run through a simulation which generates respective probabilities of viable operation of the cloud native application while in operation for the one or more subgraphs and each subgraph variant. In some cases, the simulation consists of counterfactual analysis to test for cause-and-effect relations between parameters which assesses the viability of the cloud native application when utilizing the configuration of the parameters included in the one or more subgraphs and each subgraph variant. In some cases, the probability of viable operation output from the simulation includes at least a fail result and a pass result.

[0066] Following the output of the respective probabilities of viable operation, a subset of subgraphs which includes the one or more subgraphs and each subgraph variant which indicate viable operation of the cloud native application is identified as part of operation 520. Operation 530 performs Bayesian optimization on the subset of the subgraphs to generate a ranked set of configurations. In some embodiments, instead of Bayesian optimization, probabilistic models such as Gaussian process, Tree Parzen Estimators or other probabilistic models are performed on the subset of the subgraphs to generate a ranked set of configurations. The probabilistic models may utilize the large number of possible configurations and their respective viability identified as part of the subset of the subgraphs to search for the best possible configuration for viability. In some embodiments, the ranked set of viable configurations is generated based on the respective probabilities indicating viable operation for subset of the subgraphs. In some cases, the respective probabilities indicating viable operation may take the form of a viability score which ranges from 1 to 100 for each viable configuration, and ranked set of configurations are generated based on the viability score.

[0067] In operation 540, one of the ranked set of configurations is implemented in a test replica of the cloud native application to evaluate against one or more production replicas of the cloud native application operating on the cloud computing infrastructure. The evaluation of the test replica against the production replicas is based on one or more production metrics of the cloud native application. In some embodiments, the evaluation results in a value score being given to each test replica from a set range for each production metric used in the evaluation. In some embodiments, an overall value score is provided for each test replica which is an aggregate of the value scores for each production metric. In some examples, the overall value score is provided based on a priority set for each production metric involved in the evaluation of the test replica. In some cases, the one or more production metrics of the cloud native application differ based on each different workload of the cloud native application. In some cases, multiple test replicas of the cloud native application which implement more than one of the ranked set of configurations are used in the evaluation.

[0068] Based on the evaluation of the test replicas of the cloud native application against one or more production replicas  of the cloud native application, operation 550 requires determination of whether the test replica outperforms the or more production replicas based on one or more performance metrics. Once determined, operation 560 calls for the implementation of the one of the ranked set of configurations within the one or more productions replicas of the application operating on the cloud infrastructure. In some cases, for each different workload the ranked set of configurations may differ.

[0069] In operation 570, the dependency graph is updated based on the operation of the one or more production replicas which has had one of the ranked set of configurations implemented.

[0070] Reference is now made to FIG. 6, which shows another example process for identifying subgraph and subgraph variants with viable operations.

[0071] In operation 610, a simulation is run for at least one subgraph and each subgraph variant from a dependency graph for a cloud native application utilizing a counterfactual analysis algorithm to test for cause-and-effect relations between parameters.

[0072] In operation 620, the output of the simulation generates respective probabilities of viable operation of the cloud native application which provides an output in the form of a fail result and a pass result. In some cases, the respective probabilities of viable operation are provided in the form of a scale of probable viability. In some cases, the respective probability of viable operation is broken down into multiple different value scores based on different performance, which are all provided in the form of a scale of probable viability.

[0073] In operation 630, a subset of the subgraphs based on their respective probabilities indicating viable operation based on a pass result is identified. In some cases, the indication of viable operation is based on passing a certain threshold on a scale of probable viability. In some cases, multiple thresholds need to be passed to indicate probable viability with each threshold corresponding to a different performance metric of the cloud native application.

[0074] Reference is now made to FIG. 7, which shows, in flowchart form, one example method for creating subgraph variants based on multiple criteria.

[0075] Operation 710 calls for the generation of a dependency graph for a cloud native application and the selection of at least one subgraph from the dependency graph which includes a subset of the configurable parameters in the dependency graph. Based on the selected at least one subgraph, one or more subgraph variants are created from the subgraph according to operation 720 based on one or more procedures which include but are not limited to the procedures provided in operation 730, operation 740, operation 750 and operation 760. Creating subgraphs consists of altering the subset of configurable parameters in the at least one subgraph based on the one or more procedures. In some cases, multiple procedures are utilized to create one or more of the subgraph variants, including but not limited to the ones provided in operation 730, operation 740, operation 750 and operation 760. In some cases, only a singular procedure is used to create one or more subgraph variants. In some cases, different procedures are used per different workload of the cloud native application.

[0076] In some examples, one or more of the procedures provided in operation 730, operation 740, operation 750 and operation 760 are used for at least one subgraph to create subgraph variants. In some cases, different procedures, which include but are not limited to operation 730, operation 740, operation 750 and operation 760, are utilized per different subgraphs to create subgraph variants.

[0077] In operation 730, one or more configurable parameters, which are not included in the subset of the configurable parameters in the one or more subgraph, are added from the dependency graph through random selection. The one or more configurable parameters are added to the subset of the configurable parameters to create one or more subgraph variants after being randomly selected. In one embodiment, one or more of the configurable parameters from the dependency graph may be restricted from being considered in the random selection based on the one or more configurable parameter having a dependency value of above X with the configurable parameters from the subset of the configurable parameters. In some cases, the one or more of the configurable parameters from the dependency graph may be restricted from being considered in the random selection based on the one or more configurable parameter having a dependency on one or more performance metric of the  cloud native application.

[0078] In operation 740, one or more configurable parameters, which are not included in the subset of the configurable parameters in the one or more subgraph, are added from the dependency graph to the subset of the configurable parameters in the dependency graph of the at least one subgraph based on the one or more configurable parameters having a lowest strength connection with configurable parameters in the subset of the configurable parameters to create one or more subgraph variants.

[0079] In operation 750, one or more configurable parameters from the subset of the configurable parameters are removed from the one or more subgraphs through random selection of the one or more configurable parameters from the subset of the configurable parameters of the at least one subgraph to create one or more subgraph variants. In some cases, based on the one or more configurable parameters having a lowest strength connection with configurable parameters in the subset of the configurable parameters, from the subset of the configurable parameters in the dependency graph of the at least one subgraph to create one or more subgraph variants. In some cases, one or more configurable parameters from the subset of the configurable parameters may be removed based on the one or more configurable parameter originating from a specific microservice which forms the cloud native application. For example, in one case configurable parameters originating from a specific companies microservice focused on device memory usage which forms part of the cloud native application’s infrastructure may exclusively be altered. In an example, one or more configurable parameters from the subset of the configurable parameters may be removed based on the on or more configurable parameters having the strongest dependency on one or more performance metrics. In this example, the performance metrics may include memory usage, server usage, iteration interval or workload type among other metrics.

[0080] In operation 760, the associated parameter range for at least one configurable parameter from the subset of the configurable parameters is shrunk to create one or more subgraph variants. In some cases, the associated parameter range for at least one configurable parameter from the subset of the configurable parameters is expanded to create one or more subgraph variants. In some cases, the associated parameter range for at least one configurable parameter from the subset of the configurable parameters is adjusted or fixed to create one or more subgraph variants. In some examples, the associated parameter range for at least one configurable parameter from the subset of the configurable parameters is shrunk, expanded, adjusted or fixed through random selection of the at least one configurable parameter. In some examples, the associated parameter range for at least one configurable parameter from the subset of the configurable parameters is shrunk, expanded, adjusted or fixed based on the at least one configurable parameter having a lowest strength connection with configurable parameters in the subset of the configurable parameters.

[0081] Once the subgraph variants have been created, operation 770 calls for the at least one subgraph and subgraph variants to be run and evaluated in a simulation.

[0082] Reference will now be made to FIG. 8, which shows a high-level diagram of an example computing device 800. The example computing device 800 includes a variety of modules. For example, the example computing device 800 may include a processor 810, a memory 820, and a communication module 830. As illustrated, the foregoing example modules of the example computing device 800 are in communication over a bus 840.

[0083] The processor 810 in this example is a hardware processor. In some cases, the processor 810 may include two or more processing units.

[0084] The memory 820 allows data to be stored and retrieved. The memory 820 may include, for example, random access memory, read-only memory, and persistent storage. Persistent storage may be, for example, flash memory, a solid-state drive or the like. Read-only memory and persistent storage are a computer-readable medium. A computer-readable medium may be organized using a file system such as may be administered by a operating system governing overall operation of the example computing device 800.

[0085] The communications module 830 allows the example computing device 800 to communicate with other electronic devices and / or various communications networks. For example, the communications module 830 may allow the example  computing device 800 to send or receive communications signals. As an example, the communication module 830 may include a network connection, data port, or the like. Communications signals may be sent or received according to one or more protocols or according to one or more standards. For example, the communications module 830 may allow the example computing device 800 to communicate via a cellular data network, such as for example, according to one or more standards such as, for example, Global System for Mobile Communications (GSM) , Code Division Multiple Access (CDMA) , Evolution Data Optimized (EVDO) , Long-term Evolution (LTE) , 5G, 6G, or the like. Additionally, or alternatively, the communications module 830 may allow the example computing device 800 to communicate using near-field communication (NFC) , via Wi-Fi (TM) , via the Ethernet family of network protocols, using Bluetooth (TM) or via some combination of one or more networks or protocols. In some embodiments, all or a portion of the communications module 830 may be integrated into a component of the example computing device 800. In some examples, the communications module may be integrated into a communications chipset.

[0086] Software instructions are executed by the processor 810 from a computer-readable medium. For example, software may be loaded into random-access memory from persistent storage within memory 820. Additionally, or alternatively, instructions may be executed by the processor 810 directly from read-only memory of the memory 820.

[0087] FIG. 9 depicts a simplified organization of software components stored in memory 820 of the example computing device 800. As illustrated, these software components include, at least, cloud native application software 910 and a cloud computing software 900.

[0088] The cloud native application software 910 adapts the example computing device 800, in combination with the operating software 900, to operate as a device performing a particular function. While a single cloud native application software 910 is illustrated in FIG. 9, in operation, the memory 820 may include more than one cloud native application software program and different cloud native application software programs may perform different operations. Cloud native application software 910 are usually associated and communicate with a cloud computing system, borrowing computing software and resources from the cloud computing system, which can be in a remote location, and allowing for the operation on the local computing system.

[0089] The operating software 900 is software. The operating software 900 allows the cloud native application software 910 to access the processor 810, the memory 820, and the communications module 830. The operating software 900 may, for example, be iOSTM, AndroidTM, LinuxTM, Microsoft WindowsTM, or the like. Many of the operations, methods, or processes described herein may be implemented within the operating software 900.

[0090] The cloud native application software 910 and / or operating software 900 may, when executed, cause the processor 810 to carry out operations to implement at least some portion of one or more of the methods described herein.

[0091] In the present disclosure, the terms “a” , “an” and “one” are defined to mean “at least one” , that is, these terms do not exclude a plural number of items, unless stated otherwise.

[0092] In the present disclosure, terms such as “substantially” , “generally” and “about” , which modify a value, condition or characteristic of a feature of an embodiment, should be understood to mean that the value, condition or characteristic is defined within tolerances that are acceptable for the proper operation of this embodiment for its intended application.

[0093] In the present disclosure, unless stated otherwise, the terms “connected” and “coupled” , and derivatives and variants thereof, refer herein to any structural or functional connection or coupling, either direct or indirect, between two or more elements. For example, the connection or coupling between the elements can be acoustical, mechanical, optical, electrical, thermal, logical, or any combinations thereof.

[0094] In the present disclosure, expressions such as “match” , “matching” and “matched” , including variants and derivatives thereof, are intended to refer herein to a condition in which two or more elements are either the same or within some predetermined tolerance of each other. That is, these terms are meant to encompass not only “exactly” or “identically” matching  the two elements but also “substantially” , “approximately” or “subjectively” matching the two or more elements, as well as providing a higher or best match among a plurality of matching possibilities.

[0095] In the present disclosure, the expression “based on” is intended to mean “based at least partly on” , that is, this expression can mean “based solely on” or “based partially on” , and so should not be interpreted in a limited manner. More particularly, the expression “based on” could also be understood as meaning “depending on” , “representative of” , “indicative of” , “associated with” or similar expressions.

[0096] In the present disclosure, the terms "system" and "network" may be used interchangeably in embodiments of this application. "At least one" means one or more, and "a plurality of" means two or more. The term "and / or" describes an association relationship of associated objects and indicates that three relationships may exist. For example, A and / or B may indicate the following three cases: Only A exists, both A and B exist, and only B exists, where A and B may be singular or plural. The character " / " usually indicates an "or" relationship between associated objects. "At least one of the following items (pieces) " or a similar expression thereof indicates any combination of these items, including a single item (piece) or any combination of a plurality of items (pieces) . For example, "at least one of A, B, or C" includes A, B, C, A and B, A and C, B and C, or A, B, and C, and "at least one of A, B, and C" may also be understood as including A, B, C, A and B, A and C, B and C, or A, B, and C. In addition, unless otherwise specified, ordinal numbers such as "first" and "second" in embodiments of this application are used to distinguish between a plurality of objects, and are not used to limit a sequence, a time sequence, priorities, or importance of the plurality of objects.

[0097] In the present application, the phrase “at least one of…or…” is intended to cover any one or more of the listed elements, including any one of the listed elements alone, any sub-combination, or all of the elements, without necessarily excluding any additional elements, and without necessarily requiring all of the elements. The term “and / or” is intended to indicate that either of the two elements may be included or both of the elements may be included.

[0098] A person skilled in the art will understand that embodiments of this application may be provided as a method, an apparatus (or system) , a computer-readable storage medium, or a computer program product. Therefore, this application may use a form of a hardware-only embodiment, a software-only embodiment, or an embodiment with a combination of software and hardware. Moreover, this application may use a form of a computer program product that is implemented on one or more computer-usable storage media (including but not limited to a disk memory, an optical memory, and the like) that include computer-usable program code.

[0099] This application is described with reference to the flowcharts and / or block diagrams of the method, the device (system) , and the computer program product according to this application. It should be understood that computer program instructions may be used to implement each process and / or each block in the flowcharts and / or the block diagrams and a combination of a process and / or a block in the flowcharts and / or the block diagrams. The computer program instructions may be provided for a general-purpose computer, a dedicated computer, an embedded processor, or a processor of another programmable data processing device to generate a machine, so that the instructions executed by the computer or the processor of the another programmable data processing device generate an apparatus for implementing a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0100] The computer program instructions may alternatively be stored in a computer-readable memory that can indicate a computer or another programmable data processing device to work in a specific manner, so that the instructions stored in the computer-readable memory generate an artifact that includes an instruction apparatus. The instruction apparatus implements a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0101] The computer program instructions may alternatively be loaded onto a computer or another programmable data processing device, so that a series of operations and steps are performed on the computer or the another programmable device, so that computer-implemented processing is generated. Therefore, the instructions executed on the computer or the another programmable device provide steps for implementing a specific function in one or more procedures in the flowcharts and / or in one or more blocks in the block diagrams.

[0102] It will be understood that a person skilled in the art may make various modifications and variations to this application without departing from the scope of this application. This application is intended to cover these modifications and variations of this application provided that they fall within the scope of protection defined by the following claims and their equivalent technologies.

[0103] Throughout the present disclosure, a processor, a processor system, an application processor, a baseband processor, a processor circuit, or a processor core may be collectively referred to as a processor. A processor may include one or more of a central processing unit (CPU) , a digital signal processor (DSP) , a microprocessor unit (MPU) , a microcontroller unit, (MCU) , a graphics processing unit (GPU) , a field programmable gate array (FPGA) , an artificial intelligence (AI) processor, or a neural network processing unit (NPU) , or a combination of at least two of these integrated circuit forms.

[0104] Throughout the present disclosure, a memory may include one or more of the following storage media: a RAM, a static random access memory (SRAM) , a dynamic random access memory (DRAM) , a phase-change memory (PCM) , a resistive random access memory (ReRAM) , a magnetoresistive random access memory (MRAM) , a ferroelectric random access memory (FRAM) , a cache, a register, a read-only memory (ROM) , a flash memory, an erasable programmable read-only memory (EPROM) , a hard disk, and / or the like. In an example, the computer program instructions used to execute embodiments contained herein may be stored in a non-volatile memory. When a terminal runs, part or all of corresponding computer program instructions may be loaded into a memory that has a higher transmission speed with a corresponding processor, for example, the instructions may be loaded into at least a part of a memory such that the processor executes the computer program instructions to perform the steps in of embodiments described herein.

[0105] The various embodiments presented above are merely examples and are in no way meant to limit the scope of this application. Variations of the innovations described herein will be apparent to persons of ordinary skill in the art, such variations being within the intended scope of the present application. In particular, features from one or more of the above-described example embodiments may be selected to create alternative example embodiments including a sub-combination of features which may not be explicitly described above. In addition, features from one or more of the above-described example embodiments may be selected and combined to create alternative example embodiments including a combination of features which may not be explicitly described above. Features suitable for such combinations and sub-combinations would be readily apparent to persons skilled in the art upon review of the present application as a whole. The subject matter described herein and in the recited claims intends to cover and embrace all suitable changes in technology.

Claims

1.A computer-implemented method for dynamically configuring an application operating on a cloud computing infrastructure, the application having a set of configurable parameters, the method comprising:generating a dependency graph that maps dependencies between the parameters based on metrics for the application during operation on the cloud computing infrastructure;selecting at least one subgraph from the dependency graph, wherein the at least one subgraph includes a subset of the parameters in the dependency graph;creating one or more subgraph variants from the at least one subgraph by adding one or more parameters from the dependency graph that are not in the subset to the as least one subgraph or removing at least one parameter in the subset from the at least one subgraph;running a simulation for the at least one subgraph and each subgraph variant to generate respective probabilities of viable operation of the application and identifying a subset of the subgraphs based on their respective probabilities indicating viable operation;generating a ranked set of configurations by performing a Bayesian optimization on the subset of the subgraphs;implementing one of the ranked set of configurations using a test replica of the application to evaluate against one or more production replicas of the application operating on the cloud computing infrastructure; anddetermining that the one of the ranked set of configurations outperforms the one or more production replicas based on one or more performance metrics and, in response, implementing the one of the ranked set of configurations within the one or more production replicas of the application operating on the cloud infrastructure.2.The computer-implemented method of claim 1, wherein selecting the at least one subgraph includes selecting parameters linked by at least the N strongest dependency connections in the dependency graph.3.The computer-implemented method of claim 1, wherein selecting the at least one subgraph includes pruning the dependency graph of a plurality of parameters on the basis that the plurality of parameters have the weakest dependencies.4.The computer-implemented method of claim 1, wherein creating one or more subgraph variants includes adding the one or more parameters from the dependency graph through random selection of the one or more parameters.5.The computer-implemented method of claim 1, wherein creating one or more subgraph variants includes adding the one or more parameters from the dependency graph based on the one or more parameters having a lowest strength connection with parameters in the subset of the parameters.6.The computer-implemented method of claim 1, wherein creating one or more subgraph variants includes removing the at least one parameter based on random selection.7.The computer-implemented method of claim 1, wherein the simulation includes utilizing a counterfactual analysis algorithm to test for cause-and-effect relations between parameters.8.The computer-implemented method of claim 7, wherein the probability of viable operation output from the simulation includes at least a fail result and a pass result.9.The computer-implemented method of claim 1, wherein creating the one or more subgraph variants includes, for at least one parameter in the subgraph variant, shrinking an associated parameter range.10.The computer-implemented method of claim 1, further comprising, after implementation of the one of the ranked set of configurations within the one or more production replicas of the application, updating the dependency graph based on operation of the one or more production replicas.11.A computer system comprising:a communication module;one or more processors coupled with the communication module; anda memory coupled to the one or more processors and storing processor-executable instructions which, when executed by the processor, are to configure the one or more processors to:generate a dependency graph that maps dependencies between the parameters based on metrics for the application during operation on the cloud computing infrastructure;select at least one subgraph from the dependency graph, wherein the at least one subgraph includes a subset of the parameters in the dependency graph;create one or more subgraph variants from the at least one subgraph by adding one or more parameters from the dependency graph that are not in the subset to the as least one subgraph or removing at least one parameter in the subset from the at least one subgraph;run a simulation for the at least one subgraph and each subgraph variant to generate respective probabilities of viable operation of the application and identifying a subset of the subgraphs based on their respective probabilities indicating viable operation;generate a ranked set of configurations by performing a Bayesian optimization on the subset of the subgraphs;implement one of the ranked set of configurations using a test replica of the application to evaluate against one or more production replicas of the application operating on the cloud computing infrastructure; anddetermine that the one of the ranked set of configurations outperforms the one or more production replicas based on one or more performance metrics and, in response, implementing the one of the ranked set of configurations within the one or more production replicas of the application operating on the cloud infrastructure.12.The computer system of claim 11, wherein the instructions, when executed, are to cause the one or more processors to select the at least one subgraph at least in part by selecting parameters linked by at least the N strongest dependency connections in the dependency graph.13.The computer system of claim 11, wherein the instructions, when executed, are to cause the one or more processors to select the at least one subgraph at least in part by pruning the dependency graph of a plurality of parameters on the basis that the plurality of parameters have the weakest dependencies.14.The computer system of claim 11, wherein the instructions, when executed, are to cause the one or more processors to create one or more subgraph variants at least in part by adding the one or more parameters from the dependency graph through random selection of the one or more parameters.15.The computer system of claim 11, wherein the instructions, when executed, are to cause the one or more processors to create one or more subgraph variants at least in part by adding the one or more parameters from the dependency graph based on the one or more parameters having a lowest strength connection with parameters in the subset of the parameters.16.The computer system of claim 11, wherein the instructions, when executed, are to cause the one or more processors to create one or more subgraph variants at least in part by removing the at least one parameter based on random selection.17.The computer system of claim 11, wherein the simulation includes utilizing a counterfactual analysis algorithm to test for cause-and-effect relations between parameters.18.The computer system of claim 17, wherein the probability of viable operation output from the simulation includes at least a fail result and a pass result.19.The computer system of claim 11, wherein the instructions, when executed, are to cause the one or more processors to create the one or more subgraph variants at least in part by, for at least one parameter in the subgraph variant, shrinking an associated parameter range.20.A computing device comprising at least one processor and a memory coupled to the at least one processor, wherein the memory stores instructions that, when executed by the at least one processor, are to cause the at least one processor to perform the method of any one of claims 1 to 10.21.A non-transitory, computer readable medium storing instructions which, when executed by a processor, cause the processor to carry out the method claimed in any one of claims 1 to 10.22.A computer program comprising instructions which, when executed by a computing device, are to cause the computing device to carry out the method of any one of claims 1 to 10.23.A computing device comprising means to perform the method of any one of claims 1 to 10.

Images