Complex Legacy Application Migration

Abstract

A set of network traffic between the plurality of legacy applications is monitored. A communication graph for the plurality of legacy applications is generated from the set of network traffic. A set of migratable applications within the plurality of legacy applications is identified from the communication graph. The set of migratable applications is migrated to a cloud edge layer and users are notified of the migration.

Description

[Technical Field]

[0001] The present disclosure relates generally to the field of application migration, and more particularly to migrating complex legacy applications. [Background technology]

[0002] Complex legacy applications can be commonplace in enterprise environments. These applications can be difficult to migrate because their components may have complex interconnections with other applications (legacy or otherwise). This can result in high operational costs and an inability to take advantage of new technologies such as cloud-based applications.

[0003] Current solutions for migrating complex legacy applications require manual engineering processes or the rewriting of critical components using new architectural paradigms such as containers, service-oriented architecture (SOA), or microservices. Alternatively, solutions have been proposed that integrate system layer rewrites that can move native applications to cloud mode, as long as the entire collection of applications and components can be migrated together. State-of-the-art techniques for moving entire applications to the cloud include using artificial intelligence (AI) for automated application refactoring.

[0004] The above approaches can only be successful if the application is relatively easy to move (e.g., the application has few dependencies on other applications) or if the migration does not change dependencies or other timing issues between multiple applications. Manual software engineering approaches are tedious, time-consuming, and prone to human error.

[0005] Current approaches simply don't work in real-world environments where many legacy components and applications have complex dependencies and implicit assumptions made by legacy components / applications, especially the timing of various interactions between applications, can make a company's entire application suite fragile and unstable. Summary of the Invention

[0006] An embodiment of the present disclosure includes a method for migrating a complex application. The method includes monitoring a set of network traffic between a plurality of legacy applications. From the set of network traffic, a communication graph for the plurality of legacy applications is generated. From the communication graph, a set of migratable applications within the plurality of legacy applications is identified. The set of migratable applications is migrated to a cloud edge layer and users are notified of the migration.

[0007] The method may further include monitoring a second set of network traffic occurring between the set of migratable applications and the remainder of the plurality of legacy applications. In response to the monitoring, it is determined that at least one timing error has occurred. A network rate control filter is introduced at the cloud edge layer. Criteria for the network rate control filter are based on the at least one timing error. A user is notified of the criteria.

[0008] Embodiments of the present disclosure include a computer program product for migrating complex applications. The computer program product includes a computer-readable storage medium embodying program instructions. The program instructions are executable by an apparatus and cause the apparatus to monitor a set of network traffic between a plurality of legacy applications. From the set of network traffic, a communication graph is generated for the plurality of legacy applications. From the communication graph, a set of migratable applications within the plurality of legacy applications is identified. The set of migratable applications is migrated to a cloud edge layer and a user is notified of the migration.

[0009] The program instructions of the computer program product further cause the apparatus to monitor a second set of network traffic occurring between the set of migratable applications and the remainder of the plurality of legacy applications. In response to the monitoring, it is determined that at least one timing error has occurred. A network rate control filter is deployed at the cloud edge layer. Criteria for the network rate control filter are based on the at least one timing error. A user is notified of the criteria.

[0010] An embodiment of the present disclosure includes a system for migrating complex applications. The system includes a memory subsystem having program instructions thereon and a processor in communication with the memory subsystem. The program instructions cause the processor to monitor a set of network traffic between a plurality of legacy applications. From the set of network traffic, a communication graph for the plurality of legacy applications is generated. From the communication graph, a set of migratable applications within the plurality of legacy applications is identified. The set of migratable applications is migrated to a cloud edge layer and a user is notified of the migration.

[0011] The program instructions further cause the device to monitor a second set of network traffic occurring between the set of migratable applications and the remainder of the plurality of legacy applications. In response to the monitoring, it is determined that at least one timing error has occurred. A network rate control filter is deployed at the cloud edge layer. Criteria for the network rate control filter are based on the at least one timing error. A user is notified of the criteria.

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

[0013] The drawings included in this disclosure are incorporated in and constitute 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 typical embodiments and are not intended to limit the present disclosure. [Brief explanation of the drawings]

[0014] [Figure 1] FIG. 1 illustrates an exemplary network environment for migrating complex legacy applications to a cloud edge layer, in accordance with an embodiment of the present disclosure. [Figure 2A] FIG. 1 illustrates an exemplary method for migrating a complex legacy application, according to an embodiment of the present disclosure. [Figure 2B] FIG. 1 illustrates an exemplary method for mitigating timing errors between complex applications, according to an embodiment of the present disclosure. [Figure 3] 1 illustrates an exemplary method for migrating a complex legacy application according to a communication graph, according to an embodiment of the present disclosure. [Figure 4] FIG. 1 illustrates a cloud computing environment, according to an embodiment of the present disclosure. [Figure 5] FIG. 2 illustrates an abstraction model layer according to an embodiment of the present disclosure. [Figure 6]1 depicts a high-level block diagram of an exemplary computer system that may be used in implementing embodiments of the present disclosure.

