COMPUTER-IMPLEMENTED METHOD, COMPUTER SYSTEM, AND COMPUTER PROGRAM FOR PREDICTIVELY DEPLOYING MICROSERVICES ON EDGE DEVICES IN A NETWORK

Abstract

To provide a computer-implemented method, a computer system, and a computer program, for predictively deploying microservices on edge devices in a network.SOLUTION: An application comprises a set of microservices runnable on any one edge device in a set of two or more edge devices. A state of a client device at a first point of time is determined and one or more microservices that are likely to be run at a second point of time subsequent to the first point of time and a location of the client device at the second point of time are predicted. Based on the predicted location, a next edge device in the set of edge devices is determined for running the one or more microservices predicted to be run at the second point of time.SELECTED DRAWING: Figure 4

Description

[Technical field]

[0001] The present invention relates to a computer-implemented method, a computer system and a computer program product for intelligent dynamic communication handoff for mobile applications, particularly for predictively deploying microservices at edge devices in a network.

[0002] Embodiments relate generally to wireless communications, and more particularly to a method for predictively deploying software microservices to edge nodes (i.e., edge devices) to enable rapid communication handoffs in wireless networks. [Background technology]

[0003] Wireless network systems have become a popular means for communicating with others around the world and engaging with content. Wireless communication devices, such as mobile phones, tablet computers, and the like, are becoming smaller and more powerful to meet consumer needs and to improve portability and convenience. Consumers have become dependent on these devices and are demanding reliable service, increased coverage, additional services (e.g., web browsing capabilities), and a continuing reduction in the size and cost of such devices.

[0004] One of the most challenging requirements for a wireless network to be ubiquitous is the ability to allow mobility anytime and anywhere without compromising quality of service and connectivity. Such mobility support allows users with different mobility profiles to traverse different geographical regions while continuing to access different mobile applications. A central component supporting mobility management is the handover mechanisms. In cellular telecommunications, the term handover or handoff refers to the process of transferring an ongoing call or data session from one channel connected to the core network to another. In satellite communications, it is the process of transferring the responsibility of satellite control from one earth station to another without loss or interruption of service. Handover mechanisms allow a user to change the physical point of attachment in a mobile network when certain preprogrammed conditions are met. For example, if the received signal power from the current base station serving the user falls below a certain threshold and, at the same time, the received signal power for another nearby base station rises above a certain threshold, the decision to change the attachment point, i.e., base station, can be made by devices in the network infrastructure in coordination with the user device.

[0005] The global mobile network infrastructure is in the midst of a transition to what is known as 5G, or fifth generation, technology. Compared to the current network scenario, the future 5G network scenario will be much more complex. Contributing to this increased network complexity is the growing demand for high quality data by users and devices, which is also expected to increase exponentially. There is also a technological diversity of applications that goes far beyond the traditional "voice and data" applications commonly used today, e.g., Virtual Reality (VR), Augmented Reality (AR), gaming, messaging, video playback, etc. There are various radio access technologies, i.e., 5G New Radio (NR), LTE, 3G, 2G, Wi-Fi, and a wide range of mobility profiles, e.g., encompassing high-speed train, airplane, car, or pedestrian users. The complexity of 5G networks is further exacerbated by all of these factors, not to mention the addition of new spectrum bands, e.g., mmWave frequencies, that behave much differently than the traditional spectrum bands of previous mobile network generations.

[0006] In such an environment, existing static techniques of communication handoff suffer from workload fluctuations, resulting in loss of continuity of computing and connectivity, and ultimately resulting in poor user experience. For example, in current mobile network scenarios, the network has a significant amount of time to trigger, prepare, execute, and complete a handover. However, the same is not true for future networks, where the density of access points will be high, i.e., access points with smaller coverage areas and higher bandwidth will be more densely packed in a given area. In addition, macro cells with very large coverage areas will exist to support the small cells. If the current handover mechanisms described above are used, the time to complete the handover may be much longer than the time a user can be at the desired base station, but the situation is still favorable for establishing a link. If the time available to perform resource allocation and negotiation processes is short, there is a higher risk of connection loss with the established handover mechanisms, and this may result in poor network performance. Due to the interference caused by cell densification, and also the presence of different radio access technologies, i.e. many potential handoffs between 4G LTE and older technologies, e.g. Wi-Fi, the handover signaling overhead will also become very important in the context of network performance. Therefore, optimizing the handover process such that delay and signaling overhead are reduced will become a crucial component of future handover management strategies.

[0007] For example, consider a scenario of an AR game application in which a player needs to move from one location to another on a large physical area equipped with AR markers while virtually fighting in the game. When a player moves quickly from one physical location to another, user communication with the game server will need to be enabled via a rapid handoff from one network repeater to another network repeater, regardless of whether the server is in a central location (also known as the "cloud") or close to the user at the network edge. As mentioned above, existing handover mechanisms may be too slow to handle the dynamic nature of the player's movements and the corresponding need for high bandwidth and high computing resources.

