Runtime Environment Decision for Software Containers

Abstract

Static parameters of the software container, which relate to metadata about the software container itself, are identified. The software container is assigned to a selected runtime environment based on the static parameters using a first machine learning model. Runtime parameters of the software container are identified by analyzing the software container at runtime. The runtime parameters relate to behavior required by the software container during runtime. Using a second machine learning model, it is determined whether the selected runtime environment matches the runtime parameters. If the runtime environment matches, the software container continues to execute in this environment. If the runtime environment does not match, the software container is executed in a different runtime environment that matches both the static parameters and the runtime parameters.

Description

[Background technology]

[0001] Part of developing a system capable of running software includes configuring the system to provide a runtime environment in which the software will ultimately run. The runtime environment should be defined to have all of the resources that will be needed to run the application, and the runtime environment may also provide some basic functionality necessary for the application. For example, depending on the software language and application, the runtime environment may provide functionality such as garbage collection, stack and heap management, etc. Additionally, the runtime environment may perform functionality such as load balancing, bin packing, and self-healing actions. Summary of the Invention

[0002] Aspects of the present disclosure relate to methods, systems, and computer program products related to determining runtime environment requirements for a software container. For example, the method includes identifying static parameters for the software container. The static parameters relate to metadata about the software container itself. The method further includes assigning the software container to a selected runtime environment based on the static parameters using a first machine learning model. The method further includes identifying runtime parameters for the software container. The runtime parameters are identified by analyzing the software container prior to execution of the software container based on a second machine learning model. The runtime parameters relate to operations that the software container will require during runtime. The method further includes determining whether the selected runtime environment matches the runtime parameters, and either executing the software container in the selected runtime environment when the selected runtime environment matches the runtime parameters, or executing the software container in a different runtime environment that matches both the static parameters and the runtime parameters when the selected runtime environment does not match the runtime parameters. Systems and computer products configured to perform the aforementioned methods are also disclosed.

[0003] The above summary is not intended to describe each illustrated embodiment or every implementation of the present disclosure.

[0004] The drawings included herein are incorporated into and form a part of this specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The drawings are merely illustrative of certain embodiments and do not limit the disclosure. [Brief explanation of the drawings]

[0005] [Figure 1]1 illustrates a conceptual diagram of an exemplary system in which a controller may assign labeled software containers to various runtime environments based on multiple machine learning models. [Figure 2] 2 illustrates a conceptual box diagram of exemplary components of the controller of FIG. 1. [Figure 3] 1 illustrates an example flow diagram by which the controller of FIG. 1 may assign a software container to one of multiple runtime environments. [Figure 4] FIG. 1 is a schematic diagram of a cloud computing environment in which playback speeds can be identified. [Figure 5] FIG. 1 is a diagram of an abstraction model layer of a cloud computing environment in which playback speed can be identified. DETAILED DESCRIPTION OF THE INVENTION

[0006] While the invention is susceptible to various modifications and alternative forms, specifics thereof have been shown by way of example in the drawings and will be described in detail. It should be understood, however, that the intention is not to limit the invention to the particular embodiments described. Rather, the intention is to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the invention.

[0007] While aspects of the present disclosure relate to assigning software containers to runtime environments, more particular aspects of the present disclosure relate to configuring a first machine learning model to analyze static parameters of the software containers and configuring a second machine learning model to analyze runtime parameters of the software containers to determine runtime characteristics of the software containers for the purpose of assigning the software containers to runtime environments. While the present disclosure is not necessarily limited to such application areas, various aspects of the present disclosure may be understood through a discussion of various examples using this context.

[0008] In modern computing solutions, computing elements are becoming increasingly modular, such that various virtual and / or physical components, modules, workloads, etc., can be moved to different locations. For example, in modern cloud environments, there may be a large number of runtime environments available to run a large number of software containers for a large number of customers. Some or all of the runtime environments may have different types of resources available to them (e.g., different amounts of processing power, different amounts of memory, different input / output (IO) capabilities, etc.), and each software container may require a different combination of these resources to perform different functions within the runtime environment (e.g., different rates of load balancing, different numbers of rollbacks, different rates of automatic bin packing, different rates of self-healing, etc.).

[0009] If a software container is in a runtime environment that is more robust than necessary (e.g., the software container only requires X load balancing actions per hour, but the runtime environment can provide 2X load balancing actions per hour), some resources of the complete computing system (whether within a single computer or across a network, e.g., a cloud computing network) may be wasted and / or underutilized. Similarly, if a software container is in a runtime environment that does not provide the resources needed to run the software container at full capacity, then the performance of the software container may be impaired. Modern systems may periodically move software containers between different runtime environments to attempt to avoid resource underutilization and / or slowing down the software container during runtime due to insufficient resources in the runtime environment.

[0010] For example, conventional systems may use a process in which a trained operator infers which runtime environment will best match a software container. For example, a trained operator may assign multiple software containers to multiple runtime environments and may attempt to assign software containers to such runtime environments in an attempt to invoke what previously worked for similar software containers. The operator and / or system may then incrementally move the container to different environments over time and monitor how the container performs in the environments until the software container's needs appear to be well-matched to the runtime environment's capabilities. However, this process is cumbersome and prone to user error, and it may take a relatively long time for the software container to run in a runtime environment that is well-matched to the software container.

