Automated life cycle management

Abstract

A service automation system in a microservices-based communication network is provided to automate the deployment of new software release. When a new version of a microservice deployed in a service chain is released, the system conducts a comprehensive analysis of deployed microservices and their versions. It identifies direct and indirect relation and propagation effects onto other microservices, explores dependencies, and determines the essential microservices for the upgrade including their respective versions. Moreover, the system intelligently calculates the optimal number of instances for the updated version based on user load and requested users to migrate to the new version. Also, the service automation determines ideal deployment locations in the substrate network for new versions placement.

Description

[0001] AUTOMATED LIFE CYCLE MANAGEMENT

[0002] TECHNICAL FIELD

[0003] The present disclosure relates generally to automated life cycle management systems for communication networks and, more particularly, to service automation in a microservice-based network architecture.

[0004] BACKGROUND

[0005] A microservice-based communication network consists of independently developed and deployed microservices. The ongoing, iterative adaptation and upgrading of these microservices are essential to keep pace with evolving user requirements. In a microservice-based architecture, the delivery of a service is orchestrated through a thoughtful selection of microservices, forming what we term a service chain. The intricacies emerge when upgrading a microservice to a new version, as this may trigger failures in other dependent microservices connected directly or indirectly in the service chain, owing to version incompatibility.

[0006] Our understanding of microservices dependencies extends to the precedence of one microservice over another, shaping the execution order and position within the service chain. Adding to the complexity, a microservice instance can be shared across various service requests, further complicating the web of dependencies. Recognizing these dependencies becomes imperative as the first step, prompting the need to upgrade other dependent microservices systematically to ensure uninterrupted system availability.

[0007] Beyond the direct connections and dependencies between microservices, there are also indirect and complicated relationships between various versions of an individual microservice and other microservices. These complex dependencies significantly undermine the maintainability of microservice systems, particularly as systems undergo evolution to accommodate changing user requirements.

[0008] On the other hand, microservice providers often deploy multiple instances of a specific version concurrently and in parallel, utilizing load balancing to distribute users step-by-step among these instances. This scenario, however, introduces a challenge when some users persistently request older versions. Hence, it is advisable for developers not to update all deployed microservice instances simultaneously to maintain system availability. Instead, a more effective approach is needed to enable a gradual migration of users to the new version, preserving continuous system availability while accommodating diverse user preferences. To handle these challenges better, a model is needed for upgrading versions that can implement the best plan for evolving the system.

[0009] SUMMARY

[0010] The present disclosure provides a framework for automated life cycle management (LCM) of microservices in a communication network. The service automation system automates the deployment of new software releasees and migration of users considering user load, instance distribution, upgrade dependencies, locations, workload, etc. The service automation system creates new microservice instances in a stepwise fashion and determines when to remove old instances and how to redistribute workload from old to new instances.

[0011] When deploying a new version of a microservice, the service automation system conducts a comprehensive analysis of deployed microservices and their versions. It identifies direct and indirect relation and propagation effects onto other microservices, explores dependencies, and determines the essential microservices for the upgrade including their respective versions. Moreover, the system intelligently calculates the optimal number of instances for the updated version based on user load and requested users to migrate to the new version. Also, the service automation determines ideal deployment locations in the substrate network for new versions placement.

[0012] One aspect of the disclosure comprises a method of service automation implemented by a service automation system in a microservices-based communication network. The method comprises computing or otherwise obtaining a deployment graph representing a plurality of deployed microservices in service chain and interconnections between the deployed microservices. The method further comprises generating, based on the deployment graph, a propagation graph representing dependencies between a target microservice deployed in the service chain to be replaced and the other deployed microservices in the service chain. The method further updating a version compatibility graph to include a new version of the target microservice, wherein the updated version compatibility graph indicates compatibility between the new version of the target microservice and other deployed microservices in the service chain. The method further comprises identifying, based on the propagation graph and the updated version compatibility graph, one of more affected microservices in the service chain impacted by the new version of the target microservices. The method further deploying the new version of the target microservice and a new version of each affected microservice in the service chain.

[0013] A second aspect of the disclosure comprises a service automation system for a microservices-based communication network. The services automation system is configured to compute or otherwise obtain a deployment graph representing a plurality of deployed microservices in service chain and interconnections between the deployed microservices. The services automation system is further configured to generate, based on the deployment graph, a propagation graph representing dependencies between a target microservice deployed in the service chain to be replaced and the other deployed microservices in the service chain. The services automation system is further configured to update a version compatibility graph to include a new version of the target microservice, wherein the updated version compatibility graph indicates compatibility between the new version of the target microservice and other deployed microservices in the service chain. The services automation system is further configured to identify, based on the propagation graph and the updated version compatibility graph, one of more affected microservices in the service chain impacted by the new version of the target microservices. The services automation system is further configured to deploy the new version of the target microservice and a new version of each affected microservice in the service chain.

[0014] A third aspect of the disclosure comprises a service automation system for a microservices-based communication network. The service automation system comprises memory storing executable program instructions for service automation in a communication network and processing circuitry configured by the executable program instructions stored memory to compute or otherwise obtain a deployment graph representing a plurality of deployed microservices in service chain and interconnections between the deployed microservices. The processing circuitry is further configured to generate, based on the deployment graph, a propagation graph representing dependencies between a target microservice deployed in the service chain to be replaced and the other deployed microservices in the service chain. The processing circuitry is further configured to update a version compatibility graph to include a new version of the target microservice, wherein the updated version compatibility graph indicates compatibility between the new version of the target microservice and other deployed microservices in the service chain. The processing circuitry is further configured to identify, based on the propagation graph and the updated version compatibility graph, one of more affected microservices in the service chain impacted by the new version of the target microservices. The processing circuitry is further configured to deploy the new version of the target microservice and a new version of each affected microservice in the service chain.