[0008] 5G wireless networks also lend themselves to what is known as the edge computing model. Edge computing is a distributed computing framework in which information processing is located closer to the edge of the network, where things and people generate or consume that information. Rather than relying on a central location thousands of miles away, as previously described for 5G wireless networks, edge computing brings computation and data storage closer to the devices where they are collected, resulting in a more decentralized environment.

[0009] Edge computing was developed due to the exponential growth of Internet-enabled devices, such as self-driving cars, or everyday devices in the home, such as security cameras or thermostats, or in commercial environments, automated devices on manufacturing lines. These devices now use the network to receive information from the cloud or send data back to the cloud. Many of these "edge devices" generate huge amounts of data during the course of their operation. As an example, consider devices monitoring manufacturing equipment on a factory floor, or Internet-connected video cameras transmitting live footage from a remote office. While a single device generating data can transmit the data over the network very easily, problems arise when the number of devices transmitting data at the same time increases. Instead of one video camera transmitting live footage, hundreds or thousands of devices may be transmitting or receiving data, resulting in a potential loss of quality due to latency and huge bandwidth costs.

[0010] Edge computing hardware and services help solve this problem by being a local source of processing and storage for many of these systems. An edge server, for example, can process data from edge devices and then send only relevant data back via the cloud, thereby reducing bandwidth needs, or the edge server can send data back to the edge device if a real-time application requires it. These edge devices can include a variety of things, such as a smart thermostat, an employee's notebook computer, an employee's latest smartphone, a security camera, or even an internet-connected microwave in an office break room. The edge server itself, and even network repeaters installed in 5G networks, such as cell towers, microcells, Wi-Fi access points, can be considered edge devices in an edge computing infrastructure.

[0011] In conjunction with 5G wireless infrastructure and edge computing models, a methodology of software development known as "microservices architecture" that has become popular in recent years also fits into this decentralized environment. "Microservices architecture" refers to a particular way of designing software applications as suites of independently deployable microservices. These microservices run in their own processes and communicate with each other over a network, collectively achieving goals using technology-agnostic and lightweight protocols, such as Hypertext Transfer Protocol (HTTP), with minimal centralized management. Microservices may be implemented using a variety of programming languages, databases, or hardware and software environments, depending on what is best suited for a particular microservice. Microservices are small in size, messaging-enabled, developed autonomously, independently deployable, and can be built and released in an automated process. Because of these characteristics, microservices architectures are commonly adopted for cloud-native applications, serverless computing, and applications that use lightweight container deployment -- conditions that are prevalent in 5G wireless and edge computing environments. Summary of the Invention [Problem to be solved by the invention]

[0012] The present invention aims to provide a computer-implemented method, a computer system, and a computer program product for predictively deploying microservices on edge devices in a network. [Means for solving the problem]

[0013] One embodiment is directed to a computer-implemented method for predictively deploying microservices on edge devices in a network, the method can include executing an application on a client device, where the application has a set of microservices executable on any one of a set of two or more edge devices.

[0014] The method may also include determining a state of the client device at a first time, where the state includes one or more microservices currently executing for the client device, and for each currently executing microservice, an edge device executing the microservice. The determined state of the first client device may be transmitted to at least one edge device in the set of two or more edge devices.

[0015] Additionally, the method can include predicting one or more microservices that are likely to be executed at a second time point subsequent to the first time point. This may include determining, for each of the one or more microservices currently executing for the client device, a probability that a microservice not currently executing for the client device will be requested by the client device when each currently executing microservice terminates, and ranking the microservices in order of the determined probabilities. A machine learning model may be used to determine the probability that a microservice not currently executing for the client device will be requested by the client device when a currently executing microservice terminates.

[0016] The method may further include predicting a location of the client device at the second time. A direction and speed of movement of the client device may be determined, and a location of the client device at the second time may be predicted based on the determined direction and speed of movement of the client device.

[0017] The method may also include determining a next edge device in the set of edge devices for executing the one or more microservices predicted to be executed at the second time point based on the predicted location, the first edge device as a candidate for a next edge device includes determining a computing capability of the first edge device, determining a workload of the first edge device, predicting a level of operational service if the predicted one or more microservices likely to be executed are executed at the first edge device at the second time point, and determining whether the level of operational service is a threshold for operational service. value If the level of operational service is equal to or greater than the threshold of operational service, the first edge device may be selected as the next edge device. value If the level is less than the first edge device, the first edge device may not be selected as the next edge device, and a second edge device may be evaluated as a candidate for the next edge device.