[0011] To this end, conventional systems may attempt to use machine learning models to match software containers and runtime environments. Such machine learning models may attempt to find correlations between the characteristics of software containers, the needs of the software containers in their runtime environments, and potential runtime environments. However, there are many factors that distinguish software containers, and further, there are many capabilities that distinguish runtime environments. As such, conventional systems using a single machine learning model may have difficulty finding true correlations.

[0012] Aspects of the present disclosure aim to reduce or eliminate these problems of conventional systems. For example, aspects of the present disclosure involve using a first machine learning model that analyzes static parameters of a software container to initially select a runtime environment, and a second machine learning model that analyzes runtime parameters of the software container at runtime to check whether the software container should be moved after execution in the runtime environment. These two models can be independently updated based on the performance of the software container in the initial (and any subsequent) runtime environments. By using two separate models in two different sets that process distinct sets of variables, aspects of the present disclosure may improve the ability to assign software containers to runtime environments that are well-suited for the software container within a relatively fast timeframe and with relatively few iterations (e.g., within a few hours of execution time, and within the first or second assignment to a given runtime environment rather than the fourth, fifth, sixth, etc. assignment).

[0013] 1 illustrates an environment 100 in which a controller 110 assigns a software container 120 to one of multiple runtime environments 130A, 130B (collectively, "runtime environments 130"). The controller 110 may include a computing device, such as the computing system 200 of FIG. 2, which includes a processor communicatively coupled to a memory containing instructions that, when executed by the processor, cause the controller 110 to perform one or more operations described below.

[0014] A software container 120 may include a self-contained package that includes code and a set of dependencies. This code and set of dependencies may enable the software container 120 to execute in multiple runtime environments 130 that match the software container as described herein. In some examples, the software container 120 may be received from a remote computing device, while in other examples, the software container 120 may be local to the controller 110. After executing in one of the runtime environments 130, the software container 120 may be accessed in this manner by one or more users. These users may be local or remote to one or each of the controller 110, the software container 120, or each assigned runtime environment 130, or any combination thereof.

[0015] A runtime environment 130 may be a constructed environment within a computer system in which one or more software containers 120 may execute (e.g., such that the execution model of a software container 120 is implemented by each runtime environment 130). For example, runtime environments 130 may be associated with different nodes across a distributed system. While only two runtime environments 130 are depicted in FIG. 1 for illustrative purposes, in other examples, controller 110 may have any number of runtime environments 130, each defining a different capability.

[0016] The runtime environment 130 may be provided (e.g., hosted) by one or more computing devices (e.g., computing devices similar to computing system 200 of FIG. 2). Such computing devices may be integrated with or separate from the computing device that hosts the controller 110 and / or provides the software container 120. The various computing devices of the environment 100 may communicate via a network 140. The network 140 may include a computing network over which computing messages may be sent and / or received. For example, the network 140 may include the Internet, a local area network (LAN), a wide area network (WAN), a wireless network such as a wireless LAN (WLAN), and the like. The network 140 may include copper transmission cables, optical transmission fiber, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. A network adapter card or network interface within each computing / processing device may receive messages and / or instructions from and / or over network 140 and forward the messages and / or instructions to a respective memory or processor of the respective computing / processing device for storage, execution, etc. Although network 140 is depicted as a single entity in FIG. 1 for purposes of explanation, in other examples network 140 may include multiple private and / or public networks through which controller 110 may manage connectivity as described herein.

[0017] The controller 110 can analyze static parameters of the software container 120 to assign the software container 120 to one of the runtime environments 130. These static parameters may be related to metadata of the software container itself. In some examples, none of these initial static parameters may directly define the requirements needed by the software container 120 during runtime. Some of the static parameters may be nearly permanent in nature, such that it is unlikely or impossible for the static parameters of the software container 120 to change over time.

[0018] For example, static parameters of software container 120 may include variables such as the date and time the software container 120 was created, the date and / or time the software container 120 was last accessed (e.g., accessed by a user or accessed by a developer), the date and / or time the software container 120 was last modified (e.g., when the code and / or dependencies of software container 120 changed), the size (in bytes) of software container 120, the category or type of software container 120 (e.g., based on the functionality of software container 120, the target audience of software container 120, whether software container 120 is a cloud-based application, etc.), the template of software container 120, or other such variables.

[0019] After the controller 110 identifies these static parameters, the controller 110 assigns the software container 120 to one of the runtime environments 130. The controller 110 may use a first machine learning model to determine a correlation between these static parameters and the runtime environments 130 and assign the software container 120 to one of the runtime environments 130. For example, the controller 110 may determine that the size of a software container 120 created in the year the software container 120 was created but not updated within the time frame reflected by the static parameters matches runtime environment 130A. As such, the controller 110 may assign the software container 120 to runtime environment 130A and perform steps as needed to enable the software container 120 to execute in runtime environment 130A (e.g., moving the software container 120 from a remote location to a location where the software container 120 can execute in runtime environment 130A).

[0020] The controller 110 can monitor the software container 120 during runtime in the assigned runtime environment 130A. The controller 110 can monitor runtime parameters 120 of the software container. These runtime parameters can relate to operations required by the software container 120 during runtime. For example, as described above, the runtime parameters can relate to the restart policy of the software container 120, the number of load balancing actions per hour (e.g., including the number of times the processing demand of the software container 120 is higher than the processing allocated by the host of the software container 120 to further consider and / or filter out instances of maintenance, hardware failures, etc.), the number of automatic rollbacks, the number of automatic bin-packing actions, the number of self-healing actions, etc.

