Container-based applications

Abstract

A method, computer program product, and system for adjusting a container-based application are provided. A processor may receive one or more function calls at a container-based application. The processor may process the one or more function calls using the container-based application. The processor may obtain performance data from the container-based application based on the processing of the one or more function calls. The processor may analyze the performance data against performance measurement constraints. The processor may adjust aspects of the container-based application based on the analysis of the performance data. The aspects may be one or more selected from the group consisting of resources and functionality of the container-based application.

Description

Background Art

[0001] The present disclosure relates to container-based applications, and more particularly to tuning container-based applications.

[0002] By design, cloud-native applications (such as container-based applications) are designed to grow and consume system resources based on increased workload / demand. While this scalability is desirable in many cases, it is undesirable for services to become unavailable due to meeting system constraints. For example, an application may reach a scaling limit, which can be a hard limit (related to hardware capabilities) or a soft limit (related to the application's resource allocation), where adding additional computing power will no longer allow the application to process additional incoming requests. In other words, at this point the application can no longer scale up to meet demand. In this case, when processing resources become available, a typical application queues any new requests to be processed later, thereby increasing the latency of the system. Summary of the Invention

[0003] Embodiments of the present disclosure provide methods, computer program products, and systems for adjusting container-based applications. A processor may receive one or more function calls at a container-based application. The processor may use the container-based application to process the one or more function calls. The processor may obtain performance data from the container-based application based on the processing of the one or more function calls. The processor may analyze the performance data against performance measurement constraints. The processor may adjust aspects of the container-based application based on the analysis of the performance data. The aspects may be one or more selected from the group consisting of resources and functions of the container-based application.

[0004] BRIEF DESCRIPTION OF THE DRAWINGS

[0005] The accompanying drawings included in this disclosure are incorporated into and form a part of the specification. They illustrate embodiments of the present disclosure and, together with the description, serve to explain the principles of the present disclosure. The accompanying drawings are only illustrative of typical embodiments and do not limit the present disclosure.

[0006] Figure 1 A cloud computing environment according to embodiments of the present disclosure is depicted.

[0007] Figure 2 Abstract model layers according to embodiments of the present disclosure are described.

[0008] Figure 3 A flowchart illustrating an example process for scaling a container-based application according to an embodiment of the present disclosure is shown.

[0009] Figure 4 Depicted are graphical representations of the inflection points of the curves according to embodiments of the present disclosure.

[0010] Figure 5 A high-level block diagram of an exemplary computer that can be used to implement one or more of the methods, tools, and modules described herein and any related functionality is shown, according to an embodiment of the present disclosure.

[0011] Although the embodiments described herein are subject to various modifications and alternative forms, details thereof have been shown by way of example in the drawings and will be described in detail. However, it should be understood that the specific embodiments described should not be construed as limiting. On the contrary, the present invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the present disclosure. DETAILED DESCRIPTION

[0012] It should be understood that the drawings are schematic and not drawn to scale.It should also be understood that the same reference numerals are used throughout the drawings to indicate the same or similar parts.

[0013] In the context of this application, when an embodiment of the present disclosure constitutes a method, it should be understood that such a method is a process for being performed by a computer, that is, a computer-implemented method. Therefore, the various steps of the method reflect various parts of a computer program, such as various parts of one or more algorithms.

[0014] Moreover, in the context of the present application, a (processing) system may be a single device or a collection of distributed devices suitable for performing one or more embodiments of the method of the present disclosure. For example, a system may be a personal computer (PC), a server, or a collection of PCs and / or servers connected via a network such as a local area network, the Internet, etc., to collaboratively perform at least one embodiment of the method of the present disclosure.

[0015] It should be understood that although the present disclosure includes detailed descriptions about cloud computing, the implementation of the teachings cited herein is not limited to cloud computing environments. Instead, the embodiments of the present disclosure can be implemented in conjunction with any other type of computing environment now known or later developed.

[0016] Cloud computing is a service delivery model 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 quickly provisioned and released with minimal management effort or interaction with the service provider. The cloud model can include at least five characteristics, at least three service models, and at least four deployment models.

[0017] Features are as follows:

[0018] On-demand self-service: Cloud consumers can unilaterally and automatically provision computing capabilities, such as server time and network storage, as needed, without requiring human interaction with the service provider.

[0019] Broad Network Access: Capabilities are available over the network and accessed through standard mechanisms that facilitate the use of heterogeneous thin-client or thick-client platforms (e.g., mobile phones, laptops, and PDAs).

[0020] Resource pooling: A provider's computing resources are pooled to serve multiple consumers using a multi-tenant model, where different physical and virtual resources are dynamically assigned and reassigned as needed. There is a sense of location independence, as consumers typically do not have control or knowledge of the exact location of the provided resources, but may be able to specify the location at a higher level of abstraction (e.g., country, state, or data center).

[0021] Rapid elasticity: The ability to quickly and elastically provision capacity, in some cases automatically scaling down and releasing capacity to scale up quickly. To the consumer, the capacity available for provisioning typically appears unlimited and can be purchased in any quantity at any time.

[0022] Metered Services: Cloud systems automatically control and optimize resource usage by leveraging metering capabilities at a 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 utilized services.

[0023] The service model is as follows:

[0024] Software as a Service (SaaS): The ability provided to consumers is to use the provider's applications running on a cloud infrastructure. Applications are accessible from various client devices through a thin client interface such as a web browser (e.g., web-based email). Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, storage, or even individual application capabilities, with the possible exception of limited user-specific application configuration settings.

[0025] Platform as a Service (PaaS): The capability provided to consumers is to deploy applications created or acquired using programming languages and tools supported by the provider onto cloud infrastructure. Consumers do not manage or control the underlying cloud infrastructure, including networks, servers, operating systems, or storage, but do have control over the deployed applications and the configuration of the application hosting environment.

[0026] Infrastructure as a Service (IaaS): The capabilities provided to consumers are processing, storage, networking, and other basic computing resources on which consumers can deploy and run arbitrary software, including operating systems and applications. Consumers do not manage or control the underlying cloud infrastructure, but rather have control over the operating system, storage, deployed applications, and potentially limited control over selected networking components (e.g., host firewalls).

[0027] The deployment model is as follows:

[0028] Private cloud: Cloud infrastructure is operated solely for an organization. It can be managed by the organization or a third party and can exist on-premises or off-premises.

[0029] Community cloud: Cloud infrastructure is shared by several organizations and supports a specific community with shared concerns (e.g., mission, security requirements, policies, and compliance considerations). It can be managed by the organization or a third party and can exist on-premises or off-premises.

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

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

[0032] Cloud computing environments are service-oriented and focus on statelessness, low coupling, modularity, and semantic interoperability. The core of cloud computing is the infrastructure that consists of a network of interconnected nodes.

[0033] The illustrative embodiments provide concepts for adjusting container-based applications, and more specifically, adjusting resources or functionality of container-based applications. The concepts may include: receiving one or more function calls at the container-based application; processing the one or more function calls using the container-based application; obtaining performance data from the container-based application based on the processing of the one or more function calls; analyzing the performance data against performance measurement constraints; and adjusting resources and / or functionality of the container-based application based on the analysis of the performance data.

[0034] Embodiments include concepts for adjusting container-based applications in response to a comparison between obtained performance data and predefined performance measurement limits. Evaluation of performance measurement limits can be based on analysis of performance data obtained from the container-based application when processing function calls.

[0035] Embodiments may enable a container-based application to receive one or more function calls and adjust functionality or resources of the application by analyzing a set of performance data obtained from the application when processing the function calls. The functionality or resources may be adjusted when a performance measurement limit is determined to have been reached or when a performance measurement is determined to be reached within a predetermined time period.

[0036] In this manner, the present disclosure may provide a means of adjusting container-based applications in response to a comparison between performance data and performance measurement limits.

[0037] For example, when a measure of the performance of an application exceeds a given limit (such as the time taken to process a function call exceeds a time limit), the application's resources or functionality can be adjusted. Similarly, when a measure of the performance of an application indicates that performance will exceed a given limit within a given time period, the application's resources or functionality can be adjusted. In typical container-based applications, any adjustments to application parameters are typically determined before the application begins running, which means that typical container-based applications cannot dynamically adjust their behavior, for example, in response to an unexpectedly heavy processing load. In some cases, the problem cannot be solved by simply allocating more computing power to process function calls.

[0038] Thus, by analyzing the performance of an application, performance measurements can be used to adjust functionality or resources of the application to allow further function calls to be processed that would otherwise be queued and incur wait times.

[0039] The container-based application can therefore dynamically obtain and analyze performance data related to processing received function calls and adjust the functions or resources of the container-based application accordingly.

[0040] Embodiments may provide for adjusting resources or functionality of a container-based application based on analysis of performance data obtained from the container-based application.

[0041] Containers are packages that rely on virtual isolation to deploy and run applications that access a shared operating system kernel without the need for virtual machines. Container-based applications are any software applications that can run on a system using containers.

[0042] In an embodiment, analyzing the performance data against the performance measurement limit includes determining whether the performance measurement limit has been reached or whether the performance measurement limit will be reached within a given time period. In this way, container-based applications can be dynamically adjusted based on current or predicted demand.

[0043] In one embodiment, analyzing the performance data includes: determining a processing time for processing the one or more function calls; and identifying a curve inflection point based on the analyzed performance data, wherein the curve inflection point is identified if the processing time exceeds a predetermined threshold. The curve inflection point can be used to identify a sharp increase in the performance measure. In this case, the curve inflection point can be used to identify a sharp increase in the time spent processing the function call (e.g., a sharp increase in wait time).

[0044] Inflection points can be identified from inflection point features within performance data (e.g., performance data plotted as a graph of two variables, such as a number of function calls and the time to process each function call). Inflection point features can be identified as any change, such as a point at which an increase or decrease in a given variable occurs.

[0045] For example, when a given number of function calls are received, the time spent processing the function calls may increase. The point at which this increase occurs in this relationship can be identified as a curve inflection point feature. In a specific example, if the increase is determined to be an exponential increase, the point at which the increase occurs can simply be identified as a curve inflection point feature. The same is true for a decrease in a given variable of the performance data. In other words, a curve inflection point can be identified by a curve inflection point feature that indicates a change in a variable of the performance data. In this way, a curve inflection point can be identified based on a change in the relationship between the variables of the performance data.

[0046] In one embodiment, the performance measurement constraints include one or more of the following: scalability constraints, wherein the scalability constraints include one or more of the following: physical resource constraints; virtual resource constraints; container resource constraints; and predefined scaling constraints; cost constraints; responsiveness constraints; CPU utilization per execution; CPU utilization of the container; memory utilization; network throughput; network latency; storage throughput; storage latency; request response time; number of transactions per second (or other agreed-upon time period); and failure rate. In this way, various performance measurement constraints may be employed depending on the implementation of the container-based application.

[0047] In one embodiment, the resources include one or more of: computing resources; and execution architecture resources. In this way, the adjusted resources can take a form suitable for a given scenario.

[0048] In one embodiment, the execution architecture resources include one or more of the following: Software as a Service architecture; and Function as a Service architecture. In this way, applications can take advantage of readily available execution architectures.

[0049] In an embodiment, the functionality includes front-end functionality, including one or more of the following: a plurality of displayed data; a plurality of permitted complex transactions; and a plurality of available application options. Thus, the front-end functionality can be adjusted in various ways according to the implementation of the application.

[0050] In one embodiment, the functionality includes backend functionality, wherein the backend functionality includes one or more of: multiple synthetic transactions; multiple log records; multiple synchronous transactions; and multiple asynchronous transactions. In this way, the backend functionality can be adjusted in various ways depending on the implementation of the application.

[0051] In an embodiment, adjusting the functionality of the container-based application includes using the front-end functionality to execute the back-end functionality. In this way, the back-end functionality can be retained for increased back-end performance.

[0052] Modifications and additional steps to traditional container-based applications may also be proposed, which may enhance the value and practicality of the proposed concept.

[0053] The illustrative embodiments can be utilized in many different types of data processing environments. To provide context for the description of the elements and functions of the illustrative embodiments, the following is provided. Figure 1 and Figure 2 As an example environment in which aspects of the illustrative embodiments may be implemented. It should be understood that Figure 1 and Figure 2 This is merely an example and is not intended to assert or imply any limitation with regard to the environments in which aspects or embodiments of the present disclosure may be implemented. Many modifications to the depicted environments may be made without departing from the spirit and scope of the present disclosure.

[0054] Now see Figure 1 , an illustrative cloud computing environment 50 is described. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10 with which a local computing device used by a cloud consumer can communicate, such as, for example, a personal digital assistant (PDA) or cellular phone 54A, a desktop computer 54B, a laptop computer 54C, and / or an automobile computer system 54N. The nodes 10 can communicate with each other. They can be grouped physically or virtually (not shown) in one or more networks, such as a private cloud, community cloud, public cloud, or hybrid cloud, or a combination thereof, as described above. This allows the cloud computing environment 50 to provide infrastructure, platform, and / or software as a service for which the cloud consumer does not need to maintain resources on a local computing device. It should be understood that Figure 1The types of computing devices 54A-N shown in are intended to be illustrative only, and computing node 10 and cloud computing environment 50 may communicate with any type of computerized device over any type of network and / or network-addressable connection (eg, using a web browser).

[0055] Now see Figure 2 , showing the cloud computing environment 50 ( Figure 1 ) provides a set of functional abstraction layers. It should be understood in advance that Figure 2 The components, layers, and functions shown in are intended to be illustrative only, and the embodiments of the present disclosure are not limited thereto. As described, the following layers and corresponding functions are provided:

[0056] The hardware and software layer 60 includes hardware and software components. Examples of hardware components include: mainframes 61; servers based on RISC (Reduced Instruction Set Computer) architecture 62; servers 63; blade servers 64; storage devices 65; and network and networking components 66. In some embodiments, software components include web application server software 67 and database software 68.

[0057] 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 73 , including virtual private networks; virtual applications and operating systems 74 ; and virtual clients 75 .

[0058] In one example, the management layer 80 may provide the functionality described below. Resource provisioning 81 provides dynamic procurement of computing and other resources for performing tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking when utilizing resources within the cloud computing environment and bills or invoices the consumption of these resources. In one example, these resources may include application software licenses. Security provides authentication for cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides access to the cloud computing environment for consumers and system administrators. 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 pre-arrangement and procurement of cloud computing resources in anticipation of future demand according to the SLA.

[0059] The workload layer 90 provides examples of functionality that can utilize a cloud computing environment. Examples of workloads and functionality that can be provided from this layer include: mapping and navigation 91; software development and lifecycle management 92; virtual classroom education delivery 93; data analytics processing 94; transaction processing 95; and any other suitable functions 96.

[0060] In an embodiment, a method for managing container-based applications may be deployed in the management layer 80 .

[0061] Now see Figure 3 , a flow chart of an example process 300 for adjusting a container-based application according to an embodiment of the present disclosure is shown. The process 300 begins at step 310, where one or more function calls are received at a container-based application.

[0062] At step 320, the received one or more function calls are processed by the container-based application. For example, the container-based application may be deployed in a cloud-based environment, such as Figure 1 and Figure 2 The cloud computing environment 50 is described in detail in FIG.

[0063] Typically, applications deployed in containers are designed to scale to the predefined resources of a given environment. These resources can be physical, virtual, or artificial. Once these resources are exhausted, additional function calls are queued for processing, increasing application latency.

[0064] At step 330 , performance data is obtained from the container-based application based on processing of the one or more function calls.

[0065] Containers for container-based applications are typically managed by placing them on worker nodes, the grouping of which can be called a pod, and employing management software to manage these containers. Typically, the management software does not provide tracking, logging, or metrics about the containers. However, there are various tools that perform this function, often called service meshes, which deploy a sidecar to each container. Such tools can be used to obtain performance data from each container. It should be noted that as long as containers are involved in most functions, this is serverless monitoring.

[0066] For example, you can run container-based applications from Performance data is obtained from the address space. Linux is a registered trademark of Linus Torvalds in the U.S., other countries, or both.

[0067] At step 340, the performance data is analyzed against the performance measurement constraints.

[0068] The analyzing of the performance data may include determining a processing time for processing the one or more function calls and identifying an inflection point of the curve based on the analyzed performance data, wherein the inflection point of the curve is identified if the processing time exceeds a predetermined threshold.

[0069] By analyzing the performance data, it is possible to identify when a container-based application has been extended to, for example, the maximum hardware potential. This can be performed, for example, by utilizing the inflection points of the performance data curve. Figure 4 This technique is further described in detail.

[0070] In addition to using hardware capabilities as a performance measurement limit, it is also possible to determine when a maximum cost limit has been reached, which is related to the financial cost of running a container-based application in a given processing environment. In this case, the resources can be execution architecture resources and can be adjusted to utilize an alternative environment (for example, adjusting from a Software as a Service (SAAS) architecture to a Function as a Service (FAAS) architecture).

[0071] In an embodiment, process 300 may proceed to step 350 where it is determined whether a performance measurement limit has been reached based on the analysis of the performance data. A performance measurement limit may be any measurable limit that indicates a change in the performance of a container-based application.

[0072] As an example, the performance measurement limit can be a scalability limit, which is a performance measurement limit related to the conventional ability of such an application to scale to meet increases in processing demand. In this way, when the scalability limit is reached, the container-based application can no longer scale to meet workload demands.

[0073] An example of a scalability limitation may be a physical resource limitation. Physical resource limitations may relate to the physical limitations of the underlying physical infrastructure of the system executing the container-based application, such as the physical limitations of the servers hosting the cloud processing environment. Physical limitations may relate to, for example, the CPU of the underlying architecture, the memory of the underlying architecture, the disk of the underlying architecture, the network of the underlying architecture, and so on.

[0074] Another example of a scalability limitation may be a virtual resource limitation, where the virtual resource limitation may, for example, relate to limitations on a virtual machine (VM) on which a container-based application or an aspect of a container-based application may run. The virtual limitation may, for example, relate to the VM's CPU allocation, the VM's allocated memory, the VM's disk allocation, the VM's network, etc.

[0075] Another example of a scalability limit can be a container resource limit, which can be similar to the limits described above with reference to virtual resource limits. Container resource limits relate to limits on individual containers, which can, for example, relate to a container's CPU allocation, a container's allocated memory, a container's disk allocation, a container's network, and so on.

[0076] Another example of a scalability limit may be a predefined scaling limit, where the predefined scaling limit may be a limit related to the required resource consumption level of the container-based application, rather than a limit defined by the maximum hardware (virtual or other) capabilities. Such a predefined scaling limit may be designed to limit the amount of resources that an application may consume, for example, to avoid unexpected costs.

[0077] As referenced below Figure 4As further described, scalability limitations can be assessed by identifying inflection points based on performance data obtained from container-based applications.

[0078] Another example of a performance measurement constraint may be a cost constraint, as described above. For example, there may be a cost associated with the amount of processing system resources consumed to process a received function call. If this cost exceeds a given amount, the functionality or resources of the container-based application may be adjusted to maintain the cost of running the application at the given amount.

[0079] Another example of a performance measurement limit could be a responsiveness limit, which relates to the amount of time it takes to process a given function call. For example, if the function call processing time exceeds a given amount, e.g., the application becomes unresponsive to new function calls, resources or functionality can be adjusted to improve the responsiveness of the container-based application.

[0080] For example, responsiveness limits can be reached because scalability limits are also reached. In other words, when scalability limits are reached, the application may not scale up to meet processing demands, so additional function calls may be queued, reducing the application's responsiveness. Alternatively, the autoscaling / provisioning process may be unable to provision additional containers in response to increased workload demand, causing the responsiveness limit to be reached before the scalability limit is reached.

[0081] Performance measurement limits may also relate to the overall utilization of the underlying physical computing resources and / or virtual machine resources (i.e., data not typically exposed to the container) running the container itself. While the container may not see the specific details of external resources or resource utilization as part of the performance data, the container may recognize that it cannot satisfy the incoming workload (e.g., due to resource exhaustion or reaching a performance measurement limit).

[0082] Each of the limits discussed above, and any other limits suitable for monitoring the performance of an application, can be monitored by analyzing and evaluating performance data to automatically adjust the capabilities and / or features provided by the application service to maximize availability and, for example, the number of concurrent requests that can be processed within a dynamic but finite pool of processing capacity, cost factors, and curve inflection point constraints.

[0083] Furthermore, the above constraints can be used in any combination with each other to adjust the resources / functionality of container-based applications.

[0084] In an embodiment, the analysis and evaluation of performance data can be performed by a cognitive engine. The cognitive engine can take into account known characteristics of the broader computing platform. Such details are not typically exposed to containers and can include resources such as physical host resource usage, workloads of other containers, or other virtual machines.

[0085] Furthermore, the cognitive engine can consider the workload optimization characteristics of the container to predict whether the performance measurement limit is likely to be hit or has already been hit due to historical workload characteristics. For example, it can be known that the resource demand of the application doubles between 2 am and 7 am on the second Sunday of each month.

[0086] The cognitive engine can then predict the utilization of the container in question. For example, if a client only purchased N resources for the month, and running the application with all enabled features would only last until the 23rd of the month, rather than the service being completely unavailable when the resource allocation is exhausted, the cognitive engine can investigate the projected availability of the application if its functionality is reduced. In a specific example, the cognitive engine can determine whether the banking application can be sustained until the end of the month (e.g., extending resources for an additional week) if the display of the active balance is no longer automatic and requires user input to be displayed.

[0087] Different rules can be applied to the performance data to determine adjustments to the application's resources / functions, such as scaling and performance. The results of the determinations and their impact on application availability and performance can be stored in a database.

[0088] If it is determined at step 350 that the performance measurement limit has been reached, process 300 proceeds to step 360. At step 360, resources or functionality of the container-based application are adjusted based on the analysis of the performance data.

[0089] The adjusted resources may include computing resources used by the container-based application. The computing resources may include, for example, CPU usage, memory usage, disk usage, network usage, etc.

[0090] The adjusted resources may further include execution architecture resources, which may include a software-as-a-service architecture and / or a function-as-a-service architecture.

[0091] By their nature, cloud-native applications such as container-based applications may be unaware of the underlying execution architecture and system resources (although, like any application, they do run on hardware.) Therefore, these factors can be used to dynamically adjust the execution of SAAS-based applications and migration from SAAS to FAAS.

[0092] The adjusted functionality may include a front-end functionality, wherein the front-end functionality may include: a plurality of displayed data; a plurality of permitted complex transactions; and a plurality of available application options.

[0093] In other words, based on a determination that performance measurement limits have been reached and functionality of the container-based application must be reduced / removed to preserve service and maximize throughput (processing of received function calls), different functions may be adjusted within the application logic.

[0094] For example, preloaded data can be replaced with an option for the user to explicitly request that data when needed, thereby reducing the amount of unnecessary data displayed to the user. Further, the total amount of data displayed to the user can be limited (and / or preloaded), for example by reducing content such as video and / or image quality. In addition, complex transactions typically performed by an application can be removed. In yet another example, options can be removed from menus typically available to the user, particularly options that may result in the execution of complex transactions.

[0095] The functionality may also include backend functionality, wherein the backend functionality may include: a plurality of synthetic transactions; a record amount; a plurality of synchronous transactions; and a plurality of asynchronous transactions.

[0096] In this way, backend service functionality including features not directly exposed to end users can be adjusted as a result of a determination that a performance measurement limit has been reached. For example, a container-based application can switch from synchronous to asynchronous transactions by queuing the transactions for batch processing at a later time.

[0097] Further, adjusting the functionality of the container-based application may include using the front-end functionality to perform the back-end functionality.

[0098] For example, backend services can "call forward" to frontend services to automatically reduce functionality and thereby preserve backend processing capacity. For example, long-running overnight batch operations can trigger the expected reduction of frontend service functionality through FAAS to reduce the load from online (real-time) processing.

[0099] After step 360, process 300 may return to step 310 and process 300 may proceed as described above. If it is determined at step 350 that the performance measurement limit has not been reached, process 300 may proceed to step 355 where it is determined based on analysis of the performance data whether the performance measurement limit is reached within a given time limit.

[0100] In other words, analysis of the performance data may indicate that a performance measurement limit will be reached by the application within a given time period. If it is determined that the performance measurement limit will be reached within a predetermined amount of time, process 300 may proceed to step 360, where resources and / or functionality may be adjusted to account for the predicted performance of the application. It should be noted that the above-described methods of analyzing performance data and various performance measurement limits may be equally applied to determining whether a performance measurement limit will be reached within a given time period.

[0101] If, at step 355, it is determined that the performance measurement limit has not been reached within the given time period, process 300 may return to step 310 and proceed as described above.

[0102] In summary, the present disclosure can analyze and evaluate the performance of applications and provide dynamic adjustment of resources / functions to maximize availability and the number of concurrent requests that can be processed. In other words, the present disclosure can provide a service to limit the ability to increase available resources to avoid hardware issues that are at the inflection point of the curve available to process new or future incoming end-user requests.

[0103] Now refer to Figure 4 , shows a graphical representation 400 of a curve inflection point according to an embodiment of the present disclosure. The graph 400 is shown to exhibit a curve 410 described by a function xy=sin(x+y), where x>0, in order to demonstrate the curve inflection point principle.

[0104] In this example, the x-axis may represent the number of function calls received by the container-based application, and the y-axis may represent the time taken to process the function call. In general, the x-axis may represent demand for the application and the y-axis may represent performance measures.

[0105] The inflection point 420 is defined as the area of the curve where there is an exponential change. In the current example, the inflection point is the exponential increase in the time it takes to process a function call. Generally speaking, the inflection point can be understood as the point where the performance measurement limit of the application (e.g., scalability limit) is reached.

[0106] Mathematically, the inflection point of the curve can be described with reference to plot 430 .

[0107] Orthogonal vectors N and T are shown for a first point 440 on the curve and a second point 450 on the curve. The vector at the second point 450 is translated and overlaid (shown in dashed lines) on the first point 440. The change in vector T, δT, between the first and second points is shown.

[0108] To calculate the characteristic inflection points in performance data, δT can be compared between three points to identify the onset of exponential CPU time, which typically accompanies a drop in transaction completion or even a timeout. At this point, the container-based application's resources or functionality can be adjusted, for example by removing the container from service and migrating it to a FaaS architecture. Conversely, a flat δT can encourage the application to use more containers until an optimal (fluctuation) point is identified and executed.

[0109] Note that in the above mathematics, it is assumed that the conventional system as a whole behaves as a serial bottleneck. δT is determined as the point at which the peak is typically an exponential rise and is associated with the inflection point of the curve.

[0110] By calculating the inflection point of the curve based on the obtained performance data, the future performance of the application can be determined, thereby providing a means of predicting when the performance measurement limit may be reached within a given time period.

[0111] Now refer to Figure 5, shows a high-level block diagram of an exemplary computer 500 that can be used to implement one or more of the methods, tools, and modules described herein and any related functionality according to an embodiment of the present disclosure. The various operations discussed above can utilize the capabilities of the computer 500. For example, one or more portions of the system for generating text response data by analyzing response text can be incorporated into any element, module, application, and / or component discussed herein.

[0112] Computer 500 includes, but is not limited to, a PC, a workstation, a laptop computer, a PDA, a handheld device, a server, a storage device, and the like. Generally, in terms of hardware architecture, computer 500 may include one or more processors 510, a memory 520, and one or more I / O devices 570 communicatively coupled via a local interface (not shown). The local interface may be, for example, but not limited to, one or more buses or other wired or wireless connections, as known in the art. The local interface may have additional elements, such as controllers, buffers (caches), drivers, repeaters, and receivers, to enable communication. Further, the local interface may include address, control, and / or data connections to enable appropriate communication between the above components.

[0113] Processor 510 is a hardware device for executing software that may be stored in memory 520. Processor 510 may be virtually any custom or commercial processor, a central processing unit (CPU), a digital signal processor (DSP), or auxiliary processor among several processors associated with computer 500, and may be a semiconductor-based microprocessor (in the form of a microchip) or a microprocessor.

[0114] The memory 520 may include any one or a combination of volatile memory elements (e.g., random access memory (RAM), such as dynamic random access memory (DRAM), static random access memory (SRAM), etc.) and non-volatile memory elements (e.g., ROM, erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic tape, compact disk read-only memory (CD-ROM), disk, magnetic disk, cassette, cartridge, etc.). In addition, the memory 520 may incorporate electronic, magnetic, optical, and / or other types of storage media. Note that the memory 520 may have a distributed architecture in which different components are located remotely from each other but can be accessed by the processor 510.

[0115] The software in the memory 520 may include one or more separate programs, each of which includes an ordered list of executable instructions for implementing logical functions. According to an exemplary embodiment, the software in the memory 520 includes a suitable operating system (O / S) 550, a compiler 540, source code 530, and one or more applications 560. As shown, the application 560 includes multiple functional components for implementing the features and operations of the exemplary embodiments. The application 560 of the computer 500 can represent different applications, computing units, logic, functional units, processes, operations, virtual entities, and / or modules according to the exemplary embodiments, but the application 560 is not meant to be limiting.

[0116] Operating system 550 controls the execution of other computer programs and provides scheduling, input-output control, file and data management, memory management, and communication control and related services. The inventors contemplate that application program 560 for implementing the exemplary embodiments will be applicable to all commercially available operating systems.

[0117] Application 560 can be a source program, an executable program (object code), a script, or any other entity including a set of instructions to be executed. When it is a source program, the program is typically translated via a compiler (such as compiler 540), an assembler, an interpreter, etc., which may or may not be included in memory 520 to operate appropriately in conjunction with O / S 550. I / O devices 570 may include input devices such as, but not limited to, a mouse, a keyboard, a scanner, a microphone, a camera, etc. In addition, I / O devices 570 may also include output devices such as, but not limited to, a printer, a display, etc. Finally, I / O devices 570 may also include devices that transmit both input and output, such as, but not limited to, a NIC or a modulator / demodulator (for accessing remote devices, other files, devices, systems, or networks), a radio frequency (RF) or other transceiver, a telephone interface, a bridge, a router, etc. I / O devices 570 also include components for communicating on different networks (such as the Internet or an intranet).

[0118] If the computer 500 is a PC, workstation, smart device, etc., the software in the memory 520 may also include a basic input and output system (BIOS) (omitted for simplicity). The BIOS is a collection of basic software routines that initialize and test the hardware at startup, start the O / S 550, and support data transfer between hardware devices. The BIOS is stored in some type of read-only memory (such as ROM, PROM, EPROM, EEPROM, etc.) so that it can be executed when the computer 500 is activated.

[0119] When computer 500 is running, processor 510 is configured to execute software stored in memory 520, transfer data to and from memory 520, and generally control the operation of computer 500 in accordance with the software. Applications 560 and O / S 550 are read in whole or in part by processor 510, possibly buffered within processor 510, and then executed.

[0120] While application 560 is implemented in software, it should be noted that application 560 can be stored on virtually any computer-readable medium for use by or in conjunction with any computer-related system or method. In the context of this document, a computer-readable medium can be an electronic, magnetic, optical, or other physical device or means that can contain or store a computer program for use by or in conjunction with a computer-related system or method.

[0121] Application 560 may be implemented in any computer-readable medium for use by or in conjunction with an instruction execution system, apparatus, or device, such as a computer-based system, a system containing a processor, or other system that can retrieve instructions from an instruction execution system, apparatus, or device and execute the instructions. In the context of this document, a "computer-readable medium" can be any means that can store, communicate, propagate, or transport a program for use by or in conjunction with an instruction execution system, apparatus, or device. A computer-readable medium can be, for example, but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, device, or propagation medium.

[0122] In the context of this application, when an embodiment of the present disclosure constitutes a method, it should be understood that such a method is a process for execution by a computer, i.e., a computer-implementable method. Therefore, the various steps of the method reflect various parts of a computer program, such as various parts of one or more algorithms.

[0123] The present invention may be a system, method and / or computer program product of any possible degree of technical detail integration. The computer program product may include a computer-readable storage medium (or multiple media) having computer-readable program instructions thereon for causing a processor to execute various aspects of the present invention.

[0124] Computer-readable storage media can be a tangible device that can retain and store instructions for use by an instruction execution device. Computer-readable storage media can 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 thereof. A non-exhaustive list of more specific examples of computer-readable storage media includes the following: a portable computer disk, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or flash memory), a static random access memory (SRAM), a portable compact disc read-only memory (CD-ROM), a digital versatile disc (DVD), a memory stick, a floppy disk, a mechanical encoding device such as a punch card, or a protruding structure in a groove with instructions recorded thereon, and any suitable combination thereof. As used herein, computer-readable storage media should not be interpreted as a temporary signal itself, such as a radio wave or other freely propagating electromagnetic wave, an electromagnetic wave propagated by a waveguide or other transmission medium (for example, a light pulse passing through an optical fiber cable), or an electrical signal emitted by a wire.