[0015] While the embodiments described herein are amenable to various modifications and alternative forms, specific features thereof have been shown by way of example in the drawings and will be described in detail. It is to be understood, however, that the particular embodiments described are not to be taken in a limiting sense. On the contrary, the intention is to cover all modifications, equivalents, and alternatives falling within the scope of the present disclosure. DETAILED DESCRIPTION OF THE INVENTION

[0016] Aspects of the present disclosure relate generally to the field of application migration, and more particularly to migrating complex legacy applications. While the present disclosure is not necessarily limited to such applications, various aspects of the present disclosure can be understood through a discussion of various examples using this context.

[0017] As mentioned above, the current state of technology desperately needs the ability to migrate complex, interdependent legacy applications to a cloud, or hybrid cloud platform, in a way that can both automate and mitigate timing dependencies between the migrated and non-migrated components of an enterprise's set of legacy applications and their components.

[0018] The edge layer of a cloud computing architecture can be an ideal environment for complex legacy applications because it provides local resources with low latency. The "edge layer" of a cloud can include cloud computing resources located as close as possible to the client devices that access them. Reducing the physical distance between the client devices and the cloud can potentially achieve low latency and high efficiency. The edge layer may be located at the facility where components of the legacy application run; such a facility may be instantiated as a data center, a corporate site, a private cloud hosting site, or an outsourced data center.

[0019] For example, existing legacy applications residing on an enterprise's servers may be a complex set of interacting applications and their components. The application components may interact through various protocols that were created many years ago. The components and / or protocols may use outdated programming languages, and assumptions about timing and the responsiveness of related applications may be poorly documented, if at all. As a result, timing dependencies between applications and application components may be unavailable or incomplete. However, these legacy applications may be essential to the operation of an enterprise.

[0020] When the need arises to migrate legacy applications to a new system or cloud environment, migrating all components of a given application (or set of / multiple applications) is rarely attempted because the number of errors, especially timing dependency errors between the migrated and non-migrated components / applications, can overwhelm developers and other staff and negatively impact business operations, potentially resulting in cascading failures and even catastrophe.

[0021] To illustrate the impact of contemplated embodiments, assume that an enterprise has 10 applications, each consisting of 10 components. Further, assume that one application is selected for migration to a cloud computing environment. If two of the components of the selected application are also utilized by one or more of the non-migrated applications, then migrating the selected application may slow down the non-migrated applications that utilize the selected application. The more non-migrated applications that utilize / depend on the selected application, the greater the impact of the slowdown on the enterprise's multiple applications (potentially exponential).

[0022] Not only does this slow things down, but it also increases the risk of application / component failures: legacy applications may still rely on timing characteristics and dependencies of components / applications in their local environment on a company's local servers, and if components are initially 2ms apart and suddenly move 100ms apart, related / attached applications / components may time out in unexpected ways.

[0023] A similar issue can also arise when an application / component resides on-premise (e.g. on a local enterprise server) but is updated to a new implementation that runs faster / more efficiently than the previous implementation / version. The old / unupdated component / application may have timing issues that lead to code paths that have never been executed / tested before, causing the application to crash. As a result, the migration process may fail. In other words, both operating too fast and operating too slowly can cause a complex legacy application to fail.

[0024] Embodiments of the present disclosure contemplate using at least three technologies / techniques to mitigate the above problems and accelerate and automate the migration of complex legacy applications. First, the use of passive network inspection can be employed to determine the topology of the components that make up each complex application. Passive network inspection can also be utilized to determine the characteristics of the communication between applications / components (e.g., server addresses, port addresses, protocol types, network latency, traffic volume, encryption types, etc.).

[0025] Second, a network communication graph can be generated from the results of passive network inspection. The communication graph can be used to group processes, identify various components / applications, and identify timing dependencies and the degree of application complexity. The communication graph can be used to rank complex legacy applications or compared against migration threshold criteria to determine the best candidates for migration (e.g., migrateable applications). Criteria may consider, for example, the amount of interdependence, the amount of network traffic associated with a particular process / component / application, etc.

[0026] Finally, network rate control filters may be used (e.g., in a cloud edge layer environment) to ensure that any particular component / application can operate within the migrated environment. Network rate control filters may be tailored for each component / application, allowing the migrated component / application to avoid timing-dependent failures, which are one of the leading causes of migration failures.

[0027] In embodiments, it may be assumed that some of the components / applications may be identified because they are likely running in a data center with a relatively well-defined structure that can be accounted for during passive network inspection. By monitoring network traffic in this environment, a set of processes / components / applications may be identified by listening to various communication ports that communicate with each other. For example, a server component of an application may be identified by a server address and a port number. The port number may be used to identify client requests by that component, which may lead to the identification of process elements on the network. By analyzing the communication of various processes, a communication graph between different components of the application may be generated. Furthermore, characteristics of the communication between the components may be determined, including network latency, volume of data packets / network traffic, etc. In other embodiments, network traffic monitoring may occur between components running on a single server, e.g., between components running as virtual machines on a physical machine, between components running as logical partitions on a mainframe, between components running as containers in a virtual local network such as DOCKER containers on a DOCKER network, etc.