[0021] Additionally, the controller 110 may monitor parameters such as the amount of access (read) of the software container 120 since creation and / or the number of modification (write) actions of the software container 120, and the number of access and / or modification actions since the software container 120 was reset.

[0022] The controller 110 may determine how well the software container 120 matches the runtime environment 130A. The controller 110 may determine that the software container 120 matches the runtime environment 130A based on the performance of the software container 120 in the runtime environment 130A. For example, the controller 110 may monitor central processing unit usage, memory usage, input / output usage, the number of times the software container 120 is accessed / modified by a user during runtime, etc.

[0023] The controller 110 then uses a second machine learning model to determine whether this monitored performance, quantified by the runtime parameters, indicates that the software container 120 is a match for the runtime environment 130A. This second machine learning model may or may not include or reflect static parameters. In some examples, the second machine learning model may include some static parameters, such as the size of the software container 120. In other examples, the second machine learning model may include all static parameters as well as runtime parameters, and by finding correlations using the performance of the software container 120 in the runtime environment 130A already assigned (by the first machine learning model), the controller 110 may improve its ability to quickly identify whether the runtime environment 130A is a match for the software container 120, or whether another of the runtime environments 130 may be a better match for the software container 120, or both.

[0024] The controller 110 may determine that one of the runtime environments 130 is a match for the software container 120 when the performance of the software container 120 meets a threshold, or when the cost (e.g., billable resource usage, e.g., memory usage or processing power) of the software container 120 executing within the assigned runtime environment 130 meets a threshold, or both.

[0025] The controller 110 can continue to monitor the software container 120 over time, gathering increasing data regarding performance and / or changing parameters. For example, the controller 110 can determine that the processing usage and / or memory usage of the software container 120 in the runtime environment 130A spikes, such that performance (and / or cost) does not meet a threshold. In response, the controller 110 can analyze whether another of the runtime environments 130 better matches the software container 120, such that the runtime performance (and / or cost) may meet the threshold when executed in the different runtime environment 130. If the controller 110 thus determines that the different runtime environment 130B matches the static and / or runtime parameters, the controller 110 can cause the software container 120 to run in the different runtime environment 130B instead.

[0026] The controller 110 may continue monitoring the software container 120 until ongoing updates are below a threshold. This may include changes to static parameters or runtime parameters, or both, below a threshold, such that the usage, cost, or performance, or a combination thereof, of the software container 120 within the assigned runtime environment 130 is identified as stable. This may also include any identified mismatch between the software container 120 and the runtime environment 130 being below a threshold (e.g., identifying the software container 120 as matching the runtime environment 130 with a 98% match may not meet the threshold for needing to continue monitoring). When the controller 110 determines that ongoing updates are minimal (such that the software container 120 and the runtime environment 130 are well matched, as described above), the controller 110 may terminate monitoring of the software container 120 within the runtime environment 130.

[0027] The controller 110 can independently update both the first and second machine learning models. For example, the controller 110 can update both with information regarding finalized static and / or runtime parameters, the complete historical performance of the software containers 120 in each assigned runtime environment 130, the complete historical cost of the software containers 120 in each assigned runtime environment 130, etc. The controller 110 can further differentiate between each model to distinguish between different classes, types, categories, etc. of software containers (e.g., software containers 120). Over time, the controller 110 can further determine what characteristics of the software containers 120 hold true correlations that should dictate their assignment to various runtime environments 130 and strengthen the rules of the machine learning model to assign the software containers 120 accordingly in the future. In this way, monitored data on the performance and cost of the software containers 120 in the runtime environments 130 over time can serve as training data for determining how to improve upon future software container 120 assignments.

[0028] In some examples, the runtime parameters determined and monitored by the controller 110 may include the impact of one software container 120 executing within the assigned runtime environment 130 on other downstream processes. For example, the controller 110 may determine that one software container 120 is used to spool print jobs, and another container is used for live audio processing for conference calls (e.g., these are categories of these containers). The controller 110 may further determine that, during operation, if high CPU usage causes some slowdown, the process including the software container 120 may not be substantially affected, while the process receiving the processed audio of the second container may be more substantially affected by any latency or jitter introduced by the computational contention. Upon determining this, the controller 110 may determine that the performance thresholds of the software container 120 are different from the performance thresholds of the second software container. In this way, the controller 110 can not only improve the ability of the software container 120 to execute in a given runtime environment, but also improve the execution of the complete computational process that includes part of the execution time of the software container 120 in the assigned runtime environment.

[0029] As mentioned above, the controller 110 may include, or be part of, a computing device including a processor configured to execute instructions stored in memory to perform the techniques described herein. For example, FIG. 2 is a conceptual box diagram of such a computing system 200 of the controller 110. While the controller 110 is depicted as a single entity (e.g., in a single enclosure) for purposes of explanation, in other examples, the controller 110 may include multiple separate physical systems (e.g., in multiple separate enclosures). The controller 110 may include an interface 210, a processor 220, and a memory 230. The controller 110 may include any number or quantity of interfaces 210, processors 220, and / or memories 230.