[0125] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to a corresponding computing / processing device via a network (e.g., the Internet, a local area network, a wide area network, and / or a wireless network), or downloaded to an external computer or external storage device. The network can include copper transmission cables, optical transmission fibers, wireless transmissions, routers, firewalls, switches, gateway computers, and / or edge servers. The 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 to be stored in a computer-readable storage medium within the corresponding computing / processing device.

[0126] The computer-readable program instructions for performing the operation of the present invention can be assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data, the configuration data of integrated circuit or source code or object code written in any combination of one or more programming languages, these programming languages include object-oriented programming languages (such as Smalltalk, C++ etc.) and process programming languages (such as " C " programming languages or similar programming languages). The computer-readable program instructions can be performed completely on the user's computer, partly on the user's computer, performed as an independent software package, partly on the user's computer, partly on a remote computer or fully on a remote computer or server. In the latter case, the remote computer can be connected to the user's computer by any type of network (including local area network (LAN) or wide area network (WAN)), or can be connected to an external computer (for example, using an internet service provider through the internet). In certain embodiments, the electronic circuit comprising for example programmable logic circuit, field programmable gate array (FPGA) or programmable logic array (PLA) can make the electronic circuit personalized to perform computer-readable program instructions by utilizing the state information of computer-readable program instructions, so as to perform various aspects of the present invention.

