Method and system for deploying microservices in a data center network

Abstract

The present disclosure relates to field of data centers that discloses method and system for deploying microservices in a Data Center Network (DCN). The method includes identifying deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request. Further, the method includes determining a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements. Finally, the method includes deploying microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment.

Description

METHOD AND SYSTEM FOR DEPLOYING MICROSERVICES IN A DATA CENTER NETWORK

[0001] The present disclosure relates to field of data centers. Particularly, the present disclosure relates to a method and system for deploying microservices in a Data Center Network (DCN).

[0002] With the exponential growth of ultra-reliable low-latency communications (URLLC), immersive media, autonomous systems, and Industry 4.0 use cases in fifth generation (5G) and future sixth generation (6G) networks, the pressure on cloud and edge infrastructure to deliver services with minimal latency, high reliability, and efficient resource utilization has never been higher. In this context, the optimal placement and dynamic migration of microservices especially those forming part of Service Function Chains (SFCs) is critical for meeting stringent quality of service (QoS) and Service Level Agreement (SLA) constraints such as latency budgets, energy efficiency, and load distribution across data centre networks (DCNs).

[0003] Conventional systems like Kubernetes largely rely on static placement policies, which are not designed to adapt to the temporal and spatial variability of traffic across multi-tier architectures. As a result, these systems often fall short under dynamic conditions, leading to performance degradation, SLA violations, and inefficient infrastructure utilization.

[0004] The information disclosed in this background of the disclosure section is only for enhancement of understanding of the general background of the invention and should not be taken as an acknowledgement or any form of suggestion that this information forms the prior art already known to a person skilled in the art.

[0005] Disclosed herein is a method of deploying microservices in a Data Center Network (DCN). The method includes identifying deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request. Further, the method includes determining a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements. Finally, the method includes deploying microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment.

[0006] Further, disclosed herein is an apparatus for deploying microservices in a Data Center Network (DCN). The apparatus comprises a processor and a memory communicatively coupled to the processor, where the memory stores processor executable instructions, which, on execution, may cause the processor to identify deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request. Further, the processor is configured to determine a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements. Finally, the processor is configured to deploy microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment.

[0007] The foregoing summary is illustrative only and is not intended to be in any way limiting. In addition to the illustrative aspects, embodiments, and features described above, further aspects, embodiments, and features will become apparent by reference to the drawings and the following detailed description.

[0008] The accompanying drawings, which are incorporated in and constitute a part of this disclosure, illustrate exemplary embodiments and, together with the description, explain the disclosed principles. In the figures, the left-most digit(s) of a reference number identifies the figure in which the reference number first appears. The same numbers are used throughout the figures to reference like features and components. Some embodiments of system and / or methods in accordance with embodiments of the present subject matter are now described, by way of example only, and regarding the accompanying figures, in which:

[0009] FIG. 1shows an exemplary environment for deploying microservices in a Data Center Network (DCN), in accordance with some embodiments of the present disclosure;

[0010] FIG. 2shows an exemplary illustration of customized Graph Attention Network (GAT) module, in accordance with some embodiments of the present disclosure;

[0011] FIG. 3shows a detailed block diagram of an apparatus for deploying microservices in a Data Center Network (DCN), in accordance with some embodiments of the present disclosure;

[0012] FIG. 4showsa flowchart illustrating method of deploying microservices in a Data Center Network (DCN), in accordance with some embodiments of the present disclosure; and

[0013] FIG. 5illustrates a block diagram of an exemplary computer system for implementing embodiments consistent with the present disclosure.

[0014] It should be appreciated by those skilled in the art that any block diagrams herein represent conceptual views of illustrative systems embodying the principles of the present subject matter. Similarly, it will be appreciated that any flow charts, flow diagrams, state transition diagrams, pseudo code, and the like represent various processes which may be substantially represented in computer readable medium and executed by a computer or processor, whether such computer or processor is explicitly shown.

[0015] In the present document, the word “exemplary” is used herein to mean “serving as an example, instance, or illustration.” Any embodiment or implementation of the present subject matter described herein as “exemplary” is not necessarily to be construed as preferred or advantageous over other embodiments.

[0016] While the disclosure is susceptible to various modifications and alternative forms, specific embodiment thereof has been shown by way of example in the drawings and will be described in detail below. It should be understood, however that it is not intended to limit the disclosure to the specific forms disclosed, but on the contrary, the disclosure is to cover all modifications, equivalents, and alternative falling within the scope of the disclosure.

[0017] The terms “comprises”, “comprising”, “includes”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device, or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises… a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.

[0018] The following description with reference to the accompanying drawings is provided to assist in a comprehensive understanding of various embodiments of the disclosure as defined by the claims and their equivalents. It includes various specific details to assist in that understanding but these are to be regarded as merely exemplary. Accordingly, those of ordinary skill in the art will recognize that various changes and modifications of the various embodiments described herein can be made without departing from the scope of the disclosure. In addition, descriptions of well-known functions and constructions may be omitted for clarity and conciseness.

[0019] The terms and words used in the following description and claims are not be limited to the bibliographical meanings, but, are merely used by the inventor to enable a clear and consistent understanding of the disclosure. Accordingly, it should be apparent to those skilled in the art that the following description of various embodiments of the disclosure is provided for illustration purpose only and not for the purpose of limiting the disclosure as defined by the appended claims and their equivalents. .

[0020] It is to be understood that the singular forms “a,” “an,” and “the” include plural referents unless the context clearly dictates otherwise. Thus, for example, reference to “a component surface” includes reference to one or more of such surfaces.

[0021] In various examples of the disclosure described below, a hardware approach will be described as an example. However, since various embodiments of the disclosure may include a technology that utilizes both the hardware-based and the software-based approaches, they are not intended to exclude the software-based approach.