[0030] Controller 110 may include components that enable controller 110 to communicate with (e.g., send data to, and receive and use data sent by) devices external to controller 110. For example, controller 110 may include interface 210 configured to enable controller 110 and other components within controller 110 (e.g., processor 220) to communicate with entities external to controller 110. Specifically, interface 210 may be configured to enable components of controller 110 to communicate with a computing device that provides software container 120, one or more computing devices that host runtime environment 130, etc. Interface 210 may include one or more network interface cards, e.g., Ethernet cards, or any other type of interface device capable of sending and receiving information, or both. Any appropriate number of interfaces may be used to perform the described functions depending on particular needs.

[0031] As described herein, the controller 110 can be configured to assign software containers to runtime environments using different machine learning models. The controller 110 can assign software containers in this manner using the processors 220. The processors 220 can include, for example, a microprocessor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA), or equivalent discrete or integrated logic circuitry, or a combination thereof. Two or more of the processors 220 can be configured to each use different machine learning models to learn different correlations and to cooperatively initially and then iteratively assign software containers to runtime environments before or during runtime.

[0032] The processor 220 can assign software containers to runtime environments according to instructions 232 stored in the memory 230 of the controller 110. The memory 230 can include a computer-readable storage medium or a computer-readable storage device. In some examples, the memory 230 can include one or more of short-term memory or long-term memory. The memory 230 can include, for example, random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), a magnetic hard disk, an optical disk, a floppy disk, flash memory, a form of electrically programmable memory (EPROM), electrically erasable programmable memory (EEPROM), etc. In some examples, the processor 220 can assign software containers to runtime environments as described herein according to instructions 232 of one or more applications (e.g., software applications) stored in the memory 230 of the controller 110.

[0033] In addition to instructions 232, in some examples, collected / predetermined data, techniques, etc. used by processor 220 to assign software containers to runtime environments as described herein may be stored in memory 230. For example, memory 230 may include a first model 234 (which may itself include static parameter data 236) and a second model 238 (which may include static parameter data 240, runtime parameter data 242, or both). While only two models 234, 238 are depicted in FIG. 2 for illustrative purposes, in other examples, each model 234, 238 may itself be used to spawn multiple sub-machine learning models that learn how different parameters of software containers indicate how the software containers should be assigned to runtime environments. For example, in practice, while the software container 120 is executing within its assigned runtime environment, the controller 110 can monitor and capture parameter data, and the controller 110 can determine associations between this metadata using machine learning techniques 246, such as those described below, to define input vectors for subsequent machine learning models. The size of the input layer can be defined by the dimensions of the input vectors, and the associations can be sorted by monitored performance within the runtime environment. This information can be used to create and train (and retrain) each model over time, weighting it appropriately (e.g., by removing older annotations, reinforcing newer ones, etc.).

[0034] Additionally, memory 230 may include threshold data 244. The threshold data 244 may indicate a point at which the performance and / or cost of a software container in a runtime environment indicates that the software container should be moved to a different runtime environment. The threshold data 244 may also include data regarding a point at which the match between the software container and the runtime environment is so good, or the performance and / or cost are so stable, that monitoring of the software container should stop.

[0035] Memory 230 may further include machine learning techniques 246 that controller 110 can use to improve the process of determining software container parameters for allocating these software containers to runtime environments as discussed herein over time. Machine learning techniques 244 may include algorithms or models generated by performing supervised, unsupervised, or semi-supervised training of a dataset and then applying the generated algorithm or model to allocate software containers. Using these machine learning techniques 246, controller 110 can improve its ability to allocate software containers over time.

[0036] Machine learning techniques 246 may include, but are not limited to, decision tree learning, association rule learning, artificial neural networks, deep learning, inductive logic programming, support vector machines, clustering, Bayesian networks, reinforcement learning, representation learning, similarity / metric training, sparse dictionary learning, genetic algorithms, rule-based learning, or other machine learning techniques or combinations thereof. Specifically, the machine learning techniques 246 may use one or more of the following example techniques: k-nearest neighbors (KNN), learning vector quantization (LVQ), self-organizing maps (SOM), logistic regression, least squares regression (OLSR), linear regression, stepwise regression, multivariate adaptive regression splines (MARS), ridge regression, least absolute shrinkage and selection operator (LASSO), elastic net, least-angle regression (LARS), probabilistic classification, naive Bayes classifier, binary classifier, linear classifier, hierarchical classifier, canonical correlation analysis (CCA), factor analysis, independent component analysis (ICA), linear discriminant analysis (LDA), multidimensional scaling (MDS), non-negative metric factorization (NMF), and others. factorization), partial least squares regression (PLSR), principal component analysis (PCA), principal component regression (PCR), Sammon mapping, t-distributed stochastic neighbor embedding (t-SNE), bootstrap aggregating, harmonic mean calculation, gradient boosted decision trees (GBRT), gradient boosting machines (GBM), inductive bias algorithms, Q-learning, state-action-reward-state-action (SARSA), temporal difference (TD) learning, apriori algorithm, equivalence class transformation (ECLAT) algorithm, Gaussian process regression, gene expression programming, group method of data (GMDH)handling), inductive logic programming, instance-based learning, logistic model trees, information fuzzy networks (IFN), hidden Markov models, Gaussian naive Bayes, multinomial naive Bayes, averaged one-dependence estimators (AODE), classification and regression trees (CART), chi-squared automatic interaction detection (CHAID), expectation maximization algorithm, feedforward neural networks, logic learning machines, self-organizing maps, single-link clustering, fuzzy clustering, hierarchical clustering, Boltzmann machines, convolutional neural networks, recurrent neural networks, hierarchical temporal memory (HTM), and / or other machine learning algorithms.