[0127] The present invention will be described below with reference to flowcharts and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. It should be understood that each block of the flowcharts and / or block diagrams, and combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0128] These computer-readable program instructions can be provided to a processor of a computer or other programmable data processing device to produce a machine, so that the instructions executed by the processor of the computer or other programmable data processing device create a device for implementing the functions / actions specified in the flowchart and / or block diagram or multiple blocks. These computer-readable program instructions can also be stored in a computer-readable storage medium, and these instructions cause the computer, programmable data processing device, and / or other equipment to operate in a specific manner. Thus, the computer-readable storage medium having the instructions stored therein includes an article of manufacture containing instructions that implement aspects of the functions / actions specified in the flowchart and / or block diagram or multiple blocks.

[0129] Computer-readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device, so that a series of operational steps are performed on the computer, other programmable apparatus, or other device to produce computer-implemented processing, so that the instructions executed on the computer, other programmable apparatus, or other device implement the functions / actions specified in the flowchart and / or block diagram or multiple boxes.

[0130] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functions and operations of possible implementations of the systems, methods and computer program products according to different embodiments of the present invention. To this end, each box in the flowchart or block diagram may represent a module, segment or portion of an instruction, which includes one or more executable instructions for implementing a specified logical function. In some alternative implementations, the functions marked in the box may not occur in the order marked in the figure. For example, the two boxes shown in succession can actually be completed as a step, performed simultaneously, substantially simultaneously, in a partially or completely time-overlapping manner, or the boxes can sometimes be performed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of the boxes in the block diagram and / or flowchart, can be implemented with a dedicated hardware-based system that performs a specified function or action or performs a combination of dedicated hardware and computer instructions.