[0028] According to embodiments, once interacting processes have been identified and a communication graph has been generated, various applications may be determined / identified by analyzing the communication graph. Analysis of the communication graph may identify groups of processes that operate in cooperation or in a manner typical of a component, an entire application, or multiple applications. This analysis may be performed using one or more of the following approaches: determining clusters of nodes in the communication graph that are similar; determining a minimum-cut partition of the communication graph; determining cliques or weighted partitions of nodes in the communication graph; etc. These process groups may be further analyzed to identify applications that have shared components or processes or a combination thereof, as well as the amount of network traffic exchanged between them.

[0029] In embodiments, the results of the process group analysis may include an identification of each application and the components of each application that communicate on the monitored network. As such, these results may be used to determine which components / applications are most suitable for migration to the cloud or cloud edge layer. In hybrid cloud embodiments, it may be expected that only a portion of the legacy components / applications will be migrated.

[0030] By analyzing the communication graph and process group analysis results, components / applications with the fewest links / dependencies with other components / applications can be selected for migration because these components / applications are likely to have the least impact on multiple legacy applications. In some embodiments, this can include a threshold check (e.g., comparison against migration threshold criteria). The criteria can be determined by a user / administrator or can be automated, such as a percentage of total network traffic volume over a period of time, a priority-based system of application importance, the result of a machine learning model's determination of the best components / applications to migrate, etc. In some embodiments, this can include a check against a set of migration policies, which can be determined by a user / administrator. The migration policies can define the conditions under which migration is allowed and the conditions under which migration should be avoided.

[0031] In embodiments, the cloud edge layer environment may be the destination for the migration. In this way, it may be ensured that the link between the migrating and non-migrating components / applications is maintained. Such an embodiment may be a permanent solution, or in embodiments, the cloud edge layer may be utilized as an intermediate step toward integration into a legacy cloud environment.

[0032] In embodiments, the cloud edge layer hosting the migrated components / applications may include appliances based on the same architecture as the migrated components / applications' native / origin / legacy environments. For example, a SYSTEM Z appliance for mainframe applications or an IBM CLOUD SATELLITE for Linux-based applications may be implemented within the cloud edge layer. In this manner, the cloud edge layer can ensure that latency between the migrated and non-migrated components / applications remains unchanged.

[0033] In some embodiments, components / applications may fail because the updated components / applications react too quickly, causing unexpected timing conditions. In some embodiments, network rate control filters can be incorporated to mitigate or mitigate these issues. For example, the cloud edge layer may introduce network latency via network rate control filters so that the latency experienced between the migrated and non-migrated components / applications falls within the range of the communication graph or delay observed in the native, pre-migration environment. In this way, the complex system of legacy applications can continue to operate with the same timing constraints and assumptions that existed in the native environment, and timing errors can be prevented and / or resolved.

[0034] 1 , an exemplary network environment 100 for migrating complex legacy applications to a cloud edge layer is illustrated in accordance with an embodiment of the present disclosure. The exemplary network environment 100 may include, for example, a cloud 110, a cloud edge layer 120, and an enterprise server 130. In some embodiments, certain functionality of the cloud 110, the cloud edge layer 120, and the enterprise server 130 may be implemented in different locations than depicted.

[0035] According to an embodiment, the cloud 110, the cloud edge layer 120, and the enterprise server 130 may be configured as computer systems (e.g., may include the same or similar components as the computer system 601). The cloud 110, the cloud edge layer 120, and the enterprise server 130 may be configured to communicate with each other via internal or external network interfaces (not shown). The network interfaces may be, for example, modems, wireless network adapters, Ethernet adapters, etc. The cloud 110, the cloud edge layer 120, and the enterprise server 130 may further include displays or monitors (not shown). Furthermore, the cloud 110, the cloud edge layer 120, and the enterprise server 130 may include any input device (e.g., a keyboard, a mouse, a scanner, or other input device), any commercially available or custom software (e.g., image processing software, object identification software, etc.), or a combination thereof. In some embodiments, the cloud 110, the cloud edge layer 120, and the enterprise server 130 may include additional servers, desktops, laptops, Internet of Things (IoT) devices, or handheld devices.

[0036] Cloud 110, cloud edge layer 120, and enterprise server 130 may further include storage (e.g., storage interface 614). The storage may include, for example, virtualized disk drives, physical hard disk drives, solid-state storage drives, or any other suitable storage medium. In some embodiments, workload data and metadata may be stored temporarily or persistently.

[0037] Cloud 110, cloud edge layer 120, and enterprise server 130 may be remote from one another and may communicate via a network (not shown). In an embodiment, cloud 110 may be a central hub through which cloud edge layer 120 and enterprise server 130 can establish a communication connection, as in a client-server networking model. In other embodiments, cloud edge layer 120 may serve as such a hub for enterprise server 130 and cloud 110. In some embodiments, cloud 110, cloud edge layer 120, and enterprise server 130 may be configured in any other suitable network relationship (e.g., in a peer-to-peer configuration or using another network topology).

[0038] In embodiments, connections between components of networking environment 100 may be implemented using any number of suitable communication media. For example, a wide area network (WAN), a local area network (LAN), the Internet, or an intranet. In particular embodiments, cloud 110, cloud edge layer 120, and enterprise server 130 are local to one another and may communicate via any suitable local communication media. For example, cloud 110, cloud edge layer 120, and enterprise server 130 may communicate using a local area network (LAN), one or more hardwired connections, wireless links or routers, or an intranet. In some embodiments, cloud 110, cloud edge layer 120, and enterprise server 130, as well as any other devices, may be communicatively coupled using one or more networks or one or more local connections, or a combination of both. For example, enterprise server 130 may be hardwired to cloud edge layer 120 (e.g., connected by an Ethernet cable), while a third client device may communicate with enterprise server 130 over a network such as an intranet or the Internet.