[0018] Finally, the method includes determining a time required to deploy the one or more microservices predicted to run on the determined next edge device at the second time point, and initiating deployment of the one or more microservices predicted to run on the determined next edge device at a third time point on the determined next edge device, where the third time point is before the second time point, where the third time point is determined based on the determined time required to deploy the one or more microservices predicted to run on the determined next edge device. A computational capability and workload of the determined next edge device may also be determined.

[0019] In addition to the computer-implemented methods, additional embodiments are directed to systems and computer program products for predictively deploying microservices on edge devices within a network.

[0020] This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [Brief description of the drawings]

[0021] [Figure 1] FIG. 1 is a block diagram of an exemplary computer system upon which various embodiments may be implemented. [Diagram 2] FIG. 2 illustrates an exemplary microservices interaction diagram according to one embodiment. [Diagram 3] FIG. 3 illustrates an exemplary mobile wireless network with a client device moving among multiple edge devices according to one embodiment. [Figure 4] FIG. 4 is a flowchart diagram of a microservices prediction process in a mobile wireless network architecture according to one or more embodiments. [Diagram 5] FIG. 5 shows a block diagram of the inputs and machine learning models of the microservice prediction module to determine the likelihood of the next needed microservice in a mobile wireless network. [Figure 6] FIG. 6 illustrates a cloud computing environment according to one embodiment of the present invention. [Figure 7] FIG. 7 illustrates abstraction model layers according to one embodiment of the present invention. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0022] In the example of a wireless environment, there are many software applications to be supported by the network infrastructure (repeaters and servers), where each application has a set of microservices. In this scenario, it is important to have the microservices deployed and ready to run on the appropriate edge devices (in this case, network repeaters) when the edge devices need to process data from users. The edge devices have limited computing capabilities, and therefore it is not feasible to deploy and run all microservices of an application on all edge devices. It is useful to identify which microservices are deployed on which edge devices and at what time to meet the needs of all users served by the network. It takes some time for a microservice to be deployed on an edge device, and that time must be considered when determining when the microservice needs to be ready. Given the number of network repeaters or edge devices with compute and bandwidth capacity, it is necessary to determine when a particular microservice is likely to be needed next on a particular edge device.

[0023] Referring now to FIG. 1, a block diagram is shown illustrating a computer system 100 that, in one embodiment, may be embedded in an edge server. In another embodiment, the computer system 100 may be embedded in a network repeater, such as a cell tower or a 5G microcell. In yet another embodiment, the computer system 100 may be embedded in a client device or a mobile client device, examples of which include mobile phones, smartphones, tablets, laptops, computing devices embedded in vehicles, wearable computing devices, virtual or augmented reality glasses or headsets, and the like. As shown, the computer system 100 includes a processor unit 102, a memory unit 104, a persistent storage 106, a communication unit 112, an input / output unit 114, a display 116, and a system bus 110. A computer program, such as a microservice prediction module 120, may be stored in the persistent storage 106 until needed for execution, at which point the program is brought into the memory unit 104 so that it can be directly accessed by the processor unit 102. The processor unit 102 selects a portion of the memory unit 104 to read from or write to, or a combination thereof, by using an address that the processor 102 provides to the memory 104 along with a read or write or combination thereof request. Typically, reading and interpreting an instruction encoded in the address causes the processor 102 to fetch a subsequent instruction either at the subsequent address or at some other address. The processor unit 102, the memory unit 104, the persistent storage 106, the communication unit 112, the input / output unit 114, and the display 116 interface with each other via a system bus 110.

[0024] Referring to FIG. 2, a diagram illustrating an example of microservice interactions is shown, which is used in conjunction with FIG. 4 as an example to explain the process. In this example, the microservices 202-222 of an example application are initially executed in a particular order, but after an initial period, various microservices may be triggered at different times based on user actions, and thus there is no inherent order to how the microservices are triggered. The microservice prediction module 120 may predict which one or more microservices are most likely to be needed at a given edge device D at time T, and may initiate operations to deploy such microservices, so that the microservices are ready to run when needed.

[0025] Referring to FIG. 3, an example of a mobile wireless network is shown. A client device 310 is shown within range 306 and communicates with a current edge device 302 while moving in a direction 320 into range 308 of a next edge device 304. Although a mobile phone is shown as an example of a client device in FIG. 3, it should be understood that the client device 310 can be any mobile device, such as a mobile phone, a smart phone, a tablet, a laptop, a computing device embedded in a vehicle, a wearable computing device, virtual or augmented reality glasses or headsets. In addition, while the edge nodes 302, 304 are shown as cell towers, it should be understood that a vehicle, such as a vehicle having a containerized entertainment system, can be an edge node. When the client device 310 moves out of range 306 of the current edge device 302 and into range 308 of the next edge device 304, the current edge device 302 hands off communication to the next edge device 304. The current edge device 302 and the next edge device 304 are said to be "neighboring" edge devices. In this example, the microservices that are calculated by the microservice prediction module 120 to be likely to be needed next may be deployed on the next edge device 304 before the handover. For ease of explanation, FIG. 3 only shows one current edge device, one next edge device, and a single client device moving in a single direction, but it should be understood by those skilled in the art that in practice, a single edge device may serve several client devices moving in more than one direction at a time, and a single current edge device may have multiple neighboring edge devices that will act as next edge devices.