[0022] As used herein, the terms referring to merging (e.g., merging, grouping, combination, aggregation, joint, integration, unifying), the terms referring to signals (e.g., packet, message, signal, information, signaling), the terms referring to resources (e.g. section, symbol, slot, subframe, radio frame, subcarrier, resource element (RE), resource block (RB), bandwidth part (BWP), opportunity), the terms used to refer to any operation state (e.g., step, operation, procedure), the terms referring to data (e.g. packet, message, user stream, information, bit, symbol, codeword), the terms referring to a channel, the terms referring to a network entity (e.g., distributed unit (DU), radio unit (RU), central unit (CU), control plane (CU-CP), user plane (CU-UP), O-DU -open radio access network (O-RAN) DU), O-RU (O-RAN RU), O-CU (O-RAN CU), O-CU-UP (O-RAN CU-CP), O-CU-CP (O-RAN CU-CP)), the terms referring to the components of an apparatus or device, or the like are only illustrated for convenience of description in the disclosure. Therefore, the disclosure is not limited to those terms described below, and other terms having the same or equivalent technical meaning may be used therefor. Further, as used herein, the terms, such as ‘~ module’, ‘~ unit’, ‘~ part’, ‘~ body’, or the like may refer to at least one shape of structure or a unit for processing a certain function.

[0023] Further, throughout the disclosure, an expression, such as e.g., ‘above’ or ‘below’ may be used to determine whether a specific condition is satisfied or fulfilled, but it is merely of a description for expressing an example and is not intended to exclude the meaning of ‘more than or equal to’ or ‘less than or equal to’. A condition described as ‘more than or equal to’ may be replaced with an expression, such as ‘above’, a condition described as ‘less than or equal to’ may be replaced with an expression, such as ‘below’, and a condition described as ‘more than or equal to and below’ may be replaced with ‘above and less than or equal to’, respectively. Furthermore, hereinafter, ‘A’ to ‘B’ means at least one of the elements from A (including A) to B (including B). Hereinafter, ‘C’ and / or ‘D’ means including at least one of ‘C’ or ‘D’, that is, {'C', 'D', or 'C' and 'D'}.

[0024] The disclosure describes various embodiments using terms used in some communication standards (e.g., 3rd Generation Partnership Project (3GPP), extensible radio access network (xRAN), open-radio access network (O-RAN) or the like), but it is only of an example for explanation, and the various embodiments of the disclosure may be easily modified even in other communication systems and applied thereto.

[0025] In the following detailed description of the embodiments of the disclosure, reference is made to the accompanying drawings that form a part hereof, and in which are shown by way of illustration specific embodiments in which the disclosure may be practiced. These embodiments are described in sufficient detail to enable those skilled in the art to practice the disclosure, and it is to be understood that other embodiments may be utilized and that changes may be made without departing from the scope of the present disclosure. The following description is, therefore, not to be taken in a limiting sense.

[0026] As discussed in background section, existing data centers do not support multiple radio handling. To introduce this capability in base stations, several critical issues need to be addressed. Firstly, each type of application has its own unique set of constraints, so when selecting the optimal path for deploying these constraints, it is important to consider this constraint set. Secondly, the current approach only considers network-level constraints and does not account for node-level constraints when determining the optimal path. Thirdly, as the number of microservices increases when handling multiple applications in a data center, the existing method involves manual creation of configurations and deployment of microservices.

[0027] To overcome the above limitations, the present disclosure proposes a Constraint-Aware Pipeline (CAP) which is a cloud-native orchestration framework designed for intelligent, QoS-aware microservice placement in modern data center networks (DCNs), with particular relevance for 5G / 6G network slicing and service function chaining (SFC). At its core, the CAP combines Graph Attention Networks (GAT) and Deep Reinforcement Learning (DRL) to make optimal placement decisions while satisfying stringent SLA constraints such as latency, packet error rate (PER), and peak resource utilization. The GAT encodes real-time topology and node state into embeddings, which are then consumed by the DRL agent to sequentially select nodes for microservice placement in a way that balances local and end-to-end constraints. To further enhance automation, the framework integrates a Large Language Model (LLM) for generating deployment configurations such as Kubernetes manifests, ensuring operator-specific syntax and resource logic are applied. Additionally, a SARIMA-based time-series model forecasts traffic loads and proactively informs placement and scaling decisions. CAP interacts seamlessly with the Kubernetes API for deployment execution and leverages live telemetry from nodes and proxies to continuously adapt to dynamic traffic and resource conditions. The modular architecture is designed to support real-time, AI-driven orchestration across multi-RAT cloud environments, enabling scalable and SLA-compliant service deployment.

[0028] FIG. 1shows an exemplary environment for deploying microservices in a Data Center Network (DCN), in accordance with some embodiments of the present disclosure.

[0029] Exemplary environment100illustrates a hierarchical data center network architecture based on a Core-Spine-Leaf topology. The architecture includes an orchestrator101and a control node configured to manage containerized workloads across a plurality of worker nodes (Node 1 to Node 6). As an example, the control node may be Kubernetes control node. Each worker node hosts one or more applications (as shown in figure, App1, App2, App3, App4) and is connected to leaf switches (L1-L6). The plurality of worker nodes may include physical or virtual computing resources such as servers, virtual machines, or containerized environments that execute workloads. The one or more applications hosted on these nodes can range from microservices, AI / ML models, and web services to enterprise software components deployed in containers or virtualized platforms. The leaf layer functions as the access layer, providing connectivity to compute resources and may comprise Top-of-Rack (ToR) switches. As an examples, the Top-of-Rack (ToR) switches may include, without limitation. The leaf switches interface with the spine layer (S1-S3), which ensures high-speed, non-blocking interconnections between leaves and may include high-performance Layer 3 switches. The spine layer further connects to the core layer (C1), which provides north-south traffic routing and external network connectivity, and may consist of high-capacity modular switches or routers. Additionally, the architecture incorporates Software Defined Networking (SDN) and an Artificial Intelligence / Machine Learning (AI / ML) engine for dynamic traffic optimization. The exemplary environment100may be deployed in large-scale cloud or edge data centers to support containerized workloads. In an embodiment, the orchestrator101may be configured to perform the embodiments of the present disclosure. In some embodiments, components shown in exemplary environment100may be also used to perform the embodiments of the present disclosure with the orchestrator101.