[0039] In some embodiments, network environment 100 may be implemented within or as part of a cloud computing environment. Consistent with various embodiments, a cloud computing environment may include a network-based distributed data processing system that provides one or more cloud computing services. Furthermore, a cloud computing environment may include many computers (e.g., hundreds or thousands of computers or more) located in one or more data centers and configured to share resources over a network. Further details regarding cloud computing are provided with respect to FIGS. 4 and 5.

[0040] According to an embodiment, enterprise server 130 may include applications 135A-D. Applications 135A-D may include, for example, legacy applications and their components / processes. Legacy applications may include email clients, internet browsers, databases, blockchain applications, machine learning models, artificial intelligence applications, streaming applications, or any other applications utilized by enterprise entities. In some embodiments, applications 135A-D may be candidates for migration to cloud edge layer 120 as discussed herein. As depicted, applications 135A and D may be non-migrated applications, and applications 135B-C may be migrated applications (e.g., may be substantially similar to or identical to migrated applications 135B-C).

[0041] According to an embodiment, enterprise server 130 may further include a migration controller 140. In some embodiments, migration controller 140 may be located within cloud edge layer 120 or outside cloud edge layer 120, but still within cloud 110. The migration controller may include a traffic monitor 145 (e.g., for performing passive network inspection as described herein) and a communication graph creator 148 (e.g., for generating a communication graph as described herein).

[0042] According to an embodiment, cloud edge layer 120 can include migrated applications 135B-C. As described herein, the migrated applications can be migrated implementations of applications 135B-C. The migrated applications 135B-C can be updated for the environment of cloud edge layer 120, or cloud edge layer 120 can include appliances that mimic the native environment of enterprise server 130, or a combination thereof.

[0043] In embodiments, the cloud edge layer may further include a traffic monitor 125. The traffic monitor may be substantially similar to traffic monitor 145. Traffic monitor 125 may monitor network traffic within cloud edge layer 120 or between applications 135A and D and migrated applications 135B-C, or a combination thereof, to detect timing errors and other problems that may be mitigated or resolved through the introduction of increased latency. In some embodiments, network rate control filter 128 may introduce and enforce these mitigating latencies as described herein.

[0044] Cloud 110 may include a cloud edge layer 120 and other cloud computing components. Additional details regarding cloud 110 and its components are provided with respect to FIGS. 4 and 5.

[0045] It should be noted that Figure 1 is intended to depict representative major components of exemplary network environment 100. However, in some embodiments, individual components may have greater or less complexity than depicted in Figure 1, components other than or in addition to those depicted in Figure 1 may be present, and the number, type, and configuration of such components may vary.

[0046] 2A, a flowchart of an example method 200A for migrating complex legacy applications is illustrated, according to an embodiment of the present disclosure. The example method 200A can begin at 205, where network traffic between the legacy applications is monitored. As discussed herein, passive network inspection techniques can be utilized in the monitoring, which can be performed in the legacy application's native environment (e.g., within the environment of the enterprise server 130).

[0047] At 210, a communication graph is generated. As described herein, the communication graph may include an enumeration of communication characteristics and components / processes of the application, and may further describe the relationships between the processes, components, and applications. The communication characteristics may include traffic volume in bytes or connection establishment over a period of time, the distribution of communication network protocols in the traffic, or parameters of any model that describes attributes of communication.

[0048] Applications that can be migrated are identified at 215. As described herein, applications that can be migrated may include a portion of the total number of legacy applications, and applications that can be migrated may be determined / identified using migration threshold criteria.

[0049] At 220, the migratable application can be migrated to a cloud edge layer (e.g., cloud edge layer 120). In embodiments, the migration may be performed hot or cold. In a hot migration, actively running components are migrated seamlessly. In a cold migration, application components are shut down and restarted in a new environment. In some embodiments, the migration of a subset of the application's components may be performed hot, and the remainder of the component migration may be performed cold. As described herein, the cloud edge layer may include virtual / physical machines in cloud 110 that are closest (either physically / geographically or logically) to the physical location of enterprise server 130. In some embodiments, logical proximity / distance may be measured by lowest latency or by communication compatibility. As described herein, cloud edge layer 120 may include appliances that mimic the migrated application's native environment, or may include network rate control filters, or a combination thereof.

[0050] At 225, the user is notified of the migration. In embodiments, the user may be an administrator, developer, end user, etc., and the notification may be accomplished through a pop-up window, text, email, audio sound, visual cue, tactile cue, etc. In some embodiments, the user may be prompted to respond to the notification to confirm the migration. In some embodiments, the user may modify the set of components to be migrated. In some embodiments, the notification and confirmation may occur before the migration process begins.

[0051] 2B, an exemplary method 200B for mitigating timing errors between complex applications is illustrated, in accordance with an embodiment of the present disclosure. In an embodiment, exemplary method 200B may occur after or in response to exemplary method 200A. Exemplary method 200B begins at 230, where network traffic between a migrated legacy application and a non-migrated legacy application is monitored, as described herein.