[0015] A fourth aspect of the disclosure comprises a computer program for a service automation system in a microservices-based communication network. The computer program comprises executable instructions that, when executed by processing circuitry in the service automation system, causes it to perform the method according to the first aspect. A fifth aspect of the disclosure comprises a carrier containing a computer program according to the fourth aspect. The carrier is one of an electronic signal, optical signal, radio signal, or a non-transitory computer readable storage medium.

[0016] BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1 illustrates a microservice-based communication network implemented using virtual network functions.

[0018] Figure 2 illustrates the service chain of a virtual network function.

[0019] Figure 3 illustrates one example of a version compatibility chart for the service chain shown in Figure 2.

[0020] Figure 4 is a functional block diagram of a service automation system for a microservice-based communication network.

[0021] Figures 5A-5C illustrate the evolution of the version compatibility graph for the service chain shown in Figure 2 when a new version of a microservice S3 is released.

[0022] Figures 6A - 6C illustrate one example of a depth-first search of a propagation graph for the service chain shown in Figure 2.

[0023] Figures 7A - 7F illustrate the deployment and integration of new microservices when a new version of microservice S3 is released.

[0024] Figures 8A and 8B illustrate placement of the new version microservice S3.

[0025] Figure 9 is a flow chart showing a method implemented by a service automation system of deploying new releases of a microservice.

[0026] Figure 10 is a functional block diagram of a service automation system for a microservices-based communication network.

[0027] DETAILED DESCRIPTION

[0028] Referring now to the drawings, a service automation system 100 is shown and described herein in the context of a cloud-based communication network. Those skilled In the art will appreciate, however, that the techniques described herein are not limited to use in cloud=based network, but are more generally applicable to in any microservice-based network with an interface and behavior creating interoperability dependencies.

[0029] Network Function Virtualization (NFV) is a virtualization technology for communication networks that eschews proprietary hardware and implements network functions (NFs) in the communication network as software running on industrystandard servers supported by high volume storage. A virtual network function (VNF) or containerized network function (CNF) implemented as a software component can be deployed at essentially any location within a cloud infrastructure without the need of installing new equipment. NFV enables rapid deployment of new services, ease of scalability, and reduced redundancy in the NFs.

[0030] Figure 1 illustrates an exemplary cloud computing model 10 for a communication network using virtualized NFs (VNFs) 25 and containerized NFs (CNFs) 35. Instead of proprietary hardware, the cloud computing model 10 uses industry standard servers, high volume storage and generic networking hardware that are organized into one or more data centers 15. The physical resources of the data centers 15 are shared via a virtualization layer (e.g., OpenStack or VMware) 20 that provides infrastructure as a service (laaS) and / or a containerization layer (e.g., Kubernetes) 30 that provides containers as a service (CaaS). The containerization layer 30 may be deployed on bare metal (BM) or on a virtual machine (VM) provided by the virtualization layer 20. The various NFs in a communication network are implemented as software running on a VM provided by a virtualization layer 20, or in a container provided by a containerization layer 30. The cloud computing model 10 provides ubiquitous, on-demand access to cloud resources that enables rapid provisioning and configuration of VNFs 25 and CNFs 35.

[0031] A NFV Management and Orchestration (MANO) architecture provides a framework for the management and orchestration of the network resources including computing, networking, storage, virtual machine (VM) and container resources. NFV MANO includes three main components: a Virtualized Infrastructure Manager (VIM) 40, a NFV Orchestrator 45 and a Virtual NF Manager (VNFM) 50. The VIM 40 is responsible for controlling, managing, and monitoring the compute, storage, and network hardware provided by the datacenter. The NFV Orchestrator 45 is responsible for resource coordination including the creation, allocation and termination of VMs and containers that are used by the VNFs. The VNFM 50 is responsible for the life cycle management of VNFs and CNFs. VNFM 50 operations include instantiation of VNFs / CNFs 25, 35, scaling of VNFs / CNFs 25, 35, updating and / or upgrading VNFs / CNFs 25, 35 and termination of VNFs / CNFs 25, 35. A VNFM 50 can be assigned to either a single VNF / CNF 25, 35 instance or to multiple VNF / CNF 25, 35 instances. The VNFs / CNFs 25, 35 managed by a VNFM 50 can be all of the same type of NF or a mix of different types of NFs.

[0032] In a microservices-based architecture, the function of an NF (e.g., AMF, SMF, or PCF) is implemented by a plurality of independently developed and deployed microservices forming what is called a service chain. Figure 2 illustrates an exemplary service chain implementing the functionality of a NF. The various microservices may, for example, provide services such as load balancing services, configuration management services, application logic services, and state management services. These broad categories of services can include a number of dedicated microservices. For example, application logic services may include dedicated microservices for registration, service discovery, and subscriptions / notifications according to 3GPP standards. Some microservices are common to many NFs so instances of the same microservice may be part of the service chain for different NFs. The ongoing, iterative adaptation and upgrading of these microservices are essential to keep pace with evolving user requirements.

[0033] Figure 2 is a deployment graph illustrating the service chain for a NF in a communication network, which may comprise a VNF 25 or CNF 35. In this example, the functionality is implemented by a sequence of microservices (S1 , S2, S3, S4, S5, and S6) starting with source S1 and ending at destinations S5 and S6. Each microservice is represented as a tuple (type, version) which represents the microservice type and its current version, respectively. In the example service chain, there are two instances of microservice S3 denoted them as S3i and S32. To distinguish the instances, the indices indicate the instance number. Users are distributed between these instances. In the deployment graph, each dedicated microservice is labeled to show the number of users served by the particular instance of the microservice.