[0030] In an embodiment, the orchestrator101may be configured to identify deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request. The SFC deployment request may include, without limitation, SFC structure, traffic type, and resource requirements. Further, to identify deployment-specific information the orchestrator101may parse the attributes from the SFC deployment request. In an embodiment, the orchestrator101may extract deployment-specific details such as traffic type, the number and type of microservices to be deployed, traffic distribution percentages, and node-level resource requirements. Further, the orchestrator101may parse Quality of Service (QoS) constraints from the request, including latency parameters such as Packet Delay Budget (PDB), reliability metrics such as Packet Error Rate (PER), and other SLA attributes, which may be derived from QoS Flow Identifier (QFI) mappings. These extracted and parsed attributes enable the orchestrator101to determine optimal deployment strategies that meet the defined SFC structure and SLA requirements.

[0031] In an embodiment, upon identifying the deployment information and the associated SLA requirements, the orchestrator101may be configured to determine a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements. The current state of the DCN and the placement strategy of microservices may be determined using a Constraint-Aware Pipeline (CAP). The CAP may include, without limitation, a Graph Attention Network (GAT) and a Deep Reinforcement Learning (DRL) agent. The GAT may be configured to encode real-time network topology and state of the DCN into node embeddings. An exemplary GAT is shown in FIG. 2. Further, the DRL agent may be configured to select nodes and paths for microservice placement based on the node embeddings and service-level constraints. In an embodiment, the DRL agent may be trained prior to utilizing the DRL agent for selecting the nodes and the paths for microservice placement. In an embodiment, to train the DRL agent, the orchestrator101may simulate one or more placement strategies of microservices. Further, the orchestrator101may update the one or more placement strategies of microservices based on rewards derived based on compliance of the one or more placement strategies of microservices with service-level constraints. The one or more updated placement strategies of microservices are configured to minimize loss and improve placement efficiency. In an embodiment, the CAP may determine the placement strategy based on evaluating latency, reliability, and resource capacity constraints derived from SLA parameters. Further, the CAP may perform adaptive reconfiguration of the microservices based on predicted traffic variations and resource utilization trends. This helps in enabling optimized microservice placement and ensures resilience and performance under dynamic traffic and resource conditions.

[0032] In an embodiment, upon determining the current state of the DCN and the placement strategy, the orchestrator101may be configured to deploy microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment. The configuration files may be derived from the placement strategy using Large Language Models (LLMs). The LLM may utilize policy templates, historical deployment data, and vendor-specific syntax rules to derive the configuration files. In an embodiment, the orchestrator101may label nodes with SFC identifiers for traceability and lifecycle management. The orchestration environment may include a Kubernetes-based system, and applying / executing the configuration files may include invoking Kubernetes Application Program Interface (APIs) to deploy microservices. In an embodiment, the orchestrator101may be configured to forecast the traffic patterns in the DCN using a Seasonal Autoregressive Integrated Moving Average (SARIMA) model. Further, the orchestrator101may be configured to dynamically adjust the deployment configuration files based on the forecasted traffic. The CAP is a core component of the SDN ecosystem, which is designed to enhance the deployment and lifecycle management of Network Functions (NFs). By integrating the CAP with orchestration layer, the framework ensures optimal microservice placement and dynamic path selection based on SLA constraints, leading to faster 5G control plane (CP) setup and improved service reliability. Further, Virtual Radio Access Network (vRAN) deployments require efficient handling of Stream Control Transmission Protocol (SCTP) associations between the Central Unit (CU) and Distributed Unit (DU). The CAP’s ability to forecast traffic using the SARIMA and adjust configurations in real time ensures reduced end-to-end latency and minimal service disruption. The SLA-driven orchestration that improves network efficiency, enhances reliability, and reduces operational costs, making it a key differentiator in the 5G and edge computing.

[0033] FIG. 2shows an exemplary illustration of customized Graph Attention Network (GAT) module, in accordance with some embodiments of the present disclosure.

[0034] In an embodiment, the customized Graph Attention Network (GAT) module is designed to encode the real-time state of the Data Center Network (DCN) into high-dimensional node embeddings that capture both topology and resource conditions under QoS and SLA constraints. Each node represents a compute element such as a Kubernetes worker node, with features including Central Processing Unit (CPU), memory, Graphics Processing Unit (GPU) utilization, and policy labels, while edges represent physical or logical links annotated with latency, jitter, Packet Error Rate (PER), and bandwidth metrics. The GAT employs multi-head attention with edge-aware mechanisms to prioritize neighbors and paths that satisfy stringent latency and reliability requirements. SLA parameters such as Packet Delay Budget (PDB) and PER thresholds are incorporated as conditioning vectors during attention computation, enabling dynamic re-weighting of neighborhoods per service intent. The architecture consists of stacked attention layers with residual connections, producing 256-dimensional embeddings per node, which are consumed by the Deep Reinforcement Learning (DRL) agent for constraint-aware microservice placement. This approach ensures that embeddings are context-sensitive, reflecting real-time traffic patterns and resource availability, thereby improving placement decisions compared to static or heuristic-based methods. The embeddings are refreshed periodically or upon SLA changes, and the module integrates seamlessly with the CAP to support adaptive orchestration across multi-generation networks.

[0035] FIG. 3shows a detailed block diagram of the orchestrator101for deploying microservices in a Data Center Network (DCN), in accordance with some embodiments of the present disclosure.