[0026] 4, a flowchart of a predictive process 400 for deploying required microservices is shown. In various embodiments, some or all of the operations of this process may be performed by an edge server or edge device. In other embodiments, some or all of the operations of this process may be performed by a mobile network repeater.

[0027] At 402, the microservice prediction module 120 may determine and distribute (or transmit) a state (ST) of each client device (i) to all edge devices (D), where the state captures which edge device the client device is currently connected to and which one or more microservices the client device is currently running, e.g., at a first time. With reference to the microservices shown in the example of FIG. 2, given N client devices, the state of client device i=1 is ST1={D1, 202}, which indicates that client device 1 is currently connected to edge device D1 and is currently running microservice 202 (which may be, for example, an authentication microservice). The state of client device i=2 is ST2={D4, 202}, which indicates that client device 2 is currently connected to device D4 and is currently running microservice 202. While this example references one microservice per user state for simplicity, it should be noted that the same edge device may run multiple microservices for a single client device per state, e.g., ST3={D1, 206, 216}. Additionally, a single edge device may run the same microservice simultaneously for two or more client devices, e.g., ST1={D1, 202} and ST5={D1, 202}.

[0028] At 404, the microservice prediction module 120 may collect from the neighboring edge devices which client devices are being served. The result is a list of client devices and their corresponding states. For example, the list of client devices for edge device Dj may be {U1, U4, U8, U9, ...}, and the corresponding states of these client devices on edge device Dj may be {ST1, ST4, ST8, ST9, ...}. From these lists of client devices and their states provided at the neighboring edge devices, the microservice prediction module 120 may extract the currently running microservices, e.g., at a first time point. For example, if the state for client device 1 indicates microservice 206 and the state for client device 2 indicates microservice 204, the list of microservices running on that edge device includes 204, 206, etc. A sample list of microservices running on edge device Dj may be {204, 206, 210, 206, 204, 214, ...}. It should be noted that the same microservice may appear multiple times, i.e., when different client devices are being served by neighboring devices running the same microservice.

[0029] At 406, the microservice prediction module 120 may identify (or predict) the next most likely microservice to be executed based on the list of currently running microservices. Initially, this may be based on fixed configuration settings, but then over time, the prediction may be improved according to actual execution, as described at 410. As an example, the list of currently running microservices may include three occurrences (or instances) of 204 (corresponding to the three client devices currently using 204), one occurrence of 206, and five occurrences of 214. In this case, the microservice prediction module 120 may determine that the next most likely microservices to be needed are 222 and 204, each with probability p=(5 / 9)*(1 / 2), where 5 / 9 is based on the number of occurrences of 214 and 1 / 2 is based on the example of FIG. 2, where the initial assumption is that 222 or 204 will be executed with equal probability after 214. Also, in this list, the next likely microservice to run may be 206 with probability p=(3 / 9)*1, where 3 / 9 is based on the number of occurrences of 204 and 1 is based on the example of FIG. 2, where only 206 runs after 204, and 208 with probability p=(1 / 9)*1, where 1 / 9 is based on the number of occurrences of 206 and 1 is based on the example of FIG. 2, where only 208 runs after 206.

[0030] In addition to predicting the next likely microservice to be executed in step 406, the microservice prediction module 120 may also predict the likely location of the client device by determining the direction and speed of movement of the client device (or the vehicle in which the user of the client device is located) to select a suitable next edge device 304. The microservice prediction module 120 may also predict a time when the client device 310 is predicted to be within communication range (or handoff range) of the suitable next edge device 304 based on the direction and speed of movement of the client device. Thus, the microservice prediction module 120 may predict one or more microservices that are likely to be executed at a second time point subsequent to the first time point, and the location of the client device at the second time point. Furthermore, the microservice prediction module 120 may determine a next edge device in a set of edge devices for executing the microservice predicted to be executed at the second time point based on the predicted location, and may determine the time required to deploy the microservice predicted to be executed at the second time point on the determined next edge device.

[0031] At 408, the microservice prediction module 120 may deploy the microservice on the next edge device 304 according to the match between the prediction of the previous step and the potential computing or memory or bandwidth limitations of the edge device calculated in this step. Each next edge device 304 may calculate the start-up time required to load each respective microservice, which may vary from edge device to edge device since edge devices may be heterogeneous both in terms of hardware and software and workload. For example, the time required for a particular microservice to be loaded in a cell tower may be significantly different from the time in a 5G microcell. Different edge devices may have different types and numbers of processors, different amounts and types of memory, different types and versions of software. Moreover, the start-up time for a particular microservice on a particular edge device at a particular time may depend on the amount of other processing currently running on the edge device at that time. The start-up time also depends on the attributes of the particular microservice, such as the size of the code and the required libraries. The start-up time calculation may account for some or all of these factors. A table such as the following may be calculated:

[0032] [Table 1]

[0033] Once the microservice prediction module 120 calculates the startup time, the microservice prediction module 120 may start deploying the microservice at an appropriate time so that the microservice is available in time for a potential handover of a communication session from the current edge device 302 to the next edge device 304. Thus, deploying the microservice predicted to be executed may be started at a third time point on the next edge device (the third time point is before the second time point, and the third time point is determined based on the time required to deploy the microservice predicted to be executed). In the above example, the microservice 204 has a startup time of 40 milliseconds on the edge device D1, and therefore, if the microservice 204 is predicted to be needed next and the next edge device 304 is determined to be the edge device D1, the microservice prediction module 120 must start deploying the microservice 204 on the edge device at least 40 milliseconds before the client device 310 reaches the next edge device 304 (which is also the edge device D1 in this example). As described above, the time that the client device 310 is predicted to reach or be within handoff range of the next edge device 304 may be determined at 406 .

[0034] In addition, if it is determined that the next edge device 304 can deploy 10 microservices, the next edge device 304 will deploy the 10 that are most likely to be needed. In the example environment of FIG. 2, the system deploys three instances of 222 and three instances of 204 to serve the five client devices currently using 214, three instances of 206 to serve the client devices currently using 204, and one instance of 208 to serve the client devices currently using 206. For ease of illustration, this example assumes a one-to-one correlation between instances of a microservice and users, but in reality, one instance of a microservice may serve multiple users. In another embodiment, an optional step may be added to handle the case where a device can only support a few microservices that are not enough to meet the needs of all users connected to the device. For example, a prediction may determine that an edge device needs to deploy 15 microservices because they are most likely to be needed by all client devices, but the edge device only has capacity for 10. In this case, the remaining five microservices may be dispatched to other neighboring edge devices that can support the client device, and a prioritization or allocation scheme may be proposed to handle the microservices in that scenario. In this alternative, the wake-up time and the point in time when the client device 310 is predicted to reach or be within the handoff range of the neighboring edge device 304 may be determined as described above.

[0035] At 410, the microservice prediction module 120 collects historical data about the client devices connected to the next edge device 304 and the microservices running on the next edge device, and utilizes a supervised machine learning model to create a profile of the microservices most likely to be executed next and improve its prediction, as further described in FIG. 5.

[0036] Referring to FIG. 5, the diagram illustrates example components or modules of a microservice prediction process according to at least one embodiment. According to one embodiment, the process may include a microservice prediction module 120 that utilizes supervised machine learning 520 to determine the likelihood of a microservice to be required next. The supervised machine learning model may use a suitable machine learning algorithm, such as Support Vector Machines (SVM) or random forests. The microservice prediction module 120 may monitor the actual execution of the microservice, as described in 410, and track client device information 502, i.e., both a list of client devices currently connected from adjacent edge devices and a list of client devices currently connected to the next edge device 404, and also analyze current state information 504, i.e., the state received by all edge devices in 402. The microservice prediction module 120 uses the above information to determine 510 the likelihood of execution that the microservice will be needed next, and updates the probability originally determined from the configuration file in step 210 above. For example, it may be discovered that the user selects 222 after 214 80% of the time (as opposed to the 50% probability in the configuration file), and the microservice prediction module 120 may adapt to that change and update its prediction, or probability of likelihood, for the next microservice that needs to execute.

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

[0038] Cloud computing is a model of service delivery 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 administrative effort or interaction with the service provider. The cloud model may include at least five characteristics, at least three service models, and at least four deployment models.

[0039] Its features are as follows.

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

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

[0042] Resource Pooling: Provider computing resources are pooled to serve multiple consumers using a multi-tenant model, and various physical and virtual resources are dynamically allocated and reallocated according to demand. Consumers generally have no control or knowledge of the exact location of the provided resources, but are said to be location-independent in that they may be able to specify a location at a higher level of abstraction (e.g., country, state, or data center).

[0043] Rapid Elasticity: Capabilities can be rapidly and elastically provisioned, sometimes automatically, rapidly scaled out, rapidly released and rapidly scaled in. To the consumer, the capabilities available for provisioning are often unlimited and can be purchased in any quantity at any time.

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

[0045] The service model is as follows:

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

[0047] PaaS Platform as a Service: The capability offered to a consumer to deploy consumer-created or acquired applications, created 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 networks, servers, operating systems, or storage, but has control over the deployed applications and, potentially, the application hosting environment configuration.