[0131] The description of the various embodiments of the present disclosure has been presented for illustrative purposes and is not intended to be exhaustive or limited to the disclosed embodiments. Many modifications and variations will be apparent to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is selected to best explain the principles of the embodiments, practical applications, or technical improvements over technologies found in the marketplace, or to enable those of ordinary skill in the art to understand the embodiments disclosed herein.

[0132] The present disclosure provides a method for adjusting a container-based application, wherein the container-based application is adapted to process one or more function calls. The method includes receiving one or more function calls at a container-based application and processing the one or more function calls using the container-based application. Based on the processing of the one or more function calls, performance data is obtained from the container-based application, and the performance data is analyzed against performance measurement constraints. Based on the analysis of the performance data, resources or functions of the container-based application are adjusted.

[0133] The present disclosure also seeks to provide a computer program product comprising computer program code for implementing the proposed concepts when executed on a processor.

[0134] The present disclosure also seeks to provide systems (such as processing devices and / or network components) suitable for executing the computer program code.

[0135] According to a further embodiment of the present disclosure, a computer program product for adjusting a container-based application is provided herein, wherein the container-based application is suitable for processing one or more function calls, the computer program product comprising a computer-readable storage medium having program instructions contained therewith, the program instructions being executable by a processing unit to cause the processing unit to perform a method comprising: receiving one or more function calls at a container-based application; processing the one or more function calls using the container-based application; obtaining performance data from the container-based application based on the processing of the one or more function calls; analyzing the performance data against performance measurement limits; and adjusting resources and / or functions of the container-based application based on the analysis of the performance data.