[0052] At 235, it is determined whether a timing error has occurred, as described herein. In embodiments, this may include determining from raw data generated by the monitoring, or from a communication graph generated from the monitoring. In yet other embodiments, the determination may be made by predictions generated by a machine learning model regarding realistic behavior of the migrated application in the cloud edge layer. In still other embodiments, timing errors may be avoided by determining a threshold of communication that is safe because no error notifications are observed during activity with a certain threshold rate of communication. In some embodiments, timing errors or other types of errors are observed, and the network characteristics that cause those errors are marked as ones to be avoided.

[0053] If it is determined at 235 that there are no timing errors, the method may continue monitoring network traffic at 230. However, if a timing error has occurred or is determined to occur, or if the network has been sufficiently monitored to determine a safe baseline for the network to operate without timing errors, the method proceeds to 240, where a network rate control filter 128 is deployed. As described herein, a network rate control filter may be deployed at the cloud edge layer to introduce latency in the migrated application. However, in some embodiments, a network rate control filter may be deployed at the enterprise server to introduce latency in the non-migrated remainder of the legacy application.

[0054] The network rate control filter criteria are communicated to the user at 245. In some embodiments, the network rate control filter criteria may include the communication characteristics and deployment latency of each process, component, and / or application affected by the network rate control filter.

[0055] 3, an exemplary method 300 for migrating complex legacy applications according to a communication graph is illustrated, according to an embodiment of the present disclosure. The exemplary method 300 may begin at 305, where network traffic between legacy applications is monitored to identify processes executing on the network, as described herein.

[0056] At 310, according to the results of the monitoring, the server address and port address / number of the process and / or component may be identified as described herein.

[0057] At 315, the client request associated with the component and / or process is identified based on the identified server address and port number, which may include, for example, determining the source / destination address / port number associated with the client request.

[0058] At 320, a communication graph is generated as described herein. In embodiments, the generated communication graph may include, for example, communication characteristics, network traffic volume, latency, origin / destination of data packets, etc.

[0059] The communication graph is analyzed at 325. Analyzing the communication graph may include, for example, determining the source and destination of each data packet sent between applications, network traffic volume, hardware component identification (e.g., MAC addressing, IP addresses, network latency, etc.), as described herein.

[0060] At 330, it is determined whether the monitored processes / components form a clique or group according to the communication graph. If no, the example method 300 may return to 305, or the example method 300 may end. If yes, the process group may be compared to a transition threshold criterion at 335.

[0061] If, at 335, it is determined that the process group exceeds the transition threshold criteria, as described herein, then the example method 300 may return to 305. Alternatively, the example method 300 may end. However, if it is determined that the process group meets the transition threshold criteria, then the method may proceed to 340.

[0062] At 340, the application including the process group may be migrated to the cloud edge layer as a migratable application, as described herein.

[0063] At 345, the user is notified of the transition as described herein.

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

[0065] Cloud computing is a service delivery model for enabling 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 a service provider. This cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0066] The characteristics are as follows:

[0067] On-Demand Self-Service: Cloud consumers can unilaterally provision computing capacity, such as server time or network storage, automatically as needed, without the need for human interaction with the service provider.

[0068] Broad network access: Computing power is available over the network and can be accessed through standard mechanisms, facilitating use by heterogeneous thin or thick client platforms (e.g., cell phones, laptops, PDAs).

[0069] Resource Pooling: Computing resources from a provider are pooled and offered to multiple consumers using a multi-tenant model. Various physical and virtual resources are dynamically allocated and reallocated based on demand. Consumers generally have no control or knowledge of the exact location of the resources they are provided with, resulting in a sense of location independence. However, consumers may be able to determine location at a higher level of abstraction (e.g., country, state, data center).

[0070] Rapid Elasticity: Computing capacity can be provisioned quickly and elastically, sometimes automatically, to instantly scale out and quickly release to instantly scale in. To the consumer, the computing power available for provisioning often appears unlimited, and can be purchased at any time and in any quantity.

[0071] Metered Services: Cloud systems leverage measurement capabilities at a level of abstraction appropriate to the type of service (e.g., storage, processing, bandwidth, active user accounts) to automatically control and optimize resource usage. Resource usage can be monitored, controlled, and reported to provide transparency to both providers and consumers of utilized services.

[0072] The service model is as follows:

[0073] Software as a Service (SaaS): The functionality offered to the consumer is the availability of a provider's applications running on a cloud infrastructure that can be accessed from a variety of client devices through a thin client interface such as a web browser (e.g., webmail). The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, storage, or even individual application functionality, except for limited user-specific application configuration settings.

[0074] Platform as a Service (PaaS): The capability offered to consumers is to deploy applications they create or acquire using programming languages ​​and tools supported by the provider onto a cloud infrastructure. The consumer does not manage or control the underlying cloud infrastructure, including the network, servers, operating systems, or storage, but does have control over the deployed applications and, in some cases, the configuration of their hosting environment.

[0075] Infrastructure as a Service (IaaS): The functionality offered to consumers is the provisioning of processors, storage, networking, and other basic computing resources on which they can deploy and run any software, including operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating system, storage, and deployed applications, and in some cases partial control over some network components (e.g., host firewalls).