[0037] Using these components, controller 110 can allocate software containers to runtime environments as described herein. For example, controller 110 can allocate software containers according to flowchart 300 depicted in FIG. 3. While flowchart 300 of FIG. 3 is discussed with respect to FIG. 1 for illustrative purposes, it should be understood that in other examples, other systems can be used to implement flowchart 300 of FIG. 3. Furthermore, in some examples, controller 110 can perform a different method than flowchart 300 of FIG. 3, or controller 110 can perform a similar method with more or fewer steps in a different order, etc.

[0038] Flowchart 300 may begin with controller 110 identifying (302) static parameters of software container 120. Controller 110 may assign software container 120 to runtime environment 130A (or an RTE provided in flowchart 300) using a first machine learning model (304). The controller may assign software container 120 to runtime environment 130A based on the identified static parameters.

[0039] The controller 110 may identify run-time parameters of the software container 120 (306). The controller 110 may identify these run-time environments during the execution of the software container 120 in the run-time environment 130A. In some examples, the controller 110 may collect a set of real-time static parameters of the software container 120 if these real-time static parameters are updated versions of preliminary static parameters identified by the controller 110 (if the preliminary static parameters were those static parameters identified in step 302). In other words, if static parameters are collected by the controller 110 both before and during the execution time to identify the initial run-time environment 130, the versions of the static parameters collected before the execution time may be classified as preliminary static parameters, and the (potentially, but not necessarily) different versions of those static parameters collected during the execution time may be classified as real-time static parameters.

[0040] The controller 110 may determine whether the assigned runtime environment 130A matches the identified runtime parameters (308). The controller 110 may use a second machine learning model to determine whether the assigned runtime environment 130A matches the identified runtime parameters. In some examples, the controller 110 may use the model to determine whether both the runtime parameters and the real-time static parameters match the assigned runtime environment 130A. When the performance and / or cost of the software container 120 in the assigned runtime environment 130A meets one or more thresholds (e.g., has performance above the threshold and has cost below the threshold), the controller 110 may determine that the runtime parameters and / or real-time static parameters of the software container 120 match the assigned runtime environment 130A.

[0041] If the controller 110 determines that the model indicates that one (or both) of the parameters match the assigned runtime environment 130A, the controller 110 may continue executing the software container 120 in the selected runtime environment 130A (310). Alternatively, if the controller 110 determines that a match does not exist as discussed herein, the controller 110 may use a second model to move the software container 120 to a different runtime environment 130B determined to have an improved match with the parameters (312). Similarly, if the controller 110 determines that a match does not exist as discussed herein, but the match score is better between the software container 120 and the assigned runtime environment 130A than between the other runtime environments 130, the controller 110 may decide to maintain the software container 120 in the assigned runtime environment 130A until one or more improved runtime environments 130 are discovered, brought online, created, etc.

[0042] In any case, the controller 110 may collect updates over time (314). The controller 110 may collect these updates on a predetermined schedule (e.g., once every 20 minutes, or once every few actions, etc.). These updates may be parameter updates / changes, performance updates, cost updates, etc. The controller 110 may then determine (316) whether these updates are below a threshold. For example, the threshold may include a threshold amount of change or a threshold severity of change, such that either the complete and final set of parameters or the complete and final performance of the software container 120 is unknown. If the updates are less stringent or fewer in number than a threshold (such that the software container 120 matches any of the runtime environments 130 to which the software container 120 is currently assigned), the controller 110 determines that the software container 120 matches any of the runtime environments 130 in which the software container 120 is currently executing in a stable manner and determines to terminate further analysis (e.g., according to a predetermined schedule) of the software container 120 during runtime (318). As part of ceasing monitoring, the controller 110 may also update both (or, if more than two are present, all) machine learning models with final parameter readings, performance data, cost data, etc.

[0043] Alternatively, if the controller 110 determines that the updates are of a severity and / or number above a threshold (indicating that the match is not yet satisfactory and / or that the parameters and / or performance are likely still in flux), the controller 110 may analyze whether the current runtime environment 130 matches the software container 120 and / or whether another runtime environment 130 better matches the software container 120 according to the second model (320). If the current runtime environment 130 matches the software container 120 as well as the other runtime environments 130, the controller 110 continues to execute the software container 120 in the current software environment 130 (322).

[0044] In some examples, the controller 110 may determine that another runtime environment 130 is a better fit for the software container 120. In this example, the controller 110 moves the software container 120 to this other runtime environment 130 and executes the software container 120 in this different runtime environment 130 (324). Regardless of whether the controller 110 continues to execute the software container 120 in the current runtime environment 130, the controller 110 continues to collect parameter updates (e.g., according to a predetermined schedule at 314) and determines (at 320) whether another runtime environment 130 is a better match for the software container 120 until the controller determines (at 316) that the severity and / or number of collected updates is below a threshold.

[0045] Cloud Computing

[0046] Although this disclosure includes detailed descriptions of cloud computing, it should be understood that implementation of the teachings recited herein is not limited to cloud computing environments. Rather, embodiments of the present invention may be implemented in conjunction with any other type of computing environment now known or later developed.