[0034] Figure 3 is a version compatibility graph for the service chain shown in Figure 2. The version compatibility graph is an undirected graph. Each node in the version compatibility graph represents a particular type and version of a dedicated microservice indicated by the tuple (type, version), Edges between the nodes represent compatibility of the connected microservices and their respective versions. This compatibility ensures seamless collaboration, allowing the interconnected microservices to effectively operate together. In Figure 3, node (S3,0), is linked to nodes (S4,0), (S2,0), and (S7,0). This connectivity indicates that microservice (S3,0) is compatible with microservice (S4,0), and vice versa. Microservice (S3,0) is also compatible with (S7,0) and (S2,0). Note, however, that microservice S7 is not part of the service chain in Figure 2.

[0035] From time to time, the microservices comprising the service chain may be upgraded. As an example, assume that microservice S3 is upgraded from version 0 (S3,0) to version 1 (S3, 1 ). The deployment graph in Figure 2 shows that microservice S3 is connected in the service chain to microservices S2 and S4. The direct connection and dependency between two microservices, denoted as (S2,0) and (S4,0), to instances of (S3, 0) indicate that they will be directly impacted by the introduction of the new version of S3. This impact potentially extends to other indirectly connected microservices, e.g., S1 , S5, and S6. One challenge in automating LCM of NFs in the communication network is determining which microservices are dependent and require upgrading, the number of new instances needed for deployment, the quantity of users to migrate to the new version instances, the optimal location for deploying these new instances, and the timing for removing the old version instance if it is no longer needed.

[0036] One aspect of the present disclosure comprises an automation framework for a service automation system (SAS) 100 to automate the deployment and migration process for new software releasees with respect to user load, instance distribution, upgrade dependencies, locations, workload, etc. The creation of new instances, removal of old instances, and redistribution of the workload from old to new instances are performed in a stepwise fashion. To migrate uses to a new version of a microservice, a comprehensive analysis of deployed microservices and their versions is performed to identify direct and indirect relations and propagation effects onto other microservices, explore dependencies, and determine the essential microservices for the upgrade including their respective versions. The service automation system 100 intelligently calculates the optimal number of instances for the updated version based on user load and requested users to migrate to the new version. Also, the service automation system 100 determines ideal deployment locations in the substrate network for new versions placement. The service automation system 100 may be implemented, for example, by the VNFM 50 or another network node the management domain.

[0037] The automation framework facilitates the stepwise migration of users from old version instances to new version instances during runtime. This transition is achieved by dynamically creating the minimum necessary number of instances for the new version, guided by microservices analysis. Additionally, for deploying new version instances, the framework ensures the optimal placement of these instances on substrate nodes. This strategic placement guarantees uninterrupted traffic flow through the service chain while satisfying version compatibility requirements.

[0038] The service automation system 100 has two main inputs: a deployment graph (see, e.g., Figure 2) providing a snapshot of the currently deployed microservices in the service chain, and a version compatibility graph (see, e.g., Figure 3) that represents compatibility between microservices and their versions. As previously noted, the deployment graph includes the type and version of the currently deployed microservices and interconnections between the microservices. The functionality of the service automation system 100 has three main components: propagation graph generation, microservice analysis, and microservice placement. Propagation graph generation outputs a propagation graph depicting the relationships between the target microservice to be upgraded on other microservices, and the impacts, both direct and indirect, of the changes on other microservices. The propagation graph is specific to each microservice version release. Microservice analysis includes the analysis of necessary adjustments in the service chain and outputs detailed information on required changes to ensure smooth deployment of the new version among currently deployed microservices. Microservice placement determines how to deploy the new version of a microservice and output the “best” location and substrate node to serve as a host for the new version of the microservice.

[0039] Figure 4 is a functional block diagram illustrating various logical functions in an exemplary service automation system 100. The service automation system 100 comprises a data collection module 110, updating module 120, propagation graph generator 130, analysis module 140, planning module 150, and placement allocator 160.

[0040] The data collection module 110 collects and maintains information on currently deployed microservices represented as a deployment (see, e.g. Figure 2) in the service chain and their version compatibility graph (see, e.g., Figure 3). The data collection module 110 is responsible for gathering new information when a new version is released for a particular microservice or set of microservices in the service chain. The information includes the type of microservice, its new version, the maximum user capacity to be serviced by the new version, compatibility information with other microservices and versions. The data collection module 110 provides the current version compatibility graph and information about the new releases of specific microservices to the updating module 120.

[0041] The updating module 120 uses the new version compatibility information provided by the data collection module 110 to update the version compatibility graph to include the new releasees of a microservice. The updated version compatibility graph is provided to the analysis module 140.

[0042] The propagation graph generator 130 receives the current deployment graph from the data collection module 110 and generates a propagation graph for a target microservice in the service chain. The propagation graph is specific to each type and version of a microservice. The propagation graph is a tree graph with the target microservice to be upgraded as the root. Direct edges in the graph indicate other microservices that are directly dependent on the requested microservice, and by traversing the tree, all other indirectly dependent microservices are identified.

[0043] The analysis module 140 receives the updated version compatibility graph from the updating module 120 and propagation graph from the propagation graph generator 130. The analysis module 140 analyzes the entire system to identify all dependent microservices that need upgrading and determines the version to which the dependent microservices should be upgraded. This analysis captures the required information from two elements of propagation graph and version compatibility graph. The analysis module output to the planning module 150 information about the dependent microservices that need to be upgraded along with the target microservice.

[0044] The planning module 150 receives the information about the target microservice and dependent microservices in the service chain that need to be upgraded. Based on the number of users in each old version instance, and the number of users to be migrated, he planning module employs a greedy mechanism to calculates the minimum number of new instances needed to handle user migration to the new version instances for all affected microservices. The placement allocator 160 receives the number of instances of the target microservice and dependent microservices to need to be deployed to meet requirements of any service level agreement (SLAs) from the planning module. The placement allocator monitors the current substrate network to gather information about available capacity of the current network and potential candidate substrate nodes on which to deploy the new instances of the target microservice and dependent microservices.