[0076] The deployment model is as follows:

[0077] Private Cloud: This cloud infrastructure is dedicated to a specific organization and can be managed by that organization or a third party, and can exist on-premise or off-premise.

[0078] Community Cloud: This cloud infrastructure is shared by multiple organizations to support a specific community with common concerns (e.g., mission, security requirements, policies, and compliance). This cloud infrastructure can be managed by those organizations or a third party and can exist on-premises or off-premises.

[0079] Public cloud: This cloud infrastructure is available to the general public or large industry organizations and is owned by an organization that sells cloud services.

[0080] Hybrid cloud: This cloud infrastructure combines two or more cloud models (private, community, or public), each of which retains its inherent nuances but is bound by standards or specific technologies that enable data and application portability (e.g., cloud bursting for load balancing between clouds).

[0081] A cloud computing environment is a service-oriented environment that emphasizes statelessness, low coupling, modularity, and semantic interoperability. At the core of cloud computing is an infrastructure that includes a network of interconnected nodes.

[0082] FIG. 4 illustrates an exemplary cloud computing environment 50. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers (e.g., PDAs or cell phones 54A, desktop computers 54B, laptop computers 54C, or automobile computer systems 54N, or combinations thereof) can communicate. The nodes 10 can communicate with each other. The nodes 10 can be physically or virtually grouped (not shown) in one or more networks, such as the private, community, public, or hybrid clouds described above, or combinations thereof. This enables the cloud computing environment 50 to provide infrastructure, platform, or software as a service, or combinations thereof, for which cloud consumers are not required to maintain resources on their local computing devices. It should be understood that the types of computing devices 54A-N illustrated in FIG. 4 are merely exemplary, and that the computing nodes 10 and the cloud computing environment 50 can communicate with any type of electronic device via any type of network or network-addressable connection (e.g., using a web browser), or both.

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

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

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

[0086] By way of example, the management layer 80 may provide the following functionality: Resource provisioning 81 enables dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 enables cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. By way of example, these resources may include application software licenses. Security enables identification and verification of cloud consumers and tasks, as well as protection for data and other resources. User portal 83 provides consumers and system administrators with access to the cloud computing environment. Service level management 84 enables allocation and management of cloud computing resources so that requested service levels are met. Service level agreement (SLA) planning and fulfillment 85 enables advance arrangement and procurement of anticipated future cloud computing resources required in accordance with SLAs.

[0087] The workload layer 90 provides examples of capabilities available in a cloud computing environment. Examples of workloads and capabilities that can 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 complex application migration 96.

[0088] 6, there is shown a high-level block diagram of an exemplary computer system 601 that may be configured to execute various aspects of the present disclosure, including, for example, methods 200A-B / 300 described in FIGS. 2A-B and 3. The exemplary computer system 601 may be used (e.g., using one or more processor circuits of a computer or computer processor) in performing one or more of the methods or modules described herein, and any associated functions or operations, in accordance with embodiments of the present disclosure. In some embodiments, exemplary components of the computer system 601 consist of one or more CPUs 602, a memory subsystem 604, a terminal interface 612, a storage interface 614, an I / O (input / output) device interface 616, and a network interface 618, all of which may be communicatively coupled, directly or indirectly, for communication between components via a memory bus 603, an I / O bus 608, and an I / O bus interface unit 610.

[0089] Computer system 601 may include one or more general-purpose programmable central processing units (CPUs) 602A, 602B, 602C, and 602D, generally referred to herein as CPUs 602. In some embodiments, computer system 601 may include multiple processors typical of relatively large systems, while in other embodiments, computer system 601 may alternatively be a single-CPU system. Each CPU 602 may execute instructions stored in memory subsystem 604, which may include one or more levels of on-board cache. Memory subsystem 604 may include instructions 606 that, when executed by processor 602, cause processor 602 to perform some or all of the functions described above with respect to FIGS. 2A-B and 3.

[0090] In some embodiments, memory subsystem 604 may include random-access semiconductor memory, storage devices, or storage media (either volatile or non-volatile) for storing data and programs. In some embodiments, memory subsystem 604 may represent the entire virtual memory of computer system 601 and may also include virtual memory of other computer systems coupled to computer system 601 or connected via a network. While memory subsystem 604 may conceptually be a single monolithic entity, in some embodiments, memory subsystem 604 may be a more complex arrangement, such as a hierarchy of caches and other memory devices. For example, memory may exist in multiple levels of caches, and these caches may be further divided by function, such that one cache holds instructions and another cache holds non-instruction data used by the processor or processors. Memory may be further distributed and associated with different CPUs or sets of CPUs, as known in any of a variety of so-called non-uniform memory access (NUMA) computer architectures. In some embodiments, main memory or memory subsystem 604 may include elements for the control and flow of memory used by CPU 602. This may include memory controller 605.