[0047] Cloud computing is a model of service delivery that enables convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, network bandwidth, servers, processing, memory, storage, applications, virtual machines, and services) that can be rapidly provisioned and released with minimal management effort or interaction with the provider of the service. This cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0048] The characteristics are as follows:

[0049] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity (e.g., server time and network storage) as needed automatically without the need for human interaction with the service provider.

[0050] Pervasive Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, and PDAs).

[0051] Resource Pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, with different physical and virtual resources dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the provided resources, but there is a sense of location independence in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0052] Rapid Elasticity: Capacity can be rapidly elastically provisioned, sometimes automatically, to quickly scale out, and rapidly de-provisioned to quickly scale in. To the consumer, the capacity available for provisioning often appears unlimited and can be purchased in any quantity at any time.

[0053] Measured Services: Cloud systems automatically control and optimize resource utilization by leveraging metering capabilities at some level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, and active user accounts). Resource usage can be monitored, controlled, and reported, providing transparency to both providers and consumers of the services utilized.

[0054] The service model is as follows:

[0055] Software as a Service (SaaS): The consumer is offered the ability to use a provider's applications running on a cloud infrastructure. The applications are accessible from a variety of client devices through thin-client interfaces such as web browsers (e.g., web-based email). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0056] Platform as a Service (PaaS): The ability offered to consumers is to deploy consumer-created or acquired applications onto a cloud infrastructure created using programming languages and tools supported by the provider. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does control the deployed applications and sometimes the application hosting environment configuration.

[0057] Infrastructure as a Service (IaaS): The capability offered to consumers is to provision processing, storage, network, and other underlying computing resources on which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but rather controls the operating system, storage, deployed applications, and possibly limited control of select network components (e.g., host firewalls).

[0058] The deployment models are as follows:

[0059] Private Cloud: The cloud infrastructure is operated solely for the organization. The cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises.

[0060] Community Cloud: Cloud infrastructure is shared by several organizations to support a specific community with common interests (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organization or a third party and may reside on-premises or off-premises.

[0061] Public cloud: Cloud infrastructure is made available to the general public or large industry groups and is owned by an organization that sells cloud services.

[0062] Hybrid Cloud: A cloud infrastructure is a composition of multiple clouds (private, community, or public) that remain unique entities but are tied together by standardized or proprietary technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0063] A cloud computing environment is a service oriented environment with an emphasis on statelessness, low coupling, modularity, and semantic interoperability. At the heart of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0064] Referring now to FIG. 4, an exemplary cloud computing environment 50 is depicted. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which local computing devices used by cloud consumers, such as a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, or an automotive computer system 54N, or any combination thereof, can communicate. The nodes 10 may communicate with each other. They may be physically or virtually grouped in one or more networks, such as private, community, public, or hybrid clouds, as previously described, or any combination thereof (not shown). This enables the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service without the cloud consumer having to maintain resources on their local computing device. It is understood that the types of computing devices 54A-N shown in FIG. 4 are intended to be illustrative only, and that computing node 10 and cloud computing environment 50 may communicate with any type of computerized device via any type of network and / or network-addressable connection (e.g., using a web browser).

[0065] Referring now to Figure 5, a set of functional abstraction layers provided by cloud computing environment 50 (Figure 4) is shown. It should be understood in advance that the components, layers, and functions illustrated in Figure 5 are intended to be merely exemplary, and embodiments of the present invention are not limited thereto. As depicted, the following layers and corresponding functions are provided:

[0066] Hardware and software layer 60 includes hardware and software components. Examples of hardware components include mainframes 61, RISC (reduced instruction set computer) architecture-based servers 62, servers 63, blade servers 64, storage devices 65, and networks and network components 66. In some embodiments, software components include network application server software 67 and database software 68.

[0067] The virtualization layer 70 provides an abstraction layer from which the following examples of virtual entities can be provided: virtual servers 71, virtual storage 72, virtual networks including virtual private networks 73, virtual applications and operating systems 74, and virtual clients 75.

[0068] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing and other resources used to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are used within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification of cloud consumers and tasks, as well as protection of data and other resources. User portal 83 provides consumer and system administrator access to the cloud computing environment. Service level management 84 provides cloud computing resource allocation and management so that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides advance arrangement and procurement of cloud computing resources in anticipation of future demand according to SLAs.

[0069] The workload layer 90 provides examples of functionality for which a cloud computing environment may be used. Examples of workloads and functionality that may be provided from this layer include: mapping and navigation 91, software development and lifecycle management 92, virtual classroom instruction delivery 93, data analytics processing 94, transaction processing 95, and runtime environment determination for software containers 96.

[0070] The descriptions of various embodiments of the present disclosure have been presented for purposes of illustration and are not intended to be exhaustive or limited to the disclosed embodiments. Numerous modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein has been chosen to explain the principles of the embodiments, practical applications or technical improvements to technology found in the marketplace, or to enable others skilled in the art to understand the embodiments disclosed herein.

[0071] The present invention may be a system, method, or computer program product, or any combination thereof, at any possible level of technical detail. The computer program product may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to implement aspects of the present invention.