[0045] The process of deploying the new microservice instance and migrating users comprises two phases: the analysis phase and the deployment phase. In the analysis phase, dependent microservices to be upgraded along with the target microservice are identified. This analysis is based on the deployment graph, version compatibility graph, and propagation graph. Based on examination of these graphs, the service automation system 100 determines the relationships between microservices and their versions, and facilitates informed decision-making regarding upgrades.

[0046] The analysis phase also includes planning analysis to determine the number of new instances for each upgraded microservice is calculated. A greedy mechanism is used to determine the optimal migration process taking into account version compatibility, propagation impact, number of users, and resource constraints for the new version. This greedy approach optimizes resource utilization by creating new instances only as needed, considering the number of users in the old version instances. This contrasts with existing approaches, which do not take into account the number of users when creating new version instances.

[0047] In the deployment phase, the service automation system 100 determines the placement of the new microservice instances on substrate nodes to ensure uninterrupted service delivery. The service automation system 100 ensures that the substrate nodes selected to host the new microservice instances have connectivity to other microservices in the service chain so that service is not disrupted. As an example, the process of upgrading a target microservice employed in a service chain of an NF comprises the following steps:

[0048] • Step 1 - Obtain initial deployment graph and version compatibility graph

[0049] • Step 2 - Update version compatibility graph

[0050] • Step 3 - Generate propagation graph

[0051] • Step 4 - Identify impacted microservices

[0052] • Step 5 - Determine required number of instances for each microservice being upgraded.

[0053] • Step 6 - Determine gradual migration plan for integrating new microservice instances

[0054] • Step 7 - Integrate new microservice instances into service chain and migrate users .

[0055] In Step 1 , the service automation system 100 generates or otherwise obtains an initial deployment graph and version compatibility graph. The initial deployment graph depicts the current microservices in the service chain deployed on substrate nodes, along with their respective versions. These microservices collaborate to create a service chain, delivering the desired service. A example deployment graph for a service chain is illustrated in Fig. 2 comprising microservice S1 , S2, S3, S4, S5, and S6. The initial version compatibility for the deployed microservices provided by the developer is represented in the version compatibility graph. An example version compatibility graph in shown in Figure 3.

[0056] In Step 2, the initial version compatibility graph is updated to include the new release of the target microservice. This task is handled by the updating module 120 and is triggered when a new release of a microservice is introduced. The updating module 120 obtains the initial compatibility graph and compatibility information for the new release of a microservice from the data collection module 110. Figures 5A - 5C illustrate the evolution of the version compatibility graph. Figure 5A shows the initial version compatibility graph for microservice S3, which is the target for an upgrade. The version compatibility graph is a tree graph with microservice (S3,0) as its root. The version compatibility graph shows that version 0 of S3 is compatible with version 0 of S4, S7 and S2. (S4,0) is compatible with version 0 of S5 and S6. (S2,0) is compatible with version 0 of S1 . Figure 5B shows the compatibility of version 1 of S3 with other microservices In the service chain. In this example, version 1 of S3 is compatible with version 0 of S4 and S7, and with version 1 of S2. Microservice (S2,1) is compatible with version 1 of S1. Figure 5C shows the final updated version compatibility chart that essentially combines the graphs in Figured 5A and 5B into a single graph.

[0057] In Step 3, the propagation graph generator 130 generates a propagation graph to understand the impact of the change on other microservices in the service chain. Identifying dependent microservices is important for devising the upgrade plan. An example propagation graph is shown in Figure 6A. This graph is a tree graph, with (S3,0) as the root. Direct edges in the propagation graph indicate immediately affected microservices one level removed from the root and indirectly dependent microservices at subsequent levels. In Figure 6A, microservices (S2,0) and (S4,0) are directly dependent on (S3,0), while microservices (S1 ,0), (S5,0), and (S6,0) are indirectly dependent. It should be noted, however, that not all dependent microservices will be impacted. Some dependent microservices may be compatible with the new version of the target microservice.

[0058] In Step 4, the impacted microservices are identified. This step is performed by the analysis module 140 by correlating compatibility information embodied In the updated version compatibility graph with dependency information embodied In the propagation graph. Based on the propagation graph, the analysis module 140 identifies the microservices that are directly or indirectly dependent on the target microservice by performing a depth first search of the propagation graph. For each node discovered in the graph, the analysis module 140 determines the compatibility of the microservice represented by the node based on the updated version compatibility graph. In one example, the analysis module starts with the left-most branch which begins with microservice (S3, 0) and fully explores the branch before backtracking. After reaching the leaf of a branch, the analysis module 140 backtracks to find the next unexplored branch. This process repeats until each node in the main branch has been visited.

[0059] Figure 6B shows the left-most branch of the propagation graph which includes (S2,0) and (S1 ,0). Starting with (S2,0), the analysis module determines that (S2, 0) is not compatible with (S3, 1 ) prompting an upgrade of (S2,0) to version 1 . Proceeding to (S1 ,0), the analysis module determines that it is not compatible with

[0060] (52.1) prompting an upgrade of (S1 , 0) to version 1 as well. Thus, to upgrade to

[0061] (53.1), both S2 and S1 must be upgraded to (S2,1) and (S1 ,1 ) respectively, forming the new subchain (S1 ,1) -(S2,1) -> (S3,1).

[0062] After reaching (S1 ,0) the analysis module backtracks to the next main branch (Figure 6C), which in this example includes (S4,0), (S5 0), and (S6,0). There are only two main branches in this example, but some scenarios could include more branches. Starting with (S4,0), the analysis module 140 determines that (S4,0) is compatible with (S3,1) so that (S4,0) does not need to be upgraded. There is no need to explore nodes dependent from (S4,0) so the search is complete.