[0048] Infrastructure as a Service (IaaS): The capability offered to consumers to provision processing, storage, network, and other basic computing resources on which they can deploy and run any software, which may include operating systems and applications. The consumer does not manage or control the underlying cloud infrastructure, but has control over the operating systems, storage, deployed applications, and in some cases, limited control over selection of network components (e.g., host firewalls).

[0049] The deployment models are as follows:

[0050] Private Cloud: Cloud infrastructure is operated exclusively for an organization. The cloud infrastructure may be managed by the organization or a third party, and may be on-premises or off-premises.

[0051] Community Cloud: Cloud infrastructure is shared by several organizations and supports a particular community with common concerns (e.g., mission, security requirements, policies, and compliance considerations). The cloud infrastructure may be managed by the organizations or a third party, and may reside on-premise or off-premise.

[0052] Public Cloud: The cloud infrastructure is available to the general public or a large industry group and is owned by an organization that sells cloud services.

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

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

[0055] Referring now to FIG. 6, an exemplary cloud computing environment 50 is illustrated. As shown, the cloud computing environment 50 includes one or more cloud computing nodes 10, with which local computing devices used by cloud consumers, such as personal digital assistants (PDAs) or mobile phones 54A, desktop computers 54B, laptop computers 54C, or automobile computer systems 54N, or combinations thereof, may communicate. The nodes 10 may communicate with each other. The nodes 10 may be physically or virtually grouped into one or more networks, such as a private cloud, a community cloud, a public cloud, or a hybrid cloud, or combinations thereof, as described herein above (not shown). This allows the cloud computing environment 50 to provide infrastructure, platform, or software, or combinations thereof, as a service without the cloud consumer having to maintain resources on the local computing device. It will be understood that the types of computing devices 54A-N shown in FIG. 6 are intended to be illustrative only, and that the computing node 10 and cloud computing environment 50 can communicate with any type of computerized device (e.g., using a web browser) via any type of network or network-addressable connection or combination thereof.

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

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

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

[0059] In one example, the management layer 80 may provide the functions described below. Resource provisioning 81 provides dynamic procurement of computing and other resources utilized to execute tasks within the cloud computing environment. Metering and pricing 82 provides cost tracking as resources are utilized within the cloud computing environment and billing or invoicing for the consumption of these resources. In one example, these resources may include application software licenses. Security provides identity verification for cloud consumers and tasks, and 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 allocation and management of cloud computing resources such that required service levels are met. Service level agreement (SLA) planning and fulfillment 85 provides pre-provisioning and procurement of cloud computing resources where future requirements are forecasted according to SLAs.

[0060] Workload tier 90 provides examples of functions for which a cloud computing environment may be utilized. Examples of workloads and functions that may be provided from this tier include mapping and navigation 91, software development and lifecycle management 92, virtual classroom instructional delivery 93, data analytics processing 94, transaction processing 95, and predictive selection of virtual reality content 96 to proactively adapt to later available bandwidth conditions.

[0061] The present invention may be a system, method, or computer program product, or a combination thereof, that may include one or more computer-readable storage media having computer-readable program instructions for causing a processor to perform aspects of the present invention.

[0062] The computer readable storage medium can be a tangible device capable of holding and storing instructions for use by an instruction execution device. The computer readable storage medium 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 the computer readable storage medium includes the following: a portable computer diskette, 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 disk (DVD), a memory stick, a floppy disk, a mechanically encoded device such as a punch card or a ridge structure in a groove in which instructions are recorded, or any suitable combination thereof. As used herein, a computer-readable storage medium should not be construed as a transitory signal 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 electrical wires.

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

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

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

[0066] These computer readable program instructions may be provided to a processor of a computer or other programmable data processing apparatus such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate means for implementing the functions / operations identified in one or more blocks of the flowcharts or block diagrams, or combinations thereof, to produce a machine. These computer readable program instructions may also be stored in a computer readable storage medium capable of directing a computer programmable data processing apparatus or other device, or combinations thereof, to function in a particular manner, such that the computer readable storage medium having stored thereon instructions includes an article of manufacture including instructions that implement aspects of the functions / operations identified in one or more blocks of the flowcharts or block diagrams, or combinations thereof.

[0067] The computer readable program instructions may also be loaded onto a computer, other programmable data processing apparatus, or other device such that the instructions, which execute on a computer, other programmable data processing apparatus, or other device, implement the functions / operations identified in one or more blocks of the flowcharts or block diagrams, or combinations thereof, to cause the computer, other programmable apparatus, or other device to perform a series of operational steps to generate a computer-implemented process.