[0136] According to another aspect, a system for adjusting a container-based application is provided, wherein the container-based application is suitable for processing one or more function calls, the system comprising: a receiving unit adapted to receive one or more function calls; and a processing unit adapted to: process the one or more function calls using the container-based application; obtain performance data from the container-based application based on processing the one or more function calls; analyze the performance data against performance measurement limits; and adjust resources and / or functions of the container-based application based on the analysis of the performance data.

Claims

1. A computer-implemented method comprising: receiving one or more function calls at a container-based application; processing the one or more function calls using the container-based application; obtaining performance data from the container-based application based on processing the one or more function calls; Analyzing the performance data against performance measurement constraints, wherein analyzing the performance data comprises: determining a processing time for processing the one or more function calls; comparing the processing time to a predetermined threshold; and identifying, in response to the processing time exceeding the predetermined threshold, an inflection point of a curve based on the analyzed performance data, wherein the inflection point of the curve comprises an exponential change in a variable of the performance data and can be used to determine future performance of the application and predict a point in time when a performance measurement limit will be reached within a given time period; and Aspects of the container-based application are adjusted based on the analysis of the performance data by reducing an amount of displayed data, wherein the aspects are one or more selected from the group consisting of resources and functions of the container-based application.

2. The computer-implemented method of claim 1 , wherein: Analyzing the performance data against the performance measurement limit includes determining whether the performance measurement limit has been reached.