[0036] In some implementations, the orchestrator101may include an I / O interface301, a processor303and a memory305. In an embodiment, the memory305may be communicatively coupled to the processor303. The processor303may be configured to perform one or more functions of the orchestrator101for deploying microservices in a Data Center Network (DCN), using the data307and the one or more modules309of the orchestrator101. In an embodiment, the memory305maystore the data307. In some embodiments, the memory305may also store, context aware pipeline311. The context aware pipeline311may include a Graph Attention Network (GAN) and a Deep Reinforcement Learning (DRL) agent (not shown in figure).

[0037] In an embodiment, the data307stored in the memory305may include, without limitation, deployment information313,SLA requirements315and other data317. In some implementations, the data307may be stored within the memory305in the form of various data structures. Additionally, the data307may be organized using data models, such as relational or hierarchical data models. The other data317may include various temporary data and files generated by the one or more modules309.

[0038] In an embodiment, the deployment information313may include attributes extracted from the service deployment request. The service deployment request describes the environment and service characteristics of hierarchical data center network architecture. The attributes may include radio access type, number and type of microservices in the Service Function Chain (SFC), expected traffic distribution ratios, and per-node resource demands such as CPU, memory, and GPU requirements. The attributes may also covers topology details and link properties relevant for placement decisions.

[0039] In an embodiment, the SLA requirements315may define the performance and reliability constraints that must be satisfied during deployment. The SLA requirements315may include Packet Delay Budget (PDB) for latency limits, Packet Error Rate (PER) thresholds, reliability targets, and service isolation constraints. QoS parameters derived from QFI / QCI tables are also part of SLA requirements, ensuring that latency, reliability, and error rates meet the agreed standards for each application type. In an embodiment, these inputs enable the Constraint-Aware Pipeline (CAP) to make intelligent, SLA-compliant placement decisions for microservices across multi-generation networks.

[0040] In an embodiment, the data307may be processed by one or more modules309of the orchestrator101. In some implementations, the one or more modules309may be communicatively coupled to the processor303for performing one or more functions of the orchestrator101. In an implementation, the one or more modules309may include, without limiting to, an identification module319, a determination module321, a deploying module323and other modules325.

[0041] As used herein, the term module may refer to an Application Specific Integrated Circuit (ASIC), an electronic circuit, a hardware processor303(shared, dedicated, or group) and memory that execute one or more software or firmware programs, a combinational logic circuit, and / or other suitable components that provide the described functionality. In an implementation, each of the one or more modules309may be configured as stand-alone hardware computing units. In an embodiment, the other modules325may be used to perform various miscellaneous functionalities on the orchestrator101. It will be appreciated that such one or more modules309may be represented as a single module or a combination of different modules.

[0042] In an embodiment, the identification module319may be configured to identify deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request. The SFC deployment request may include SFC structure, traffic type, and resource requirements, and identifying deployment-specific information comprises parsing these attributes from the request.

[0043] In an embodiment, the determination module321may be configured to determine a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements. The determination module321may determine the current state of the DCN and the placement strategy of microservices using a Constraint-Aware Pipeline (CAP). The CAP may include, without limitation, a Graph Attention Network (GAT) and a Deep Reinforcement Learning (DRL) agent. The GAN may be configured to encode real-time network topology and state of the DCN into node embeddings. Further, the DRL agent may be configured to select nodes and paths for microservice placement based on the node embeddings and service-level constraints. In an embodiment, the DRL agent may be trained prior to utilizing the DRL agent for selecting the nodes and the paths for microservice placement. In an embodiment, to train the DRL agent, the determination module321may simulate one or more placement strategies of microservices. Further, the determination module321may update the one or more placement strategies of microservices based on rewards derived based on compliance of the one or more placement strategies of microservices with service-level constraints. The one or more updated placement strategies of microservices are configured to minimize loss and improve placement efficiency.

[0044] The training process of the DRL agent begins by initializing the policy network and value network with random weights. The policy network is a neural model that takes the environment state including node embeddings, Service Function Chain (SFC) context, current microservice index, QoS constraints, and placement history, and outputs a continuous action vector in the same embedding space. The DRL agent architecture consists of an input layer for the flattened state vector, two fully connected hidden layers with multiple neurons each using ReLU activation to capture complex spatial and temporal patterns, and an output layer that produces the action vector corresponding to microservice placement. To ensure robustness, multiple scenarios are simulated by generating diverse SFC requests and traffic patterns that reflect realistic operating conditions. Each training episode represents the placement of all microservices in a single SFC. At every timestep, the agent observes the current state, selects an action via the policy network, maps it to the closest node embedding, performs placement, computes the delayed reward, and stores the transition. These stored transitions are then used to update the policy network by minimizing the PPO clipped loss function. If the cumulative reward exceeds a defined success threshold for the episode, it is marked as successful; otherwise, if the episode times out or underperforms, it is marked as failed. This iterative training across many episodes allows the policy to continuously improve by interacting with a dynamic, constraint-aware environment.

[0045] In an embodiment, the deploying module323may be configured to deploy microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment. In an embodiment, the deploying module323may derive the configuration files from the placement strategy using Large Language Models (LLMs). The LLM may utilize policy templates, historical deployment data, and vendor-specific syntax rules. The orchestration environment may include a Kubernetes-based system, and applying / executing the configuration files may invoke Kubernetes Application Program Interface (APIs) to deploy microservices. The deploying module323may be further configured to forecast traffic patterns in the DCN using a Seasonal Autoregressive Integrated Moving Average (SARIMA) model. Thereafter, the deploying module323may dynamically adjust the deployment configuration files based on the forecasted traffic.