[0063] In this example, the analysis of all branches in the propagation graph (Figure 6A) indicate that upgrading S3 to version 1 necessitates upgrades to S2 and S1 to version 1 as well.

[0064] In Step 5, the planning module 150 determines the required number of instances for each microservice being upgraded. In the given example, microservices (S3,0), (S2,0), and (S1 ,0) are being upgraded to (S3,1), (S2,1), and

[0065] (51.1) respectively. (S4,0), (S5,0), and (S6,0) do not require upgrading.

[0066] The planning module determines the required number of new microservices instances based on a count of the current users being serviced and a maximum capacity of the upgraded microservices being deployed. The "Current Users" attribute reflects the existing user load on each microservice instance. Referring to Figure 2, instances (S1 ,0) and (S2,0) serve 100 users each. User distribution among instances may vary based on factors like load balancing. The "Max Capacity" attribute represents the maximum users each microservice instance can handle. When a new version is released, the developer provides relevant information, including the Max Capacity. For instance, in the example given, (S3,1) can handle a maximum of 35 users per instance. To upgrade from (S3,0) to (S3, 1 ), analyzing the user load of 100 users for (S3,0) and considering Max Capacity, it is determined that three instances of microservice (S3,1) are needed to accommodate the existing demand effectively.

[0067] In step 6, the planning module 150 receives the number of new instances from the analysis module 140 and determines a migration plan for moving users from the microservice instances being retired to the new microservices instances. A gradual approach is adopted for deploying instances of the new version, ensuring stepwise integration into the service chain. The rationale for this phased creation is to validate the functionality of the new version before migrating all users gradually from the old version instances to the new version instances. This gradual migration process mitigates potential disruptions and ensures a smooth transition for all users.

[0068] In Step 7, the new microservice instances are integrated into the service chain and the users are migrated gradually according to the migration plan. The placement allocator 160 determines the substrate nodes to host the new microservice instances. This element monitors the current substrate network to gather information about the available capacity of the current network and potential candidate substrate nodes to deploy the new instances onto. The placement allocator 160 also coordinates the integration of the new microservices into the service chain and the migration of users to the new microservice instances. After determining new instances for each migration and their placement, integration into the existing service chain according to the migration plan occurs. The chain's transformation from (S1 ,0) -> (S2,0) -> (S3,0) -> (S4,0) -> (S5,0) to (S1 ,1 ) -> (S2,1) - > (S3, 1 ) -> (S4,0) -> (S5,0) requires consideration of both old and new version instances, with updates to the Deployment Graph (refer to Fig. 5A, B).

[0069] Figures 7A - 7E illustrate the phased approach assuming that 10% of the total users from the old version will be initially migrated to the new version, which means moving 10 users out of 100 current users. The greedy deployment mechanism for creating instances aims to create as few new instances as possible. The underlying idea for the greedy deployment mechanism is to utilize existing instances, filling them first before creating new ones. Because the Max Capacity of

[0070] (53.1) is 35, only one instance is needed for each of (S3,1), (S2,1 ), and (S1 ,1 ) for the initial migration. Figure 7A shows the creation of one instance for each of (S3, 1 ),

[0071] (52.1), and (S1 ,1).

[0072] After the creation of the new instances for each migration, integration into the existing chain occurs. The chain's transformation from (S1 ,0) -> (S2,0) -> (S3,0) -> (S4,0) -> (S5,0), (S6,0) to (S1 ,1) -> (S2,1) -> (S3,1) -> (S4,0) -> (S5,0), (S6,0) requires consideration of both old and new version instances, with updates to the deployment graph. Figure 7B shows the integration of the new instances into the service chain.

[0073] After integrating the new version instances, user migration from old to new versions begins. Singular instances like (S1 ,0) and (S2,0) straightforwardly transfer 10 users, while for (S3,0) with two instances, a random selection approach can be used to select ten users for migration. Alternatively, the selection process may consider other factors such as load on the microservice instances, performance of the microservice instances, and user priority. Figure 7C shows the service chain after the migration of ten users from (S3i,0) to (S3i , 1 ). Forty users remain on (S3i,0).

[0074] Once it is determined that the new service chain is operating without disruption, the migration of users can continue. In the next phase of migration, 50% of the users will be migrated from the old versions of the microservices to the new versions, which in this example is 50 users. This second migration requires the creation of additional microservice instances for each of (S3,1 ), (S2,1 ), and (S1 ,1 ). After the creation of (S3i ,1 ), (S2i ,1 ), and (S11 ,1 ), fifty users are migrated from each of (S1 ,0) and (S2,0) to (S11, 1 ) to (S2i ,1 ) respectively. Twenty-five users are migrated from (S3i ,0) to (S3i ,1 ) followed by 15 users from (S3i,0) to (S32,1 ), and 10 users from (S32,0) to (S32,1 ). Alternatively, 50 users could be migrated from (S32,0) to (S32,1 ). Either approach leaves one instance of the old version empty, which can be removed. To maximize the utilization of current instance and follow the greedy approach, it is desirable to fill newly created microservice instances to full capacity before creating new instances, and to empty old microservice instances before drawings users from other microservice instances. The state of the service chain after the second migration is shown in Figure 7D. It should be noted that (S3i ,0) is now empty and could be removed early before the migration is completed.

[0075] In the final round migration, the remaining 40 users served by (S32, 0), (S2,0), and (S1 ,0) are migrated. Utilizing a resource-efficient strategy, available space in existing instances are filled first before creating new instances one to accommodate the remaining users. With only one active instance for (S3,0), the final migration is straightforward. Once all necessary instances are created and integrated into the service chain, the remaining users are migrated to the new versions. Figure 7E shows the service chain after the final round of migration.