3. The computer-implemented method of claim 1 , wherein: Analyzing the performance data against the performance measurement limit includes determining whether the performance measurement limit will be reached within a predetermined time period.

4. The computer-implemented method of claim 1 , wherein: The performance measurement constraints are selected from the group consisting of: Scalability limitations, wherein the scalability limitations are selected from the group consisting of: physical resource limitations; Virtual resource limits; Container resource limits; and Predefined zoom limits; Cost constraints; Responsiveness limitations; CPU utilization per execution; The CPU utilization of the container; Memory utilization; Network throughput; Network latency; Storage throughput; Storage wait time; Request response time; Transactions per second; and Failure rate.

5. The computer-implemented method of claim 1 , wherein: Select the resource in question from the group consisting of: Computing resources; as well as Execute architecture resources.

6. The computer-implemented method of claim 1 , wherein: The resource is an execution architecture resource selected from the group consisting of: Software-as-a-Service architecture; and Function-as-a-Service architecture.

7. The computer-implemented method of claim 1 , wherein: The functionality comprises a front-end functionality selected from the group consisting of: Multiple displayed data; Multiple complex transactions are allowed; and Multiple application options available.

8. The computer-implemented method of claim 1 , wherein: The functionality comprises a backend functionality, wherein the backend functionality is selected from the group consisting of: Multiple composite transactions; Multiple records; Multiple simultaneous transactions; and Multiple asynchronous transactions.