[0046] In an embodiment, the proposed CAP delivers significant advantages for real-time industrial automation over multi-RAT networks. By enforcing strict reliability requirements, CAP ensures service reliability through constraint-aware path selection and node scoring. The CAP maintains end-to-end latency by forecasting traffic and dynamically avoiding congested paths, which is critical for URLLC applications. The integration of a Large Language Model (LLM) enables zero-touch deployment by automating complex multi-network configurations, reducing human error and deployment time. The CAP also supports seamless cross-generation deployment across networks while adhering to stringent QoS constraints. Furthermore, the SARIMA-based forecasting triggers proactive scaling before traffic spikes occur, ensuring uninterrupted service. By prioritizing SLA-sensitive workloads through its cost function, the CAP minimizes SLA violations and associated penalties, delivering a robust, adaptive orchestration framework for mission-critical environments.

[0047] FIG. 4is a flowchart illustrating a method of deploying microservices in a Data Center Network (DCN), in accordance with some embodiments of the present disclosure.

[0048] As illustrated inFIG. 4, the method400may include one or more blocks illustrating a method of deploying microservices in a Data Center Network (DCN), using the orchestrator101illustrated inFIG. 3. The method400may be described in the general context of computer executable instructions. Generally, computer executable instructions can include routines, programs, objects, components, data structures, procedures, modules, and functions, which perform specific functions or implement specific abstract data types.

[0049] The order in which the method400is described is not intended to be construed as a limitation, and any number of the described method blocks can be combined in any order to implement the method. Additionally, individual blocks may be deleted from the methods without departing from the scope of the subject matter described herein. Furthermore, the method can be implemented in any suitable hardware, software, firmware, or combination thereof.

[0050] At block401,the method400includes identifying, by a processor303of the orchestrator101, deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request. The SFC deployment request may include, SFC structure, traffic type, and resource requirements, and identifying deployment-specific information comprises parsing these attributes from the request. The deployment information may include, without limitation, a plurality of attributes extracted from the service deployment request.

[0051] At block403,the method400includes determining, by the processor303, a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements. In an embodiment, the current state of the DCN and the placement strategy of microservices may be determined using a Constraint-Aware Pipeline (CAP). The CAP may include, a Graph Attention Network (GAT) configured to encode real-time network topology and state of the DCN into node embeddings, and a Deep Reinforcement Learning (DRL) agent configured to select nodes and paths for microservice placement based on the node embeddings and service-level constraints. The CAP may determine the placement strategy based on evaluating latency, reliability, and resource capacity constraints derived from SLA parameters. The CAP may perform adaptive reconfiguration of the microservices based on predicted traffic variations and resource utilization trends. In an embodiment, to train the DRL agent the processor may simulate one or more placement strategies of microservices. Further, the processor may update the one or more placement strategies of microservices based on rewards derived based on compliance of the one or more placement strategies of microservices with service-level constraints. The one or more updated placement strategies of microservices are configured to minimize loss and improve placement efficiency.

[0052] At block405,the method400includes deploying, by the processor303, microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment. The configuration files may be derived from the placement strategy using Large Language Models (LLMs). The LLM may utilize policy templates, historical deployment data, and vendor-specific syntax rules. The orchestration environment comprises a Kubernetes-based system, and applying / executing the configuration files may include invoking Kubernetes Application Program Interface (APIs) to deploy microservices. In an embodiment, the processor may forecast traffic patterns in the DCN using a Seasonal Autoregressive Integrated Moving Average (SARIMA) model. Further, the processor may dynamically adjust the deployment configuration files based on the forecasted traffic. The processor may also label nodes with SFC identifiers for traceability and lifecycle management.

[0053] Computer System

[0054] FIG. 5illustrates a block diagram of an exemplary computer system500for implementing embodiments consistent with the present disclosure. In an embodiment, the computer system500may be an orchestrator101illustrated inFIG. 1. The computer system500may include a central processing unit (“CPU” or “processor” or “memory controller”)502. The processor502may comprise at least one data processor for executing program components for executing user- or system-generated business processes. A user may include a network manager, an application developer, a programmer, an organization, or any system / sub-system being operated parallelly to the computer system500. The processor502may include specialized processing units such as integrated system (bus) controllers, memory controllers / memory management control units, floating point units, graphics processing units, digital signal processing units, etc.

[0055] The processor502may be disposed in communication with one or more Input / Output (I / O) devices (511and512) via I / O interface501. The I / O interface501may employ communication protocols / methods such as, without limitation, audio, analog, digital, stereo, IEEE®-1394, serial bus, Universal Serial Bus (USB), infrared, PS / 2, BNC, coaxial, component, composite, Digital Visual Interface (DVI), high-definition multimedia interface (HDMI), Radio Frequency (RF) antennas, S-Video, Video Graphics Array (VGA), IEEE® 502.n / b / g / n / x, Bluetooth, cellular (e.g., Code-Division Multiple Access (CDMA), High-Speed Packet Access (HSPA+), Global System For Mobile Communications (GSM), Long-Term Evolution (LTE) or the like), etc. Using the I / O interface501, the computer system500may communicate with one or more I / O devices511and512.

[0056] In some embodiments, the processor502may be disposed in communication with a network509via a network interface503. The network interface503may communicate with the network509. The network interface503may employ connection protocols including, without limitation, direct connect, Ethernet (e.g., twisted pair 10 / 100 / 1000 Base T), Transmission Control Protocol / Internet Protocol (TCP / IP), token ring, IEEE® 502.11a / b / g / n / x, etc.

[0057] In an implementation, the preferred network509may be implemented as one of the several types of networks, such as intranet or Local Area Network (LAN) and such within the organization. The preferred network509may either be a dedicated network or a shared network, which represents an association of several types of networks that use a variety of protocols, for example, Hypertext Transfer Protocol (HTTP), Transmission Control Protocol / Internet Protocol (TCP / IP), Wireless Application Protocol (WAP) etc., to communicate with each other. Further, the network509may include a variety of network devices, including routers, bridges, RAN nodes, computing devices, storage devices, etc. Using the network interface503and the network509, the computer system500may communicate with Software Defined Networking (SDN) and an Artificial Intelligence / Machine Learning (AI / ML) engine.