[0076] After the final round of migration is complete, the old version instances can be shut down and removed from the service chain. The final service chain after removal of the old version instances is shown in Figure 7F.

[0077] An important consideration during deployment and migration process is placement strategy to determine the “best” placement of the newly created microservices instances within the substrate network having a plurality of substrate nodes. A node in the substrate network may comprise Kubernetes pod, a virtual machine, or bare metal. The object is to determine the “best” node to host the new microservice instances according to some criteria. One such criteria is distance, but other criteria can be used. This task is performed by the placement allocator 160.

[0078] The placement allocator 160 in the service automation system 100, operates in the deployment strategy as follows. First, it identifies the substrate node hosting the old version microservices that is already deployed and checks its availability based on the new version instance's computational needs (e.g., CPU, memory, and storage) and the candidate substrate node’s available resources. If the current location has enough capacity and supports the new version, the deployment occurs there. If the candidate substrate node lacks sufficient capacity, the placement allocator 160 searches for other nodes reachable from the current location based on distance. The placement allocator 160 begins with a list of candidate nodes and starts with the candidate nodes that have the shortest distance from the current node. For each candidate, the placement allocator 160 checks whether sufficient resources are available and whether the node supports the new version. An important condition is that the selected candidate substrate node should have a path to the successor node of the old version instance to maintain the service chain and ensure proper routing between the old version and new version.

[0079] Figures 8A and 8B illustrate one example of a placement strategy. Figure 8A shows the original service chain deployed in a substrate network with 8 nodes. In this example, nodes 7 and 8 are not currently being used. Each substrate node has attributes indicative of the central processing unit (CPU) memory, and storage. These attributes are also considered for the microservices, reflecting their computational needs.

[0080] In this example, a new instance of the S3 microservice, denoted as (S3, 1 ), is being deployed while randomly selecting instances to upgrade, such as (S3i,0).

[0081] Assume that the new instance (S3, 1 ) requires 2 CPU units for deployment. Referring to Figure 8A, if the existing instance (S3i,0) is located on node n3, then n3 becomes the initial candidate. The placement allocator 160 checks whether there is sufficient CPU capacity on node n3 for deploying (S3i ,1 ). If n3 lacks the necessary resources, The placement allocator 160 explore all reachable nodes from n3, which include n4, n7, and n8. These three nodes have the same distance from n3, making them equal candidates. In this situation, The placement allocator 160 randomly selects n4 first, but n4 does not support the microservice type S3. The placement allocator 160 then considers the other two nodes, n7 and n8. The placement allocator 160 randomly choose n7, which is not a feasible candidate because there is no path from n7 to the successor instance of (S3i,0) in the service chain which is (S4,0). Thus, The placement allocator 160 selects the remaining node, n8, which has a route to (S4,0). After confirming that n8 has sufficient capacity and can support S3, The placement allocator 160 deploys (S3i,1) onto n8, as illustrated in Fig. 8B.

[0082] The automation framework herein described enables automated migration process with diverse objectives. The automation framework allows for the customization of diverse migration objectives, including factors like cost, resource use, and energy efficiency. Specific milestones can be set during the migration process. By including these milestones, the service automation system 100 smartly plans migration steps, optimizes new instance allocation, and schedules user migration to meet objectives and spend time at each milestone. This unique capability ensures a goal-oriented migration experience, offering flexibility and control in the migration process.

[0083] The automation framework adheres to the separation of concerns (SoC) principle. Developers are primarily focused on ensuring compatibility, understanding how microservices can interact with each other independently of deployment or runtime context (in our works represents as version compatibility graph). On the other hand, operations teams are concerned with changes, understanding constraints, and managing runtime contexts (in our works relates to deployment and propagation graph). In this dynamic, the automation framework acts as a bridge between these two aspects / concerns, facilitating collaboration and process. Developers can focus on ensuring compatibility between different microservices and versions, irrespective of deployment or runtime context, while operations teams can determine the target for upgrading, and manage the runtime environment. The automation framework can interact independently with these two concerns and integrate them, providing a comprehensive solution that ensures both compatibility and operational efficiency during upgrades.

[0084] The services automation system 100 easily handles overlapping upgrades at different rollout stages. The proposed automation framework has the capability to manage overlapping upgrades, allowing for the simultaneous deployment of different versions at various rollout stages. One result is that, during a transition period, where multiple versions of the microservice coexist, the services automation system 100 ensures a smooth and stable transition, minimizing disruptions and maintaining operational efficiency.

[0085] The services automation system 100 also allows stepwise migration. In practical scenarios, there may arise a need to upgrade microservices while actively serving a group of users. When implementing the new version into the system, migrating users from the existing instances of the old version to the new ones becomes imperative. The services automation system 100 addresses this migration scenario thoughtfully. Initially, the services automation system 100 migrates a trial subset of current users to the new version instances. After validating the proper response of these new instances, we proceed to migrate the remaining users. It is crucial to note that our solution not only generates essential new version instances but also intricately re-architects the service chain to establish robust links and connections for supporting user migrations. With this solid foundation, we ensure a stepwise transition, moving users effortlessly from the old instances to the newly created ones, all the while maintaining uninterrupted service for the old versions' users. The services automation system 100 makes efficient use of compute, memory and storage resources. Conventional approaches to microservices upgrading suffer from inefficiencies, as they often map every old version instance to a new instance of the updated version, irrespective of the actual users load on the older instances. This practice leads to the creation of redundant new version instances, some of which remain underutilized, resulting in a wasteful consumption of resources such as CPU, memory, and data storage. The services automation system 100 herein described focuses on updating instances to the new version dynamically, aligning with the current user load. Unlike traditional methods, we avoid the unnecessary mapping of each old version instance to a new version instance. This approach ensures that we only create new instances as needed, preventing the generation of excess, unused instances and contributing to a more resource-efficient system.