9. The computer-implemented method of claim 1 , wherein: Adjusting the functionality of the container-based application includes executing the back-end functionality using the front-end functionality.

10. A computer program product comprising a computer-readable storage medium having program instructions embodied therein, wherein The computer-readable storage medium itself is not a transient signal, and the program instructions can be executed by a processor to cause the processor to perform a method comprising the following steps: receiving one or more function calls at a container-based application; processing the one or more function calls using the container-based application; obtaining performance data from the container-based application based on processing the one or more function calls; Analyzing the performance data against performance measurement constraints, wherein analyzing the performance data comprises: determining a processing time for processing the one or more function calls; comparing the processing time to a predetermined threshold; and identifying, in response to the processing time exceeding the predetermined threshold, an inflection point of a curve based on the analyzed performance data, wherein the inflection point of the curve comprises an exponential change in a variable of the performance data and can be used to determine future performance of the application and predict a point in time when a performance measurement limit will be reached within a given time period; and Aspects of the container-based application are adjusted based on the analysis of the performance data by reducing an amount of displayed data, wherein the aspects are one or more selected from the group consisting of resources and functions of the container-based application.

11. The computer program product according to claim 10, wherein: Analyzing the performance data against the performance measurement constraints includes: A determination is made as to whether the performance measurement limit will be reached within a predetermined time period.