[0091] 6 as a single bus structure providing a direct communication path between CPU 602, memory subsystem 604, and I / O bus interface 610, memory bus 603 may, in some embodiments, be comprised of multiple distinct buses or communication paths, which may be arranged in any of a variety of configurations, such as point-to-point links in a hierarchical, star, or web configuration, multiple hierarchical buses, parallel and redundant paths, or any other suitable type of configuration. Additionally, while I / O bus interface 610 and I / O bus 608 are shown as single respective units, computer system 601 may, in some embodiments, include multiple I / O bus interface units 610, multiple I / O buses 608, or both. Additionally, although multiple I / O interface units are shown, this separates I / O bus 608 from the various communication paths running to the various I / O devices, in other embodiments some or all of the I / O devices may be directly connected to one or more system I / O buses.

[0092] In some embodiments, computer system 601 may be a multi-user mainframe computer system, a single-user system, or a server computer or similar device that has little or no direct user interface but receives requests from other computer systems (clients). Further, in some embodiments, computer system 601 may be implemented as a desktop computer, a portable computer, a laptop or notebook computer, a tablet computer, a pocket computer, a telephone, a smartphone, a mobile device, or any other suitable type of electronic device.

[0093] It should be noted that Figure 6 is intended to depict representative exemplary components of exemplary computer system 601. However, in some embodiments, individual components may have greater or less complexity than depicted in Figure 6, components other than or in addition to those shown in Figure 6 may be present, and the number, type, and configuration of such components may vary.

[0094] The present invention may be a system, method, or computer program product, or combination thereof, integrated at any possible level of technical detail. The computer program product may include a computer-readable storage medium having stored thereon computer-readable program instructions for causing a processor to carry out aspects of the present invention.

[0095] A computer-readable storage medium may be a tangible device capable of retaining and storing instructions for use by an instruction execution device. The computer-readable storage medium may be, by way of example, an electronic storage device, a magnetic storage device, an optical storage device, an electromagnetic storage device, a semiconductor storage device, or a suitable combination thereof. More specific examples of computer-readable storage media include portable computer diskettes, hard disks, RAM, ROM, EPROM (or flash memory), SRAM, CD-ROMs, DVDs, memory sticks, floppy disks, mechanically encoded devices having instructions recorded on punch cards or ridge-in-groove structures, or the like, and suitable combinations thereof. Computer-readable storage devices, as used herein, should not be construed as ephemeral signals per se, such as radio waves or other freely propagating electromagnetic waves, electromagnetic waves propagating through a waveguide or other transmission medium (e.g., light pulses passing through a fiber optic cable), or electrical signals transmitted over wires.

[0096] The computer-readable program instructions described herein can be downloaded from a computer-readable storage medium to each computer / processing device. Alternatively, they can be downloaded to an external computer or external storage device via a network (e.g., the Internet, a LAN, a WAN, or a wireless network, or a combination thereof). The network can 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 within each computer / processing device receives the computer-readable program instructions from the network and transfers the computer-readable program instructions to a computer-readable storage medium in the respective computer / processing device for storage.

[0097] The computer-readable program instructions for carrying out the operations of the present invention can be either assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine-dependent instructions, microcode, firmware instructions, state setting data, configuration data for integrated circuits, or source or object code written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Smalltalk and C++, and procedural programming languages ​​such as the "C" programming language and similar programming languages. The computer-readable program instructions can execute entirely on the user's computer as a stand-alone software package, partially on the user's computer, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In the latter case, the remote computer may be connected to the user's computer via any type of network, including a LAN or WAN, or may be connected to an external computer (e.g., via the Internet using an Internet Service Provider). In some embodiments, electronic circuitry, including, for example, programmable logic circuits, field programmable gate arrays (FPGAs), programmable logic arrays (PLAs), can execute computer-readable program instructions by utilizing state information of the computer-readable program instructions to customize the electronic circuitry for carrying out aspects of the present invention.

[0098] Embodiments of the present invention are described herein with reference to flowchart and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the present invention. Each block of the flowchart and / or block diagrams, and combinations of blocks in the flowchart and / or block diagrams, can be implemented by computer-readable program instructions.

[0099] The computer-readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus to produce a machine, whereby the instructions, executed by the processor of such computer or other programmable data processing apparatus, create means for performing the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams. The computer-readable program instructions may also be stored on a computer-readable storage medium capable of instructing a computer, programmable data processing apparatus, or other device, or combination thereof, to function in a particular manner. The computer-readable storage medium having instructions stored thereon thereby constitutes an article of manufacture including instructions for performing aspects of the functions / acts identified in one or more blocks of the flowcharts and / or block diagrams.

[0100] Computer-readable program instructions may also be loaded into a computer, other programmable device, or other device and a series of operational steps executed on the computer, other programmable device, or other device to create a computer-implemented process, whereby the instructions executing on the computer, other programmable device, or other device perform the functions / operations identified in one or more blocks in the flowcharts and / or block diagrams.

[0101] The flowcharts and block diagrams in the figures of this disclosure 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 performing specific logical functions. In some implementations, the functions shown in the blocks may be executed in a different order than shown in the figures. For example, two blocks shown in succession may actually be executed concurrently or nearly concurrently, or may even be executed in reverse order, depending on the functionality involved. Note that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented by a dedicated hardware-based system that performs specific functions or operations or executes a combination of dedicated hardware and computer instructions.