[0058] In some embodiments, the processor502may be disposed in communication with a memory505(e.g., RAM513, ROM514, etc. as shown inFIG. 5) via a storage interface504. The storage interface504may connect to memory505including, without limitation, memory drives, removable disc drives, etc., employing connection protocols such as Serial Advanced Technology Attachment (SATA), Integrated Drive Electronics (IDE), IEEE-1394, Universal Serial Bus (USB), fiber channel, Small Computer Systems Interface (SCSI), etc. The memory drives may further include a drum, magnetic disc drive, magneto-optical drive, optical drive, Redundant Array of Independent Discs (RAID), solid-state memory devices, solid-state drives, etc.

[0059] The memory505may store a collection of program or database components, including, without limitation, user / application interface506, an operating system507, a web browser508, and the like. In some embodiments, computer system500may store user / application data506, such as the data, variables, records, etc. as described in this invention. Such databases may be implemented as fault-tolerant, relational, scalable, secure databases such as Oracle® or Sybase®.

[0060] The operating system507may facilitate resource management and operation of the computer system500. Examples of operating systems include, without limitation, APPLE® MACINTOSH® OS X®, UNIX®, UNIX-like system distributions (E.G., BERKELEY SOFTWARE DISTRIBUTION® (BSD), FREEBSD®, NETBSD®, OPENBSD, etc.), LINUX® DISTRIBUTIONS (E.G., RED HAT®, UBUNTU®, KUBUNTU®, etc.), IBM® OS / 2®, MICROSOFT®WINDOWS® (XP®, VISTA® / 7 / 8, 10 etc.), APPLE® IOS®, GOOGLETMANDROIDTM, BLACKBERRY® OS, or the like.

[0061] The user interface506may facilitate display, execution, interaction, manipulation, or operation of program components through textual or graphical facilities. For example, the user interface506may provide computer interaction interface elements on a display system operatively connected to the computer system500, such as cursors, icons, check boxes, menus, scrollers, windows, widgets, and the like. Further, Graphical User Interfaces (GUIs) may be employed, including, without limitation, APPLE® MACINTOSH® operating systems’ Aqua®, IBM® OS / 2®, MICROSOFT® WINDOWS® (e.g., Aero, Metro, etc.), web interface libraries (e.g., ActiveX®, JAVA®, JAVASCRIPT®, AJAX, HTML, ADOBE® FLASH®, etc.), or the like.

[0062] The web browser508may be a hypertext viewing application. Secure web browsing may be provided using Secure Hypertext Transport Protocol (HTTPS), Secure Sockets Layer (SSL), Transport Layer Security (TLS), and the like. The web browsers508may utilize facilities such as AJAX, DHTML, ADOBE® FLASH®, JAVASCRIPT®, JAVA ®, Application Programming Interfaces (APIs), and the like. Further, the computer system500may implement a mail RAN node stored program component. The mail RAN node may utilize facilities such as ASP, ACTIVEX®, ANSI® C++ / C#, MICROSOFT®, .NET, CGI SCRIPTS, JAVA®, JAVASCRIPT®, PERL®, PHP, PYTHON®, WEBOBJECTS®, etc. The mail RAN node may utilize communication protocols such as Internet Message Access Protocol (IMAP), Messaging Application Programming Interface (MAPI), MICROSOFT® exchange, Post Office Protocol (POP), Simple Mail Transfer Protocol (SMTP), or the like. In some embodiments, the computer system500may implement a mail client stored program component. The mail client may be a mail viewing application, such as APPLE® MAIL, MICROSOFT® ENTOURAGE®, MICROSOFT® OUTLOOK®, MOZILLA® THUNDERBIRD®, and the like.

[0063] Furthermore, one or more computer-readable storage media may be utilized in implementing embodiments consistent with the present invention. A computer-readable storage medium refers to any type of physical memory on which information or data readable by a processor may be stored. Thus, a computer-readable storage medium may store instructions for execution by one or more processors, including instructions for causing the processor(s) to perform steps or stages consistent with the embodiments described herein. The term “computer-readable medium” should be understood to include tangible items and exclude carrier waves and transient signals, i.e., non-transitory. Examples include Random Access Memory (RAM), Read-Only Memory (ROM), volatile memory, nonvolatile memory, hard drives, Compact Disc (CD) ROMs, Digital Video Disc (DVDs), flash drives, disks, and any other known physical storage media.

[0064] In light of the technical advancements provided by the disclosed method, the claimed steps, as discussed above, are not routine, conventional, or not well-known aspects in the art, as the claimed steps provide the aforesaid solutions to the technical problems existing in the conventional technologies. Further, the claimed steps clearly bring an improvement in the functioning of the system itself, as the claimed steps provide a technical solution to a technical problem.

[0065] The terms "an embodiment", "embodiment", "embodiments", "the embodiment", "the embodiments", "one or more embodiments", "some embodiments", and "one embodiment" mean "one or more (but not all) embodiments of the invention(s)" unless expressly specified otherwise.

[0066] The terms "including", "comprising", “having” and variations thereof mean "including but not limited to", unless expressly specified otherwise.

[0067] The enumerated listing of items does not imply that any or all the items are mutually exclusive, unless expressly specified otherwise. The terms "a", "an" and "the" mean "one or more", unless expressly specified otherwise.

[0068] According to embodiments in the disclosure, a method of deploying microservices in a Data Center Network (DCN) is provided. The method comprises identifying deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request, determining a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements, and deploying microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment.

[0069] For example, the current state of the DCN and the placement strategy of microservices are determined using a Constraint-Aware Pipeline (CAP), wherein the CAP comprises a Graph Attention Network (GAN) configured to encode real-time network topology and state of the DCN into node embeddings, and a Deep Reinforcement Learning (DRL) agent configured to select nodes and paths for microservice placement based on the node embeddings and service-level constraints.