[0086] The services automation system 100 enhances reliability of the service chain during upgrading. Current approaches to updating and evolving plans may encounter reliability challenges, particularly when creating and embedding new version instances. Resource and capacity limitations on substrate nodes can lead to failures in the process. Unlike existing solutions that generate one new version instance for each old version instance, regardless of actual requirements, the services automation system 100 as herein described takes a more efficient approach. By avoiding unnecessary instantiation and utilization of substrate node resources, we significantly reduce the likelihood of failures during upgrades caused by resource constraints. This strategic resource management ensures a more reliable and successful transition during system upgrades.

[0087] Figure 9 illustrates a method 200 implemented by the services automation system 100 when a new version of a microservice is released. The services automation system 100 computes or otherwise obtains a deployment graph representing a plurality of deployed microservices in service chain and interconnections between the deployed microservices (block 210). The services automation system 100 generates, based on the deployment graph, a propagation graph representing dependencies between a target microservice deployed in the service chain to be replaced and the other deployed microservices in the service chain (block 220). The services automation system 100 updates a version compatibility graph to include a new version of the target microservice, wherein the updated version compatibility graph indicates compatibility between the new version of the target microservice and other deployed microservices in the service chain (block 230). The services automation system 100 identifies, based on the propagation graph and the updated version compatibility graph, one of more affected microservices in the service chain impacted by the new version of the target microservices (block 240). The services automation system 100 deploys the new version of the target microservice and a new version of each affected microservice in the service chain (block 250).

[0088] In some embodiments of method 200, the target microservice comprises a root node in the propagation graph.

[0089] Some embodiments of method 200 further comprise computing a number of new target microservice instances to be deployed based on a current load of existing target microservice instances and a capacity of the new target microservice instances.

[0090] In some embodiments of method 200, deploying the new version of the target microservice comprises deploying the computed number of new target microservice instances in one or more compute nodes and migrating users from the existing target microservice instances to the new target microservice instances.

[0091] In some embodiments of method 200, migrating users from the existing target microservice to the new target microservice instances comprises migrating a first subset of users from one or more existing target microservice instances to one or more new target microservice instances, wherein the subset comprises less than all of the current users of the service chain.

[0092] In some embodiments of method 200, migrating users from the existing target microservice instances to the new target microservice instances comprises, after an initial migration of the first subset of users, continuing migration of one or more additional subsets of users from the existing target microservice instances to the new target microservice instances.

[0093] Some embodiments of method 200 further comprise, after the initial migration, releasing one or more instances of the previous version of the target microservice before migration of all users is complete and continuing migration of users from the previous version of the target microservice to the new version of the target following the release of one or more instances of the previous version of the target microservice.

[0094] In some embodiments of method 200, deploying the new version of the target microservice comprises identifying one or more compute nodes to host new target microservice instances and deploying the new target microservice instances on the identified compute nodes.

[0095] Some embodiments of method 200 further comprise computing a number of affected microservice instances based on a current load of the affected microservice(s) and a capacity of the affected microservice(s) instances, deploying the computed number of affected microservice instances in one or more compute nodes, and migrating users from one or more previous affected microservice instances to the new affected microservice instances.

[0096] An apparatus can perform any of the methods herein described by implementing any functional means, modules, units, or circuitry. In one embodiment, for example, the apparatuses comprise respective circuits or circuitry configured to perform the steps shown in the method figures. The circuits or circuitry in this regard may comprise circuits dedicated to performing certain functional processing and / or one or more microprocessors in conjunction with memory. For instance, the circuitry may include one or more microprocessor or microcontrollers, as well as other digital hardware, which may include Digital Signal Processors (DSPs), special-purpose digital logic, and the like. The processing circuitry may be configured to execute program code stored in memory, which may include one or several types of memory such as read-only memory (ROM), random-access memory, cache memory, flash memory devices, optical storage devices, etc. Program code stored in memory may include program instructions for executing one or more telecommunications and / or data communications protocols as well as instructions for carrying out one or more of the techniques described herein, in several embodiments. In embodiments that employ memory, the memory stores program code that, when executed by one or more processors, carries out the techniques described herein.

[0097] Figure 10 illustrates an exemplary service automation system 300 configured for operation in a wireless communication network. The service automation system 300 generally comprises communication circuitry 310, processing circuitry 320, and memory 330.