[0068] The flowcharts and block diagrams in the drawings 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 the flowcharts or block diagrams may represent a module, segment, or portion of an instruction, which includes one or more executable instructions for implementing one or more specified logical functions. In some alternative implementations, the functions shown in the blocks may occur out of the order shown in the drawings. For example, two blocks shown in succession may in fact be accomplished as one step performed simultaneously, substantially simultaneously, partially or fully in a time-overlapping manner, depending on the functions involved, or the blocks may be performed in the reverse order. It should also be noted that each block of the block diagrams or flowchart diagrams or combinations thereof, as well as combinations of multiple blocks of the block diagrams or flowchart diagrams or combinations thereof, may be implemented by a special purpose hardware-based system that performs the specified functions or operations, or may execute a combination of special purpose hardware and computer instructions.

[0069] The description of various embodiments of the present invention is presented for illustrative purposes, but is not intended to be exhaustive or limited to the disclosed embodiments. Similarly, examples of features or functions of the embodiments of the present disclosure described herein, whether used in a particular embodiment description or described as an example, are not intended to limit the embodiments of the present disclosure described herein or to limit the disclosure to the examples described herein. 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 in this specification have been selected to explain the principles of the embodiments, practical applications or technical improvements to the technology found in the market, or to enable those skilled in the art to understand the embodiments disclosed herein.

Claims

1. 1. A computer-implemented method for predictively deploying microservices at edge devices in a network, comprising: executing an application on a client device, the application having a set of microservices executable on any one of the edge devices in a set of two or more edge devices; determining a state of the client device at a first time, where the state includes one or more microservices currently running for the client device, and for each currently running microservice, an edge device running the microservice; predicting one or more microservices that are likely to be executed at a second time point subsequent to the first time point; predicting a location of the client device at the second time; and determining a next edge device in the set of edge devices for executing one or more microservices predicted to execute at the second time based on the predicted location; The computer-implemented method comprising:

2. Determining a state of the client device at a first time transmitting the determined state of the client device to at least one edge device in the set of two or more edge devices. The computer-implemented method of claim 1 , further comprising:

3. predicting one or more microservices likely to be executed at a second time point subsequent to the first time point; determining, for each of the one or more microservices currently executing for the client device, a probability that a microservice that is not currently executing for the client device will be requested by the client device when each currently executing microservice terminates; and Ranking the microservices in order of the determined probabilities. The computer-implemented method of claim 1 or 2, further comprising:

4. determining, for each of the one or more microservices currently executing for the client device, a probability that a microservice that is not currently executing for the client device will be requested by the client device when each currently executing microservice terminates; Determining, using a machine learning model, a probability that a microservice that is not currently running for the client device will be requested by the client device when a currently running microservice is terminated. The computer-implemented method of claim 3 , further comprising:

5. predicting a location of the client device at the second time; determining a direction and speed of movement of the client device; and predicting a location of the client device at a second time based on the determined direction and speed of movement of the client device; The computer-implemented method of any one of claims 1 to 4, further comprising:

6. determining a next edge device in the set of edge devices for executing the one or more microservices predicted to execute at the second time based on the predicted location; Determining a computational capability of a first edge device; determining a workload of the first edge device; predicting a level of operational service if the predicted one or more microservices likely to be executed are executed at the first edge device at the second time; and selecting the first edge device as a next edge device if the level of operational service is equal to or greater than a threshold level of operational service; and evaluating the first edge device as a candidate for a next edge device by The computer-implemented method of any one of claims 1 to 5, further comprising:

7. not selecting the first edge device as the next edge device if the level of operational service is below the threshold level of operational service; and evaluating a second edge device as a candidate for the next edge device; The computer-implemented method of claim 6 , further comprising:

8. determining an amount of time required to deploy the one or more microservices that are predicted to run on the determined next edge device at the second time; and initiating deployment of the one or more microservices predicted to run on a next edge device at a third time on the determined next edge device, where the third time is before the second time and the third time is determined based on the determined time required to deploy the one or more microservices predicted to run on the determined next edge device. The computer-implemented method of any one of claims 1 to 7, further comprising:

9. Determining an amount of time required to deploy the one or more microservices that are predicted to run on the determined next edge device at the second time; determining a computational capability of the determined next edge device; and determining a workload for the determined next edge device; The computer-implemented method of claim 8 , further comprising:

10. 1. A computer system for predictively deploying microservices on edge devices in a network, comprising: a computer system comprising one or more processors, one or more computer readable memories, one or more computer readable tangible media, and program instructions stored on at least one of the one or more tangible media for execution by at least one of the one or more processors via at least one of the one or more readable memories, wherein the computer system comprises: executing an application on a client device, the application having a set of microservices executable on any one of the edge devices in a set of two or more edge devices; determining a state of the client device at a first time, where the state includes one or more microservices currently running for the client device, and for each currently running microservice, an edge device running the microservice; predicting one or more microservices that are likely to be executed at a second time point subsequent to the first time point; predicting a location of the client device at the second time; and determining a next edge device in the set of edge devices for executing one or more microservices predicted to execute at the second time based on the predicted location; The computer system is capable of executing a method comprising:

11. Determining a state of the client device at a first time transmitting the determined state of the client device to at least one edge device in the set of two or more edge devices. The computer system of claim 10 further comprising:

12. predicting one or more microservices likely to be executed at a second time point subsequent to the first time point; determining, for each of the one or more microservices currently executing for the client device, a probability that a microservice that is not currently executing for the client device will be requested by the client device when each currently executing microservice terminates; and Ranking the microservices in order of the determined probabilities.

12. The computer system of claim 10 or 11, further comprising:

13. determining, for each of the one or more microservices currently executing for the client device, a probability that a microservice that is not currently executing for the client device will be requested by the client device when each currently executing microservice terminates; Determining, using a machine learning model, a probability that a microservice that is not currently running for the client device will be requested by the client device when a currently running microservice is terminated. The computer system of claim 12 further comprising:

14. predicting a location of the client device at the second time; determining a direction and speed of movement of the client device; and predicting a location of the client device at a second time based on the determined direction and speed of movement of the client device; The computer system of any one of claims 10 to 13, further comprising:

15. determining a next edge device in the set of edge devices for executing the one or more microservices predicted to execute at the second time based on the predicted location; Determining a computational capability of a first edge device; determining a workload of the first edge device; predicting a level of operational service if the predicted one or more microservices likely to be executed are executed at the first edge device at the second time; and selecting the first edge device as a next edge device if the level of operational service is equal to or greater than a threshold level of operational service; and evaluating the first edge device as a candidate for a next edge device by The computer system of any one of claims 10 to 14, further comprising:

16. not selecting the first edge device as the next edge device if the level of operational service is below the threshold level of operational service; and evaluating a second edge device as a candidate for the next edge device; 16. The computer system of claim 15, further comprising:

17. determining an amount of time required to deploy the one or more microservices that are predicted to run on the determined next edge device at the second time; and initiating deployment of the one or more microservices predicted to run on a next edge device at a third time on the determined next edge device, where the third time is before the second time and the third time is determined based on the determined time required to deploy the one or more microservices predicted to run on the determined next edge device. The computer system of any one of claims 10 to 16, further comprising:

18. Determining an amount of time required to deploy the one or more microservices that are predicted to run on the determined next edge device at the second time; determining a computational capability of the determined next edge device; and determining a workload for the determined next edge device; 20. The computer system of claim 17, further comprising:

19. 1. A computer program product for predictively deploying microservices on edge devices in a network, comprising: executing an application on a client device, the application having a set of microservices executable on any one of the edge devices in a set of two or more edge devices; determining a state of the client device at a first time, where the state includes one or more microservices currently running for the client device, and for each currently running microservice, an edge device running the microservice; predicting one or more microservices that are likely to be executed at a second time point subsequent to the first time point; predicting a location of the client device at the second time; and determining a next edge device in the set of edge devices for executing one or more microservices predicted to execute at the second time based on the predicted location; The computer program causes a computer to execute the above.

20. Determining a state of the client device at a first time transmitting the determined state of the client device to at least one edge device in the set of two or more edge devices.

20. The computer program product of claim 19, further comprising:

21. predicting one or more microservices likely to be executed at a second time point subsequent to the first time point; determining, for each of the one or more microservices currently executing for the client device, a probability that a microservice that is not currently executing for the client device will be requested by the client device when each currently executing microservice terminates; and Ranking the microservices in order of the determined probabilities.

21. The computer program of claim 19 or 20, further comprising:

22. determining, for each of the one or more microservices currently executing for the client device, a probability that a microservice that is not currently executing for the client device will be requested by the client device when each currently executing microservice terminates; Determining, using a machine learning model, a probability that a microservice that is not currently running for the client device will be requested by the client device when a currently running microservice is terminated.

22. The computer program product of claim 21 further comprising:

23. predicting a location of the client device at the second time; determining a direction and speed of movement of the client device; and predicting a location of the client device at a second time based on the determined direction and speed of movement of the client device; 23. The computer program of claim 19, further comprising:

24. determining a next edge device in the set of edge devices for executing the one or more microservices predicted to execute at the second time based on the predicted location; Determining a computational capability of a first edge device; determining a workload of the first edge device; predicting a level of operational service if the predicted one or more microservices likely to be executed are executed at the first edge device at the second time; and selecting the first edge device as a next edge device if the level of operational service is equal to or greater than a threshold level of operational service; and evaluating the first edge device as a candidate for a next edge device by The computer program product of any one of claims 19 to 23, further comprising:

25. not selecting the first edge device as the next edge device if the level of operational service is below the threshold level of operational service; and evaluating a second edge device as a candidate for the next edge device; 25. The computer program product of claim 24, further comprising:

Images