[0070] For example, training the DRL agent comprises simulating one or more placement strategies of microservices, and updating the one or more placement strategies of microservices based on rewards derived based on compliance of the one or more placement strategies of microservices with service-level constraints. The one or more updated placement strategies of microservices are configured to minimize loss and improve placement efficiency.

[0071] For example, the configuration files are derived from the placement strategy using Large Language Models (LLMs), wherein the LLM utilizes policy templates, historical deployment data, and vendor-specific syntax rules.

[0072] For example, the method comprises forecasting traffic patterns in the DCN using a Seasonal Autoregressive Integrated Moving Average (SARIMA) model, and dynamically adjusting the deployment configuration files based on the forecasted traffic.

[0073] For example, the orchestration environment comprises a Kubernetes-based system, and applying / executing the configuration files comprises invoking Kubernetes Application Program Interface (APIs) to deploy microservices.

[0074] For example, the SFC deployment request comprises SFC structure, traffic type, and resource requirements, and identifying deployment-specific information comprises parsing these attributes from the request.

[0075] For example, the CAP determines the placement strategy based on evaluating latency, reliability, and resource capacity constraints derived from SLA parameters.

[0076] For example, the CAP performs adaptive reconfiguration of the microservices based on predicted traffic variations and resource utilization trends.

[0077] For example, applying the configuration files further comprises labeling nodes with SFC identifiers for traceability and lifecycle management.

[0078] For example, the deployment information comprises a plurality of attributes extracted from the service deployment request.

[0079] According to embodiments in the disclosure, an apparatus for deploying microservices in a Data Center Network (DCN) is provided. The apparatus comprises at least one processor comprising processing circuitry, and memory comprising one or more storage media storing instructions. The instructions, when executed by the at least one processor individually or collectively, cause the apparatus to identify deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request, determine a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements, and deploy microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment.

[0080] For example, the current state of the DCN and the placement strategy of microservices are determined using a Constraint-Aware Pipeline (CAP), wherein the CAP comprises a Graph Attention Network (GAN) configured to encode real-time network topology and state of the DCN into node embeddings, and a Deep Reinforcement Learning (DRL) agent configured to select nodes and paths for microservice placement based on the node embeddings and service-level constraints.

[0081] For example, to train the DRL agent, the instructions, when executed by the at least one processor individually or collectively, cause the apparatus to simulate one or more placement strategies of microservices, and update the one or more placement strategies of microservices based on rewards derived based on compliance of the one or more placement strategies of microservices with service-level constraints. The one or more updated placement strategies of microservices are configured to minimize loss and improve placement efficiency.

[0082] For example, the configuration files are derived from the placement strategy using Large Language Models (LLMs), wherein the LLM utilizes policy templates, historical deployment data, and vendor-specific syntax rules.

[0083] For example, the instructions, when executed by the at least one processor individually or collectively, cause the apparatus to forecast traffic patterns in the DCN using a Seasonal Autoregressive Integrated Moving Average (SARIMA) model, and dynamically adjust the deployment configuration files based on the forecasted traffic.

[0084] For example, the orchestration environment comprises a Kubernetes-based system, and applying / executing the configuration files comprises invoking Kubernetes Application Program Interface (APIs) to deploy microservices.

[0085] For example, the SFC deployment request comprises SFC structure, traffic type, and resource requirements, and identifying deployment-specific information comprises parsing these attributes from the request.

[0086] For example, the CAP determines the placement strategy based on evaluating latency, reliability, and resource capacity constraints derived from SLA parameters.

[0087] For example, the CAP performs adaptive reconfiguration of the microservices based on predicted traffic variations and resource utilization trends.

[0088] For example, applying the configuration files further comprises labeling nodes with SFC identifiers for traceability and lifecycle management.

[0089] For example, the deployment information comprises a plurality of attributes extracted from the service deployment request.

[0090] A description of an embodiment with several components in communication with each other does not imply that all such components are required. On the contrary, a variety of optional components are described to illustrate the wide variety of possible embodiments of the invention.

[0091] When a single device or article is described herein, it will be clear that more than one device / article (whether they cooperate) may be used in place of a single device / article. Similarly, where more than one device / article is described herein (whether they cooperate), it will be clear that a single device / article may be used in place of the more than one device / article or a different number of devices / articles may be used instead of the shown number of devices or programs. The functionality and / or features of a device may be alternatively embodied by one or more other devices which are not explicitly described as having such functionality / features. Thus, other embodiments of invention need not include the device itself.

[0092] For one or more embodiments, at least one of the components set forth in one or more of the preceding figures may be configured to perform one or more operations, techniques, processes, and / or methods as set forth herein. For example, a processor (e.g., baseband processor) as described herein in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein. For another example, circuitry associated with a UE, base station, network element, etc. as described above in connection with one or more of the preceding figures may be configured to operate in accordance with one or more of the examples set forth herein.

[0093] Any of the above described embodiments may be combined with any other embodiment (or combination of embodiments), unless explicitly stated otherwise. The foregoing description of one or more implementations provides illustration and description, but is not intended to be exhaustive or to limit the scope of embodiments to the precise form disclosed. Modifications and variations are possible in light of the above teachings or may be acquired from practice of various embodiments.

[0094] The methods according to various embodiments described in the claims and / or the specification of the disclosure may be implemented in hardware, software, or a combination of hardware and software.

[0095] When implemented by software, a computer-readable storage medium storing one or more programs (software modules) may be provided. One or more programs stored in such a computer-readable storage medium (e.g., non-transitory storage medium) are configured for execution by one or more processors in an electronic device. The one or more programs include instructions that cause the electronic device to execute the methods according to embodiments described in the claims or specification of the disclosure.