[0098] Communication circuitry 310 comprises network interface circuitry for communication with other elements in the communication network. The network interface circuitry may comprise any wired or wireless interface for coupling the network node to a communication network, such as an Ethernet interface, optical interface (e.g., SONET), or wireless interface (e.g. Wireless Fidelity (WiFi).

[0099] The processing circuitry 320 controls the overall operation of the service automation system 300 according to program instructions stored in memory 330. The processing circuitry 320 may comprise one or more microprocessors, hardware, firmware, or a combination thereof. The processing circuitry 320 in one embodiment is configured to perform the methods herein described. Figure 4 illustrates logical components of one services automation system implemented by the processing circuitry 320. Memory 330 comprises both volatile and non-volatile memory for storing computer program code and data needed by the processing circuitry 320 for operation. Memory 330 may comprise any tangible, non-transitory computer- readable storage medium for storing data including electronic, magnetic, optical, electromagnetic, or semiconductor data storage. Memory 330 stores a computer program 340 comprising executable instructions that configure the processing circuitry 320 to implement the perform the methods herein described. A computer program 340 in this regard may comprise one or more code modules corresponding to the means or units described above. In general, computer program instructions and configuration information are stored in a non-volatile memory, such as a ROM, erasable programmable read only memory (EPROM) or flash memory. Temporary data generated during operation may be stored in a volatile memory, such as a random access memory (RAM). In some embodiments, computer program 340 for configuring the processing circuitry 320 as herein described may be stored in a removable memory, such as a portable compact disc, portable digital video disc, or other removable media. The computer program 340 may also be embodied in a carrier such as an electronic signal, optical signal, radio signal, or computer readable storage medium.

[0100] Those skilled in the art will also appreciate that embodiments herein further include corresponding computer programs. A computer program comprises instructions which, when executed on at least one processor of an apparatus, cause the apparatus to carry out any of the respective processing described above. A computer program in this regard may comprise one or more code modules corresponding to the means or units described above.

[0101] Embodiments further include a carrier containing such a computer program. This carrier may comprise one of an electronic signal, optical signal, radio signal, or computer readable storage medium. In this regard, embodiments herein also include a computer program product stored on a non-transitory computer readable (storage or recording) medium and comprising instructions that, when executed by a processor of an apparatus, cause the apparatus to perform as described above. Embodiments further include a computer program product comprising program code portions for performing the steps of any of the embodiments herein when the computer program product is executed by a computing device. This computer program product may be stored on a computer readable recording medium.

Claims

CLAIMSWhat is claimed is:1 . A method (200) of service automation implemented by a service orchestration system in a microservices-based communication network, the method (200) comprising computing (210) a deployment graph representing a plurality of deployed microservices in a service chain and interconnections between the deployed microservices; generating (220), based on the deployment graph, a propagation graph representing dependencies between a target microservice deployed in the service chain to be replaced and the other deployed microservices in the service chain; updating (230) a version compatibility graph to include a new version of the target microservice, wherein the updated version compatibility graph indicates compatibility between the new version of the target microservice and other deployed microservices in the service chain; identifying (240), based on the propagation graph and the updated version compatibility graph, one or more affected microservices in the service chain impacted by the new version of the target microservices; and deploying (250) the new version of the target microservice and a new version of each affected microservice in the service chain.

2. The method (200) of claim 1 , wherein the target microservice comprises a root node In the propagation graph.

3. The method (200) of claim 1 or 2, further comprising: computing a number of new target microservice instances to be deployed based on a current load of existing target microservice instances and a capacity of the new target microservice instances.

4. The method (200) of claim 3, wherein deploying the new version of the target microservice comprises: deploying the computed number of new target microservice instances in one or more compute nodes; and migrating users from the existing target microservice instances to the new target microservice instances.

5. The method (200) of claim 4, wherein migrating users from the existing target microservice to the new target microservice instances comprises: migrating a first subset of users from one or more existing target microservice instances to one or more new target microservice instances, wherein the subset comprises less than all of the current users of the service chain.

6. The method (200) of claim 5, wherein migrating users from the existing target microservice instances to the new target microservice instances comprises: after an initial migration of the first subset of users, continuing migration of one or more additional subsets of users from the existing target microservice instances to the new target microservice instances.

7. The method (200) of claim 5 or 6, further comprising: after the initial migration, releasing one or more instances of the previous version of the target microservice before migration of all users is complete; andcontinuing migration of users from the previous version of the target microservice to the new version of the target following the release of one or more instances of the previous version of the target microservice.

8. The method (200) of any one of claims 1 - 7, wherein deploying the new version of the target microservice comprises: identifying one or more compute nodes to host new target microservice instances; and deploying the new target microservice instances on the identified compute nodes.

9. The method (200) of any one of claims 1 - 8, further comprising: computing a number of affected microservice instances based on a current load of the affected microservice(s) and a capacity of the affected microservice(s) instances; deploying the computed number of affected microservice instances in one or more compute nodes; and migrating users from one or more previous affected microservice instances to the new affected microservice instances.

10. A service orchestration system (100, 300) for managing network services, the service orchestration system being configured to: compute a deployment graph representing a plurality of deployed microservices in service chain and interconnections between the deployed microservices; generate, based on the deployment graph, a propagation graph representing dependencies between a target microservice deployed in the servicechain to be replaced and the other deployed microservices in the service chain; update a version compatibility graph to include a new version of the target microservice, wherein the updated version compatibility graph indicates compatibility between the new version of the target microservice and other deployed microservices in the service chain; identify, based on the propagation graph and the updated version compatibility graph, one or more affected microservices in the service chain impacted by the new version of the target microservices; and deploy the new version of the target microservice and a new version of each affected microservice in the service chain.11 . The service automation system (100, 300) of claim 10, further configured to perform the method of any one of claims 2 - 9.

12. A service automation system (100, 300) for managing network services, the service automation system comprising: memory (330) storing executable program instructions for service automation in a communication network; processing circuitry (320) configured by the executable program instructions stored memory to: compute a deployment graph representing a plurality of deployed microservices in a service chain and interconnections between the deployed microservices; generate, based on the deployment graph, a propagation graph representing dependencies between a target microservicedeployed in the service chain to be replaced and the other deployed microservices in the service chain; update a version compatibility graph to include a new version of the target microservice, wherein the updated version compatibility graph indicates compatibility between the new version of the target microservice and other deployed microservices in the service chain; identify, based on the propagation graph and the updated version compatibility graph, one of more affected microservices in the service chain impacted by the new version of the target microservices; and deploy the new version of the target microservice and a new version of each affected microservice in the service chain.

13. The service automation system (100, 300) of claim 12, wherein the processing circuitry is further configured by the executable program instructions stored memory to perform the method of any one of claims 2 - 9.

14. A computer program (340) comprising executable instructions that, when executed by processing circuitry (320) in a service automation system (100, 300) causes it to perform the method of claims 1 - 9.

15. A carrier containing a computer program (340) of claim 14, wherein the carrier is one of an electronic signal, optical signal, radio signal, or computer readable storage medium.

16. A non-transitory computer-readable storage medium (330) containing a computer program (340) comprising executable instructions that, when executed by processing circuitry (320) in a service automation system (100) causes it to perform the method of any one of claims 1 - 9.

Images