12. The computer program product of claim 10, wherein: The performance measurement constraints are selected from the group consisting of: Scalability limitations, wherein the scalability limitations are selected from the group consisting of: physical resource limitations; Virtual resource limits; Container resource limits; and Predefined zoom limits; Cost constraints; Responsiveness limitations; CPU utilization per execution; The CPU utilization of the container; Memory utilization; Network throughput; Network latency; Storage throughput; Storage wait time; Request response time; Transactions per second; and Failure rate.

13. A system for scaling a container-based application, comprising: processor; as well as A computer-readable storage medium communicatively coupled to the processor and storing program instructions that, when executed by the processor, cause the processor to perform a method comprising: receiving one or more function calls at a container-based application; processing the one or more function calls using the container-based application; obtaining performance data from the container-based application based on processing the one or more function calls; Analyzing the performance data against performance measurement constraints, wherein analyzing the performance data comprises: determining a processing time for processing the one or more function calls; comparing the processing time to a predetermined threshold; and identifying, in response to the processing time exceeding the predetermined threshold, an inflection point of a curve based on the analyzed performance data, wherein the inflection point of the curve comprises an exponential change in a variable of the performance data and can be used to determine future performance of the application and predict a point in time when a performance measurement limit will be reached within a given time period; and An aspect of the container-based application is adjusted based on the analysis of the performance data by reducing an amount of displayed data, wherein the aspect is one or more selected from the group consisting of resources and functions of the container-based application.

14. The system according to claim 13, wherein: Analyzing the performance data against the performance measurement limit includes determining whether the performance measurement limit has been reached.

15. The system according to claim 13, wherein: Analyzing the performance data against the performance measurement limit includes determining whether the performance measurement limit will be reached within a given time period.

16. The system of claim 13, wherein: The functionality includes front-end functionality selected from the group consisting of: Multiple displayed data; Multiple complex transactions are allowed; and Multiple application options available.

17. The system of claim 13, wherein: The functionality includes backend functionality selected from the group consisting of: Multiple composite transactions; Multiple records; Multiple simultaneous transactions; and Multiple asynchronous transactions. 18 . A computer-readable storage medium having a program stored thereon, wherein when the program is executed on a computer, the program causes the computer to execute the method according to claim 1 .

Images