[0102] The description of various embodiments of the present invention has been presented for illustrative purposes and is not intended to be exhaustive or limiting of the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terms used herein have been selected to best describe the principles of the embodiments, practical applications or technical improvements to technology found in the market, or to best enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method for a computer system to migrate a complex application, comprising: the computer system monitoring a set of network traffic between a plurality of applications, each of the plurality of applications including a plurality of components, at least some of the components interconnected with other applications; generating, by the computer system, a communication graph from the set of monitored network traffic, the communication graph including an average latency between each of the plurality of components and other applications; the computer system identifying a set of migratable components and other applications from the average latency of the communication graph; the computer system migrating the identified set of components and other applications to an edge layer; the computer system notifying a user of the transition.

2. The computer system generating the communication graph comprises: the computer system identifying server addresses and port numbers for the components and other applications; the computer system using the server address and the port number to identify a set of client requests associated with the component and other applications; The method of claim 1 , further comprising: the computer system generating the communication graph from the identified set of client requests.

3. The communication graph may be a set of server addresses and port numbers associated with a set of origins for the set of client requests; a set of server addresses and port numbers associated with a set of destinations for the set of client requests; and a volume of network traffic.

4. The computer system identifying the set of migratable components and other applications comprises: analyzing the communication graph to identify one or more groups of related components and other applications; The method of claim 3 , further comprising the computer system determining the set of migratable components and other applications from the group of one or more related components and other applications.

5. The method of claim 4 , wherein the edge layer includes an appliance based on a native architecture of a first application from a set of the migratable components and other applications.

6. The method of claim 5 , wherein software is provided as a service at the edge layer for hosting the first application.

7. The computer system monitoring a second set of network traffic occurring between the set of migratable components and other applications and the remainder of the plurality of applications; determining, by the computer system in response to the monitoring, that at least one timing error has occurred; the computer system deploying a network rate control filter at the edge layer, the criteria of the network rate control filter being based on the at least one timing error; The method of claim 1 , further comprising the computer system notifying a user of the criteria.

8. 1. A computer program for migrating a complex application, the computer program being executable by an apparatus, the apparatus comprising: monitoring a set of network traffic between a plurality of applications, each of the plurality of applications including a plurality of components, at least some of the components being interconnected with other applications; generating a communication graph from the set of monitored network traffic, the communication graph including average latencies between each of the plurality of components and other applications; Identifying a set of components and other applications that can be migrated from the average latency of the communication graph; Migrating the identified set of components and other applications to an edge layer; and notifying a user of said transition.

9. generating the communication graph Identifying server addresses and port numbers for said components and other applications; using the server address and the port number to identify a set of client requests associated with the component and other applications; The computer program product of claim 8 , further comprising: generating the communication graph from the identified set of client requests.

10. The communication graph may be a set of server addresses and port numbers associated with a set of origins for the set of client requests; a set of server addresses and port numbers associated with a set of destinations for the set of client requests; and an amount of network traffic.

11. identifying the set of migratable components and other applications includes: analyzing the communication graph to identify one or more related groups of components and other applications; The computer program product of claim 10 , further comprising: determining the set of migratable components and other applications from the group of one or more related components and other applications.

12. The computer program product of claim 11 , wherein the edge layer includes an appliance based on a native architecture of a first application from a set of the migratable components and other applications.

13. The computer program product of claim 12 , wherein software is provided as a service at the edge layer for hosting the first application.

14. The computer program causes the device to: monitoring a second set of network traffic occurring between the migratable component and a set of other applications and the remainder of the plurality of applications; determining, in response to said monitoring, that at least one timing error has occurred; introducing a network rate control filter at the edge layer, wherein criteria for the network rate control filter are based on the at least one timing error; 9. The computer program product of claim 8, further comprising: notifying a user of the criteria.

15. 1. A system for migrating complex applications, comprising: a memory subsystem having program instructions thereon; a processor in communication with the memory subsystem, wherein the program instructions cause the processor to: monitoring a set of network traffic between a plurality of applications, each of the plurality of applications including a plurality of components, at least some of the components being interconnected with other applications; generating a communication graph from the set of monitored network traffic, the communication graph including average latencies between each of the plurality of components and other applications; Identifying a set of components and other applications that can be migrated from the average latency of the communication graph; Migrating the identified set of components and other applications to an edge layer; and notifying a user of the transition.

16. generating the communication graph Identifying server addresses and port numbers for said components and other applications; using the server address and the port number to identify a set of client requests associated with the component and other applications; The system of claim 15 , further comprising: generating the communication graph from the identified set of client requests.

17. The communication graph may be a set of server addresses and port numbers associated with a set of origins for the set of client requests; a set of server addresses and port numbers associated with a set of destinations for the set of client requests; and a volume of network traffic.

18. identifying the set of migratable components and other applications includes: analyzing the communication graph to identify one or more related groups of components and other applications; 20. The system of claim 17, further comprising: determining the set of migratable components and other applications from the group of one or more related components and other applications.

19. 20. The system of claim 18, wherein the edge layer includes an appliance based on a native architecture of a first application from a set of the migratable components and other applications.

20. The program instructions may cause the processor to: monitoring a second set of network traffic occurring between the migratable component and a set of other applications and the remainder of the plurality of applications; determining, in response to said monitoring, that at least one timing error has occurred; introducing a network rate control filter at the edge layer, wherein criteria for the network rate control filter are based on the at least one timing error; 16. The system of claim 15, further comprising: notifying a user of the criteria.

Images