[0096] Such a program (e.g., software module, software) may be stored in a random-access memory, a non-volatile memory including a flash memory, a read only memory (ROM), an electrically erasable programmable read only memory (EEPROM), a magnetic disc storage device, a compact disc-ROM (CD-ROM), digital versatile discs (DVDs), other types of optical storage devices, or magnetic cassettes. Alternatively, it may be stored in a memory configured with a combination of some or all of the above. In addition, respective constituent memories may be provided in a multiple number.

[0097] Further, the program may be stored in an attachable storage device that can be accessed via a communication network, such as e.g., Internet, Intranet, local area network (LAN), wide area network (WAN), or storage area network (SAN), or a communication network configured with a combination thereof. Such a storage device may access an apparatus performing an embodiment of the disclosure through an external port. Further, a separate storage device on the communication network may be accessed to an apparatus performing an embodiment of the disclosure.

[0098] In the above-described specific embodiments of the disclosure, a component included therein may be expressed in a singular or plural form according to a proposed specific embodiment. However, such a singular or plural expression may be selected appropriately for the presented context for the convenience of description, and the disclosure is not limited to the singular form or the plural elements. Therefore, either an element expressed in the plural form may be formed of a singular element, or an element expressed in the singular form may be formed of plural elements.

[0099] Meanwhile, specific embodiments have been described in the detailed description of the disclosure, but it goes without saying that various modifications are possible without departing from the scope of the disclosure.

[0100] Finally, the language used in the specification has been principally selected for readability and instructional purposes, and it may not have been selected to delineate or circumscribe the inventive subject matter. It is therefore intended that the scope of the invention be limited not by this detailed description, but rather by any claims that issue on an application based here on. Accordingly, the embodiments of the present invention are intended to be illustrative, but not limiting, of the scope of the invention, which is set forth in the following claims.

[0101] While various aspects and embodiments have been disclosed herein, other aspects and embodiments will be apparent to those skilled in the art. The various aspects and embodiments disclosed herein are for purposes of illustration and are not intended to be limiting, with the true scope and spirit being indicated by the following claims.

[0102] Referral Numerals:

[0103]

Claims

1.A method of deploying microservices in a Data Center Network (DCN), the method comprising:identifying deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request;determining a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements; anddeploying microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment.2.The method of claim 1, wherein the current state of the DCN and the placement strategy of microservices are determined using a Constraint-Aware Pipeline (CAP), wherein the CAP comprises:a Graph Attention Network (GAN) configured to encode real-time network topology and state of the DCN into node embeddings, anda Deep Reinforcement Learning (DRL) agent configured to select nodes and paths for microservice placement based on the node embeddings and service-level constraints.3.The method of claim 2, wherein training the DRL agent comprises:simulating one or more placement strategies of microservices; andupdating the one or more placement strategies of microservices based on rewards derived based on compliance of the one or more placement strategies of microservices with service-level constraints, wherein the one or more updated placement strategies of microservices are configured to minimize loss and improve placement efficiency.4.The method of claim 1, wherein the configuration files are derived from the placement strategy using a Large Language Models (LLM), wherein the LLM utilizes policy templates, historical deployment data, and vendor-specific syntax rules.5.The method of claim 1, comprises:forecasting traffic patterns in the DCN using a Seasonal Autoregressive Integrated Moving Average (SARIMA) model; anddynamically adjusting the deployment configuration files based on the forecasted traffic.6.The method of claim 1, wherein the orchestration environment comprises a Kubernetes-based system, and applying / executing the configuration files comprises invoking Kubernetes Application Program Interface (APIs) to deploy microservices.7.The method of claim 1, wherein the SFC deployment request comprises SFC structure, traffic type, and resource requirements, and identifying deployment-specific information comprises parsing these attributes from the request.8.The method of claim 1, wherein the CAP determines the placement strategy based on evaluating latency, reliability, and resource capacity constraints derived from SLA parameters.9.The method of claim 1, wherein the CAP performs adaptive reconfiguration of the microservices based on predicted traffic variations and resource utilization trends.10.The method of claim 1, wherein applying the configuration files further comprises labeling nodes with SFC identifiers for traceability and lifecycle management.11.The method of claim 1, wherein the deployment information comprises a plurality of attributes extracted from the service deployment request.12.An apparatus for deploying microservices in a Data Center Network (DCN), the apparatus comprising:at least one processor comprising processing circuitry; andmemory comprising one or more storage media storing instructions that, when executed by the at least one processor individually or collectively, cause the apparatus to:identify deployment information and associated Service-Level Agreement (SLA) requirements based on a Service Function Chain (SFC) deployment request;determine a current state of the DCN and a placement strategy of microservices based on the deployment information and associated SLA requirements; anddeploy microservices based on execution of configuration files generated using the placement strategy of microservices, in an orchestration environment.13.The apparatus of claim 12, wherein the current state of the DCN and the placement strategy of microservices are determined using a Constraint-Aware Pipeline (CAP), wherein the CAP comprises:a Graph Attention Network (GAN) configured to encode real-time network topology and state of the DCN into node embeddings, anda Deep Reinforcement Learning (DRL) agent configured to select nodes and paths for microservice placement based on the node embeddings and service-level constraints.14.The apparatus of claim 13, wherein to train the DRL agent, the instructions, when executed by the at least one processor individually or collectively, cause the apparatus to:simulate one or more placement strategies of microservices; andupdate the one or more placement strategies of microservices based on rewards derived based on compliance of the one or more placement strategies of microservices with service-level constraints, wherein the one or more updated placement strategies of microservices are configured to minimize loss and improve placement efficiency.15.The apparatus of claim 12, wherein the configuration files are derived from the placement strategy using a Large Language Model (LLM), wherein the LLM utilizes policy templates, historical deployment data, and vendor-specific syntax rules.

Images