[0072] A computer-readable storage medium may be a tangible device capable of holding and storing instructions for use by an instruction execution device. A computer-readable storage medium may be, for example, but not limited to, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or any suitable combination of the foregoing. A non-exhaustive list of more specific examples of computer-readable storage media includes: portable computer diskettes, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), static random access memory (SRAM), portable CD-ROMs, digital versatile disks (DVDs), memory sticks, floppy disks, mechanically encoded devices such as punch cards or raised structures in grooves with instructions recorded on them, and any suitable combination of the foregoing. As used herein, a computer-readable storage medium should not be construed as being a transitory signal per se, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagating through a waveguide or other transmission medium (e.g., a light pulse passing through a fiber optic cable), or an electrical signal transmitted over a wire.

[0073] The computer-readable program instructions described herein may be downloaded to each computing / processing device from a computer-readable storage medium or to an external computer or storage device via a network, such as the Internet, a local area network, a wide area network, or a wireless network, or a combination thereof. The network may include copper transmission cables, optical fiber transmissions, wireless transmissions, routers, firewalls, switches, gateway computers, or edge servers, or a combination thereof. A network adapter card or network interface in each computing / processing device receives the computer-readable program instructions from the network and forwards the computer-readable program instructions for storage in a computer-readable storage medium within the respective computing / processing device.

[0074] Computer-readable program instructions for carrying out operations of the present invention may be source or object code written in any combination of one or more programming languages, including assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state and status data, configuration data for integrated circuits, or object-oriented programming languages such as Smalltalk, C++, and procedural programming languages, e.g., the "C" programming language or similar programming languages. The computer-readable program instructions may execute entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer via any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, a programmable logic circuit, a field programmable gate array (FPGA), or a programmable logic array (PLA), may execute computer-readable program instructions by customizing the electronic circuitry using state information of the computer-readable program instructions to perform aspects of the present invention.

[0075] Aspects of the present invention are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0076] These computer-readable program instructions may be provided to a processor of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, when executed by the processor of the computer or other programmable data processing apparatus, produce means for implementing the functions / activities specified in one or more blocks of the flowcharts and / or block diagrams. These computer-readable program instructions may also be stored in a computer-readable storage medium that can instruct a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner, such that the computer-readable storage medium on which the instructions are stored comprises an article of manufacture containing instructions that implement aspects of the functions / activities specified in one or more blocks of the flowcharts and / or block diagrams.

[0077] Computer-readable program instructions may also be loaded into a computer, other programmable data processing apparatus, or other device to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to produce a computer-implemented process, such that the instructions executing on the computer, other programmable apparatus, or other device implement the functions / activities specified in one or more blocks of the flowcharts and / or block diagrams.

[0078] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of the present invention. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of instructions, including one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions noted in the blocks may occur out of the order noted in the figures. For example, two blocks shown in succession may in fact be completed as a single step, executed concurrently, substantially concurrently, partially, or completely in a time-overlapping manner, or the blocks may sometimes be executed in reverse order, depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, may be implemented by a special-purpose hardware-based system that performs the specified functions or activities or executes a combination of special-purpose hardware and computer instructions.

Claims

1. identifying static parameters of a software container, the static parameters relating to metadata of the software container itself; initially selecting a runtime environment by analyzing static parameters of the software container using a first machine learning model, and assigning the software container to the selected runtime environment; identifying runtime parameters of the software container by analyzing the software container at runtime, the runtime parameters relating to operations required by the software container during runtime; responsive to determining, using a second machine learning model, that the selected runtime environment matches the runtime parameters, continuing to execute the software container in the selected runtime environment; and responsive to determining, using the second machine learning model, that the selected runtime environment does not match the runtime parameters, executing the software container in a different runtime environment that matches both the static parameters and the runtime parameters; 20. A computer-implemented method comprising:

2. monitoring the performance of the software container during runtime; updating the first machine learning model based on the performance; and updating the second machine learning model based on the performance; and The computer-implemented method of claim 1 further comprising:

3. The computer-implemented method of claim 2 , wherein the performance is monitored for at least central processing unit (CPU) usage, memory usage, and input / output (I / O) metrics.

4. the static parameters are preliminary static parameters, and the computer-implemented method further comprises: identifying real-time static parameters of the software container by analyzing the software container at run time; In response to determining, using the second machine learning model, that the selected runtime environment matches both the real-time static parameters and the runtime parameters, continuing to execute the software container in the selected runtime environment; and responsive to determining, using the second machine learning model, that the selected runtime environment does not match the real-time static parameters and the runtime parameters, executing the software container in the different runtime environment that matches both the real-time static parameters and the runtime parameters; 4. The computer-implemented method of claim 1, comprising:

5. identifying one or more updates to either the real-time static parameters or the runtime parameters by analyzing the software container during runtime, subsequent to identifying the runtime parameters according to a predetermined schedule; executing the software container in the selected runtime environment in response to determining, using the second machine learning model, that the selected runtime environment matches both the real-time static parameters and the runtime parameters according to the update information; and executing the software container in the different runtime environment in response to determining, using the second machine learning model, that the selected runtime environment does not match the real-time static parameters and the runtime parameters due to the update information; and The computer-implemented method of claim 4 further comprising:

6. 6. The computer-implemented method of claim 5, further comprising, in response to determining that a quantity or severity of the one or more updates is below a threshold, terminating subsequent analysis of the software container during the execution time according to the predetermined schedule.

7. The computer-implemented method of claim 1 , wherein the runtime parameters relate to operations required by the software container.

8. The static parameters are: The type of software container, a template of the software container; The software container category and 8. The computer-implemented method of claim 1, comprising:

9. The execution time parameter is the number of load balancing operations per hour; and The number of automatic rollbacks, the number of automatic bin packing operations per hour; and Number of self-healing actions per hour and 9. The computer-implemented method of claim 1, comprising:

10. a processor; a memory in communication with the processor, identifying static parameters of a software container, the static parameters relating to metadata of the software container itself; initially selecting a runtime environment by analyzing static parameters of the software container using a first machine learning model, and assigning the software container to the selected runtime environment; identifying runtime parameters of the software container by analyzing the software container at runtime, the runtime parameters relating to operations required by the software container during runtime; continuing to execute the software container in the selected runtime environment in response to determining, using a second machine learning model, that the selected runtime environment matches the runtime parameters; and and executing the software container in a different runtime environment that matches both the static parameters and the runtime parameters in response to determining, using the second machine learning model, that the selected runtime environment does not match the runtime parameters. the memory containing instructions that, when executed by the processor, cause the processor to perform A system comprising:

11. The memory, when executed by the processor, monitoring the performance of the software container during runtime; updating the first machine learning model based on the performance; and updating the second machine learning model based on the performance; and 11. The system of claim 10, further comprising additional instructions that cause the processor to:

12. The system of claim 11 , wherein the performance is monitored for at least central processing unit (CPU) usage, memory usage, and input / output (I / O) metrics.

13. The static parameters are preliminary static parameters, and the memory identifying real-time static parameters of the software container by analyzing the software container at run time; In response to determining, using the second machine learning model, that the selected runtime environment matches both the real-time static parameters and the runtime parameters, continuing to execute the software container in the selected runtime environment; and 13. The system of claim 10, further comprising additional instructions that, when executed by the processor, cause the processor to: in response to determining using the second machine learning model that the selected runtime environment does not match the real-time static parameters and the runtime parameters, execute the software container in the different runtime environment that matches both the real-time static parameters and the runtime parameters.

14. The memory identifying one or more updates to either the real-time static parameters or the runtime parameters by analyzing the software container during runtime, subsequent to identifying the runtime parameters according to a predetermined schedule; executing the software container in the selected runtime environment in response to determining, using a second machine learning model, that the selected runtime environment matches both the real-time static parameters and the runtime parameters according to the update information; and executing the software container in the different runtime environment in response to determining, using a second machine learning model, that the selected runtime environment does not match the real-time static parameters and the runtime parameters due to the update information; and 14. The system of claim 13, further comprising additional instructions that, when executed by the processor, cause the processor to:

15. 15. The system of claim 14, wherein the memory comprises additional instructions that, when executed by the processor, cause the processor to terminate subsequent analysis of the software container during the execution time according to the predetermined schedule in response to determining that a quantity or severity of the one or more updates is below a threshold.

16. A computer program comprising: identifying static parameters of a runtime environment of the software container; identifying said static parameters, said static parameters relating to metadata of said software container itself; initially selecting a runtime environment by analyzing static parameters of the software container using a first machine learning model, and assigning the software container to the selected runtime environment; identifying runtime parameters of the software container by analyzing the software container at runtime, the runtime parameters relating to operations required by the software container during runtime; responsive to determining, using a second machine learning model, that the selected runtime environment matches the runtime parameters, continuing to execute the software container in the selected runtime environment; and and in response to determining using a second machine learning model that the selected runtime environment does not match the runtime parameters, executing the software container in a different runtime environment that matches both the static parameters and the runtime parameters. A computer program that performs the following:

17. the computer-readable storage medium comprises: When executed by the computer, the computer monitoring the performance of the software container during runtime; updating the first machine learning model based on the performance; and updating the second machine learning model based on the performance; and 17. The computer program product of claim 16, further comprising additional program instructions to:

18. 20. The computer program product of claim 17, wherein the performance is monitored for at least central processing unit (CPU) usage, memory usage, and input / output (I / O) metrics.

19. the static parameters are preliminary static parameters, and the computer-readable storage medium is identifying real-time static parameters of the software container by analyzing the software container prior to the execution time; continuing to execute the software container in the selected runtime environment in response to determining, using a second machine learning model, that the selected runtime environment matches both the real-time static parameters and the runtime parameters; and executing the software container in the different runtime environment in response to determining, using a second machine learning model, that the selected runtime environment does not match the real-time static parameters and the runtime parameters; and 19. A computer program product as claimed in any one of claims 16 to 18, comprising additional program instructions which, when executed by the computer, cause the computer to:

20. the computer-readable storage medium comprises: identifying one or more updates to either the real-time static parameters or the runtime parameters by analyzing the software container during runtime, subsequent to identifying the runtime parameters and according to a predetermined schedule; continuing to execute the software container in the selected runtime environment in response to determining, using a second machine learning model, that the update causes the selected runtime environment to match both the real-time static parameters and the runtime parameters; and executing the software container in the different runtime environment in response to determining, using a second machine learning model, that the selected runtime environment does not match the real-time static parameters and the runtime parameters due to the update information; and 20. The computer program product of claim 19, further comprising additional program instructions which, when executed by said computer, cause said computer to:

Images