Apparatus, method, and computer readable medium for configuring plurality of microservices in networked system

Abstract

An apparatus, method, and computer-readable medium for configuring micro-services in a networked system. The method comprises: monitoring one or more metrics of the networked system; determining a topology of the networked system based on the one or more metrics; and configuring the plurality of microservices based on the topology.

Description

Background Technology

[0001] In the evolution of software architecture, developers have widely shifted from monolithic architectures (applications built as single, unified units) to microservices. Microservices focus on specific functionalities, provide simple APIs, and allow individual services to evolve independently. Compared to traditional monolithic architectures, this shift offers benefits and advantages in scalability, clear ownership, and ease of maintenance. However, this shift is not without challenges. Large companies have reported significant difficulties managing extensive networks of microservices. Increased complexity, high communication overhead, duplicated resources, and security vulnerabilities have prompted these organizations to reconsider microservices as their sole architectural choice. In some cases, companies have even reverted to monolithic architectures and seen significant resource reductions, particularly in terms of network latency.

[0002] Given that microservices and monolithic architectures are beneficial for certain applications and situations, improved apparatuses, methods, and computer-readable media that can manage the trade-offs and benefits of these two architectures may be desirable. Attached Figure Description

[0003] Examples of apparatuses and / or methods will be described below by way of example only and with reference to the accompanying drawings, in which:

[0004] Figure 1 A flowchart is shown for a method of configuring multiple microservices in a networked system;

[0005] Figure 2 A simplified flowchart is shown for an example implementation of configuring multiple microservices in a networked system;

[0006] Figure 3 Showing the target Figure 2 The example application's model usage flow;

[0007] Figure 4 A flowchart illustrating the training process for a machine learning model is shown.

[0008] Figure 5 A block diagram illustrating an example of a device (or apparatus) for configuring multiple microservices in a networked system; and

[0009] Figure 6 The diagram illustrates a computing device used to configure multiple microservices in a networked system. Detailed Implementation

[0010] Some examples will now be described in more detail with reference to the accompanying drawings. However, other possible examples are not limited to the features of these embodiments described in detail. Other examples may include modifications to the features, as well as equivalents and alternatives to the features. Furthermore, the terminology used herein to describe certain examples should not limit other possible examples.

[0011] Throughout the description of the accompanying drawings, the same or similar reference numerals refer to the same or similar elements and / or features, which may be identical or implemented in modified form while providing the same or similar function. For clarity, the thickness of lines, layers, and / or areas in the drawings may also be enlarged.

[0012] Accordingly, while further examples can have various modifications and alternative forms, some specific examples are shown in the accompanying drawings and will be described in detail thereafter. However, this detailed description does not limit the further examples to the specific forms described. Further examples may cover all modifications, equivalents, and alternatives falling within the scope of this disclosure. Throughout the description of the accompanying drawings, the same numbers refer to the same or similar elements that may be implemented identically or in modified form while providing the same or similar functionality.

[0013] When two elements A and B are combined using "or", it should be understood that this discloses all possible combinations: A only, B only, and A and B, unless otherwise explicitly defined in individual cases. As alternative wording for the same combination, "at least one of A and B" or "A and / or B" can be used. This is equivalent to combinations of more than two elements.

[0014] If singular forms such as “a / an” and “the” are used and the use of only a single element is neither explicitly nor implicitly mandatory, further examples may also use several elements to achieve the same functionality. If the functionality is described below as being implemented using multiple elements, further examples may use a single element or a single processing entity to achieve the same functionality. Further understanding is that when the terms “include,” “including,” “comprise,” and / or “comprising” are used, the presence of the features, integers, steps, operations, processes, elements, components, and / or groups thereof specified in the description is included, but the presence or addition of one or more other features, integers, steps, operations, processes, elements, components, and / or groups thereof is not excluded.

[0015] Unless otherwise specified, all terms (including technical and scientific terms) are used herein in the general sense of the field to which the examples belong.

[0016] Specific details are set forth in the following description, but examples of how the techniques described herein can be implemented without these specific details are provided. Well-known circuits, structures, and techniques are not shown in detail to avoid obscuring the understanding of this specification. Terms such as "an example," "various examples," "some examples," etc., may include features, structures, or characteristics, but not every example necessarily includes these specific features, structures, or characteristics.

[0017] Some examples may have some or all of the features described for other examples, or none of them. "First," "second," "third," etc., describe common elements and indicate different instances of similar elements being referenced. Such adjectives do not imply that the described element items must be in a given order, either temporally or spatially, or in any other way. "Connected" may indicate that elements are in direct physical or electrical contact with each other, and "coupled" may indicate that elements cooperate or interact with each other, but these elements may or may not be in direct physical or electrical contact.

[0018] As used herein, the terms “operation,” “execution,” or “running” are used interchangeably when referring to software or firmware in relation to a system, device, platform, or resource, and may refer to software or firmware stored in one or more computer-readable storage media accessible by the system, device, platform, or resource, even if the instructions contained in the software or firmware are not being actively executed by the system, device, platform, or resource.

[0019] The specification may use the phrases “in an example,” “in various examples,” “in some examples,” and / or “in various examples,” each of which may refer to one or more examples of the same or different examples. Furthermore, the terms “comprising,” “including,” “having,” etc., as used with respect to examples of this disclosure are synonymous.

[0020] It should be noted that the example schemes disclosed herein are applicable to / applied with any operating system, and references to specific operating systems in this disclosure are merely examples and not limitations.

[0021] Figure 1A flowchart of a method 100 for configuring multiple microservices in a networked system is shown. The method may include: monitoring (110) one or more metrics of the networked system; determining (120) the topology of the networked system based on the one or more metrics; and configuring (130) multiple microservices based on the topology.

[0022] For decades, monolithic architecture has been the default choice for companies developing production systems. Applications created as monolithic are built as unified units. This typically includes the user interface, business logic, and data access layers, all within the same application. More recently, microservices architecture has been introduced, and many companies have moved to this approach. Applications built using microservices are constructed as collections of small, independent services that communicate with each other through well-defined interfaces such as APIs. Each microservice focuses on a specific business capability and can be developed, deployed, and scaled independently of other microservices.

[0023] Compared to monolithic architectures, microservices offer benefits in terms of scalability, flexibility, deployment time, maintenance, and other factors. However, the microservices approach also has drawbacks in terms of network latency and communication overhead, increased resource requirements, and security concerns. Therefore, dynamic systems capable of adaptively switching between microservices and monolithic deployments based on real-time system monitoring and quality of service requirements have advantages.

[0024] The choice between microservices and monolithic architecture depends on a variety of factors, including the size and scope of the project, the organizational capacity to manage complex distributed systems, and specific performance and scalability requirements. For startups and smaller applications, starting with a monolithic architecture and then breaking it down into microservices as needed may be a pragmatic approach. For larger, more complex applications with clear requirements for scalability and resilience, adopting a microservices architecture from the outset may be beneficial.

[0025] A networked system can be an interconnected collection of computing devices, servers, nodes, or systems communicating over a network. The arrangement of this system, known as the network topology, describes how multiple microservices, hardware resources, communication links, and other system components are organized and interconnected. The topology defines the structural layout and deployment of microservices within the system, determining how they are executed (e.g., as plugins or standalone services), how they communicate with each other (e.g., via in-process communication or network requests), and how they interact with shared infrastructure resources. By optimizing performance, scalability, and resource utilization within a networked system, modifying the topology can help achieve desired operational goals.

[0026] Microservices can be multiple independent modules, components, software, or functional units designed to perform specific tasks within an application or networked system. Each microservice can focus on a specific business capability and can be developed, deployed, and scaled independently of other microservices. Examples of microservices include user interface components, payment processing modules, authentication services, inventory management systems, and notification handlers.

[0027] Microservices can scale independently, allowing more resources to be allocated to the components that need them most without scaling the entire application. Different microservices can use different programming languages, databases, or other tools, allowing for the use of the best tools for each specific task. Due to their smaller size and independence, microservices can be developed, tested, and deployed much faster than monolithic applications. This can accelerate the time to market for new features. If a microservice fails, it doesn't necessarily destroy the entire system. This siloed failure mode can improve the overall resilience of the application. Compared to large, complex monolithic codebases, smaller, well-defined microservices are easier for developers to understand and easier for teams to maintain. Microservices may be well-suited for continuous integration and continuous delivery (CI / CD) processes, making it easier to automate testing and deployment.

[0028] Microservices offer many benefits compared to monolithic applications; however, in certain software scenarios, especially where infrastructure costs are a concern, monolithic architectures are not an issue. Some disadvantages of using microservices include network latency, communication overhead, increased resource requirements, and security concerns.

[0029] Communication between services on a network introduces latency. Optimizing this communication to avoid significant performance degradation requires careful design and implementation. Ensuring data consistency across services and managing distributed data can be challenging, especially in systems requiring strong transactional integrity. Running multiple services, each potentially with its own stack and dependencies, can lead to increased infrastructure costs compared to a monolithic architecture. Monitoring, logging, and troubleshooting distributed systems can require more sophisticated tools and expertise from development and operations teams. Furthermore, each microservice exposes its own set of endpoints, potentially increasing the attack surface for malicious activity. Implementing consistent security policies across diverse services and technology stacks can be challenging.

[0030] The embodiments in this document disclose a mechanism for configuring multiple microservices in a networked system, which can manage trade-offs between two models depending on application type, available infrastructure / topology, and resource utilization. Depending on where services are deployed, their resource utilization, and quality of service requirements, a collection of microservices can operate independently (i.e., forming a regular microservice mesh), work together as monolithic architectures, or operate as a hybrid model. The system can adapt based on context. Different types of triggers (such as network overload, performance-related issues, or other issues that the system can learn over time) allow the system to autonomously adapt or deform by identifying the correct components for grouping based on quality of service (QoS) requirements. To this end, the system uses mechanisms that provide alternatives for communication between components (e.g., gRPC / REST, direct function calls, shared memory, etc.), which are fully abstracted to simplify development.

[0031] The embodiments in this paper focus on reducing network traffic to make the system more efficient, while improving performance (e.g., eliminating wait time for calls to other components). Furthermore, on the security side, when components are aggregated into monolithic structures, they can reduce the attack surface by making man-in-the-middle attacks impossible. This is especially important at the edge, where resources are more limited.

[0032] In the context of networked systems, particularly cloud computing, the "edge" refers to distributed computing resources and infrastructure located near the data generation source or end user. Edge computing brings computing and data storage closer to devices, sensors, or users, reducing latency, saving bandwidth, and enabling real-time processing and analysis. Processing data at the edge of the network, rather than in centralized data centers, enhances the performance of applications requiring instantaneous responses, such as Internet of Things (IoT) devices, autonomous vehicles, and real-time analytics.

[0033] Sometimes, the disclosed embodiments can orchestrate changes from an edge orchestrator, which can be on-premises or in the cloud. The edge orchestrator can be a central authority, as in a GitOPs continuous delivery type infrastructure. Once edge nodes are replicated from the edge orchestrator, the edge nodes can act as a cluster to distribute workloads across one or more edge nodes. Embodiments within this disclosure can operate the edge orchestrator across edge nodes for infrastructure control and / or application clustering. This leverages the advantages of microservices architecture and monolithic architecture while minimizing their disadvantages. The system can result in reduced latency and communication overhead, and can be highly adaptive in its use of resources for efficiency.

[0034] One or more metrics may include network traffic metrics and / or quality of service metrics. Network traffic metrics can be measurements related to data flow within the network, such as bandwidth usage, packet loss, latency, or throughput. Quality of service metrics can indicate the quality of network performance, including availability, error rate, jitter, or response time. The monitoring and analytics module can continuously track system metrics (such as events, errors, component latency, and overall system behavior) to assess performance and identify potential problems.

[0035] In some embodiments, each of a plurality of microservices can be configured to selectively operate as a plugin and / or an independent service. Microservices can be designed to either function as an integrated component (plugin) within a host application or independently over a network. A plugin is a software module that can be loaded into a host application to extend its functionality without requiring separate deployment. A host application is a software environment or service wrapper that can load plugins and manage their execution within its process space. An independent service is a microservice that operates independently and communicates with other services over a network using standard protocols. Operating microservices as plugins or independent services allows the system to optimize performance and resource usage by dynamically selecting the most appropriate operating mode for each microservice.

[0036] Configuring multiple microservices can involve executing two or more microservices as plugins. Running multiple microservices embedded within the host application or a service wrapper allows for tighter integration and potentially improved performance. A service wrapper is an intermediate software layer (e.g., a hosted application, framework, or container) that encapsulates microservices, providing a unified interface and managing the execution of microservices as plugins within the host application's process space. This configuration enhances performance by enabling direct method calls and shared memory access, resulting in faster data exchange and lower latency.

[0037] In some embodiments, plugins communicate with each other via intra-process communication (IPC). IPC refers to the exchange of data between software components within the same operating system process using mechanisms similar to shared memory or internal messaging systems. Compared to inter-process communication or network communication, IPC minimizes wait time and resource consumption.

[0038] In some embodiments, each microservice implements a service interface that can be invoked by a service wrapper. A service interface is a defined set of methods and protocols that a management application or framework can use to invoke or interact with a microservice, regardless of its deployment mode. Configuring (130) multiple microservices may include: loading (132) a first microservice as a first plugin into the service wrapper when the first microservice selectively operates as a plugin; and / or invoking (134) the first microservice via a network request from the service wrapper when the first microservice selectively operates as a standalone service. A consistent service interface allows the service wrapper to interact seamlessly with microservices, whether the microservice operates as a plugin or a standalone service. This uniformity simplifies integration and promotes flexibility in deployment strategies, thereby enhancing maintainability and scalability.

[0039] In some embodiments, method 100 further includes: receiving (140) a request for a first microservice from a client device; and routing the request to a service wrapper. A client device can refer to any computing device or system that initiates a request for a service provided by the microservice, such as a user device, server, or other application. Routing client requests via a service wrapper centralizes control and management of microservice interactions and enhances security by providing a single entry point.

[0040] In some embodiments, monitoring (110) one or more metrics of the networked system may further include monitoring (112) multiple shared hardware infrastructure resources. These may be physical computing resources, such as processors, memory, storage devices, and network interfaces used by multiple microservices or applications within the system. Monitoring shared hardware infrastructure resources ensures efficient utilization of hardware, prevents bottlenecks, and maintains system performance under varying loads.

[0041] In some embodiments, determining the topology of the (120) networked system can be based on a machine learning model trained on historical data to predict the future state of the system. A machine learning model is a computational model that uses algorithms and statistical techniques to learn patterns from data and makes predictions or decisions without being explicitly programmed for a specific task. This allows the system to anticipate future system states and proactively adjust the network topology, thereby enhancing system robustness and minimizing downtime.

[0042] In some embodiments, method 100 further includes: obtaining (150) one or more feedback metrics based on the topology of the configuration of the multiple microservices; and adding one or more feedback metrics as further historical data for retraining the machine learning model. Feedback metrics are collected data on the performance and effectiveness of the current microservice configuration, such as response time, error rate, or resource utilization. By utilizing new data to retrain the model, the system can adapt to changing conditions and improve its decisions over time.

[0043] In some embodiments, determining (120) the topology may include: identifying or selecting a subset of multiple microservices for use as plug-in operations. Identifying specific microservices for use as plug-in operations, and grouping specific microservices for use as plug-in operations, can optimize inter-service communication and resource usage. This selective aggregation enhances the performance of tightly coupled services and contributes to a more efficient system architecture.

[0044] The decision to group these microservices into subsets of plug-in operations (e.g., within the same service wrapper) can be based on monitored metrics indicating high frequency of inter-service communication and low allowable latency. For example, a monitoring and analytics module might collect data revealing that these services exchange information extensively and require fast response times to maintain a seamless user experience. Some examples of microservices that can be grouped include user authentication, session management, and user profile services. When managing user-related functions within the system, these are often tightly coupled due to their frequent interactions and shared data dependencies.

[0045] In some embodiments, a group of microservices across multiple microservices can be configured to form a microservice bundle. Each microservice within a microservice bundle is configured to operate together via a port or socket. A microservice bundle is a collection of microservices bundled together to function as a cohesive unit, thereby facilitating simplified deployment and management. Ports and sockets are communication endpoints used for inter-process communication, allowing data exchange between microservices within the bundle. Forming microservice bundles allows for streamlined deployment and enhanced communication efficiency between grouped services. Utilizing ports or sockets for communication within a bundle reduces latency and simplifies network configuration.

[0046] In some embodiments, when a subset of multiple microservices is determined to operate as a plugin, that subset can be stopped or paused as an independent service. By stopping, pausing, or maintaining instances of independent microservices when microservices are configured to operate as plugins, the system prevents redundant execution and conserves computational resources. This also allows services to quickly resume independent operation when a new topology is determined. This dynamic management of microservices as plugins and independent services reduces overhead and improves system efficiency.

[0047] In some embodiments, each microservice can be assigned a priority, and the microservices are configured to modify their execution based on their priority according to system policies. Modifying the execution of a microservice may include pausing the microservice or adjusting quality metrics. A subset of multiple microservices supports pausing and / or QoS adjustment, and this subset is prioritized based on one or more policies. One or more policies may be set by past machine learning or artificial intelligence (AI) monitoring of one or more hardware resources and / or by human network administrators. Different levels of priority can be assigned to microservices within the system. This prioritization determines how resources are allocated to each microservice, especially when there is contention for limited hardware resources. The system may temporarily suspend lower-priority microservices to free up resources for higher-priority microservices. QoS mechanisms ensure that higher-priority microservices receive the necessary resources to meet performance requirements such as bandwidth, latency, and computing power.

[0048] The system can use AI to monitor hardware resource utilization over time, and based on this monitoring, the AI ​​can generate strategies to optimize resource allocation by predicting bottlenecks and adjusting priorities accordingly. For example, suppose AI monitoring detects that the GPU is overloaded due to multiple competing microservices. In that case, the system can pause less critical microservices or adjust their QoS to free up resources. In applications with 5G microservices, low latency and high throughput can be critical. Dynamic prioritization of these microservices can help maintain service quality and ensure that resource constraints do not hinder the most important services for 5G payloads.

[0049] Similarly, human administrators can manually set policies based on organizational priorities, service-level agreements (SLAs), or other considerations. This allows for human oversight and intervention during the prioritization process. Furthermore, adjusting microservice operations based on AI insights and human policies allows the system to scale effectively as needs change.

[0050] In some embodiments, each of a plurality of microservices can be configured to process fifth-generation (5G) payload data. Microservices can be targeted at 5G applications, meaning they can be designed to handle actual data and control traffic or payloads generated by the 5G system, rather than focusing on managing or maintaining the infrastructure of the underlying system or cluster. In other words, microservices can be responsible for processing, analyzing, or managing network traffic and data associated with 5G applications. This can include handling user data, processing AI inference results, and managing control signals within the 5G network. In this scenario, microservices may not primarily concern themselves with operational aspects of the cluster itself, such as resource allocation, hardware configuration, or system maintenance. Infrastructure tasks may include monitoring hardware performance, managing CPU / GPU resources, or tuning system settings to optimize performance. By focusing on payloads, microservices can optimize 5G network performance, improve data handling, and enhance user experience without being burdened by infrastructure overhead. Separating payload processing from infrastructure management allows for more scalable and flexible deployment of microservices, which is particularly important in dynamic 5G environments.

[0051] In some embodiments, method 100 may set thresholds (114) for one or more metrics based on the determined topology and continuously monitor one or more metrics of the networked system. Further topologies of the networked system may be determined, and multiple microservices may be reconfigured based on this further topology when a threshold is met. A threshold is a predefined value or set of values ​​for a specific metric that triggers actions such as network topology reconfiguration when exceeded. Setting thresholds allows the system to respond quickly to significant changes in performance or load.

[0052] In some embodiments, monitoring (110) of one or more metrics can be performed continuously, and topology determination and configuration of multiple microservices can be based on continuous monitoring. Continuous monitoring allows the system to detect and respond to fluctuations in real time, thereby ensuring that the configuration of microservices remains aligned with current operational requirements.

[0053] A non-transitory computer-readable medium may include program code for configuring multiple microservices in a networked system, which, when executed on a processor, computer, or programmable hardware component, causes the processor, computer, or programmable hardware component to perform method 100.

[0054] Figure 1 Further details and optional aspects can be found in the following text (e.g., Figures 2 to 6 The example described is used for illustration.

[0055] Figure 2A simplified flowchart 200 illustrates an example implementation of configuring multiple microservices in a networked system. The example is implemented using the Python programming language and Flask, a web development framework written in Python. However, nothing in this disclosure should be construed as limiting oneself to a particular language or framework.

[0056] A first application 201 (e.g., Flask application-service 1) utilizing the mechanisms or embodiments disclosed herein can use a plugin manager 230 (e.g., PluginManager) to route requests to one or more service wrappers 240 (e.g., ServiceWrapper). The system can operate a monitoring module 210 (e.g., MonitoringModule) to monitor network traffic and QoS. Based on this, a topology manager 220 (e.g., TopologyManager) is notified by a signal. Upon receiving the signal from the monitoring module 210, the topology manager 220 reconfigures the first application 201 and instructs the plugin manager 230 regarding the new topology of the system. The plugin manager 230 receives instructions from the topology manager 220 and loads one or more service wrappers 240 according to the new topology. The first application 201 then reroutes requests to the appropriate service wrapper 240, which then invokes microservices 242, 244 that act as plugins, or remotely invokes microservice 246.

[0057] Service wrapper 240 is an interface for service operations. Microservices 242, 244, and 246 (e.g., service A, service B, and a remote service) implement service wrapper 240. When microservices 242 and 246 are implemented as plugins (e.g., service A and service B), they can directly call each other. Microservices 242 and 246 operating as plugins can also call instances of independent microservices 246. Similarly, independent microservices 246 can call other independent microservices. Furthermore, all microservices 242, 244, and 246 can make network calls to a second application 202 (e.g., another Flask application – service 2). The second application 202 can be a separate Flask application or web service that exposes API endpoints for interaction.

[0058] The embodiments described herein disclose an autonomous system that can dynamically adapt between microservice architectures, monolithic architectures, or hybrid models based on network traffic and QoS. To this end, services that require close interaction can be dynamically loaded as plugins within the same process. This reduces network traffic between these services, as they can now communicate directly within the process. The system can still maintain a microservice architecture when services are independent and do not require frequent communication. Each microservice can also be refactored to function as a plugin. This means it can be dynamically loaded into a host service, allowing it to run in the same process space and communicate directly with other plugins without network overhead. A plugin manager is introduced to handle the dynamic loading and unloading of these service plugins. Depending on current needs, the plugin manager can load a single service as a microservice or load multiple services together as a thicker service. Several new components are required to monitor the system and make decisions, such as reconfiguring services based on context.

[0059] The first application 201 can serve as the entry point for all client requests. It interacts with the appropriate service wrapper 240 using the plugin manager 230, regardless of whether the service wrapper 240 is local or remote. The first application 201 receives incoming client requests. Based on the current configuration, it uses the plugin manager 230 to route each request to the appropriate service wrapper. The service wrapper 240 processes the request and returns a response. If the wrapper is a local instance, it handles the request directly. If it is a remote proxy, it makes an HTTP call to the external microservice. The first application 201 then sends the response back to the client.

[0060] Monitoring module 210 continuously monitors network traffic and QoS metrics. It determines when to trigger a service reconfiguration (from microservices to monolithic setup, from monolithic setup to microservices, or a hybrid model). One or more metrics can be quantitative measurements or indicators related to system performance, such as throughput, latency, resource utilization, or other operational parameters. Monitoring module 210 continues to monitor the system, ready to trigger further reconfiguration in the event of changing conditions.

[0061] The topology manager 220 can receive signals from the monitoring module and orchestrate the reconfiguration process. It starts and stops services (and also suspends them), and manages their deployment / redeployment based on the current optimal topology. Topology can be the structural arrangement, configuration, or layout of a network system, including how components are interconnected.

[0062] The plugin manager 230 can manage the dynamic loading and unloading of services that act as plugin wrappers. It instantiates services locally or remotely based on the configuration received from the topology manager 220. This can be based on the Python example provided below, or in the case of C++, using dynamic library loading (.so in Linux).

[0063] Each microservice 242, 244, 246 can have a service wrapper 240 that implements a common service interface (ServiceWrapper). The service wrapper 240 can be instantiated directly as a local service within the Flask application, or it can be instantiated as a remote service proxy that makes HTTP requests to the individual microservices.

[0064] Figure 2 Further details and optional aspects can be found in conjunction with the above (e.g., Figure 1 ) or the following text (e.g., Figures 3 to 6 The example described is used for illustration.

[0065] Figure 3 Showing the target Figure 2 The example application uses the model usage flow 300. The system may have a monitoring module, a topology manager, service wrappers, a plugin manager, and applications. The machine learning model 301 can determine how the monitoring module 303 evaluates the system's metrics. When making certain real-time predictions about how the system should operate, the decision engine 303 will trigger the topology manager 304 to send instructions to the plugin manager 305 to reconfigure multiple microservices. Then, based on system performance, the feedback module 206 will collect information about how the reconfigured topology is executed.

[0066] The monitoring (and analytics) module continuously collects data across all microservices regarding network traffic, response time, resource usage, and other relevant metrics. It analyzes this data to determine system performance and identify bottlenecks or inefficiencies. Four key indicators are used: events, saturation, latency, and throughput.

[0067] An event (e.g., an error) describes the number of failed requests. Saturation describes memory usage and central processing unit (CPU) load (e.g., CPU saturation is 100%). Latency (e.g., response time) describes the time required to process a request. Throughput (e.g., traffic) describes the number of requests processed per minute or per second.

[0068] Each of these signals is monitored and can be used to detect and predict infrastructure bottlenecks. This type of telemetry is workload-agnostic. However, it can also be combined with key performance indicators (KPIs) to make predictions to avoid issues similar to noisy neighbors (e.g., workload spikes in cloud neighbors), where the activity of one tenant in an environment such as a public cloud can impact another. Other metrics, such as disk I / O operations or system logs, may also be needed, including error and audit logs. Additionally, considering power consumption as an input may also be important. The monitoring and analytics module also measures shared hardware infrastructure resources to detect exhaustion. Monitored resources include cache utilization metrics, memory bandwidth metrics, I / O bandwidth metrics for disks, storage devices, accelerators, and hardware accelerator utilization, including GPUs.

[0069] The monitoring module 302 sends a signal to the topology manager 304 with a recommended service topology change. This topology also indicates whether the workload (microservice or monolithic application) uses one or more XPUs or runs entirely within one or more XPUs (such as in cases where an IPU ACC provides additional computing space for the workload). Executing microservices as plug-ins reduces inter-process communication overhead and latency, resulting in faster response times and more efficient resource utilization.

[0070] By utilizing specific metrics similar to network traffic and quality of service, the system can fine-tune microservice configurations to maintain optimal performance. This ensures that service levels are maintained even under changing network conditions, thereby enhancing the robustness and efficiency of the networked system.

[0071] Based on the analysis, the monitoring module (303) determines whether reconfiguration can improve system performance or QoS. If reconfiguration is required, the monitoring module determines the optimal service topology (which services should be local and remote). To enable the autonomous system to anticipate and adapt to changing conditions before they affect performance or QoS, machine learning models such as Long Short-Term Memory (LSTM) can be integrated. However, this disclosure is not limited to this model, and other machine learning models similar to gradient boosting machines used for classification can be used. These models can utilize historical and real-time data to predict future system states. Machine learning is discussed below. Figure 4 discuss.

[0072] The topology manager 304 receives the signal and translates it into a specific action for the plugin manager 305 to execute via the service reconfiguration mechanism (API). For example, it can instruct the plugin manager to load certain services as local instances or to set other services as remote proxies.

[0073] Plugin Manager 305 uninstalls any currently loaded service wrappers that are no longer needed or need to be switched from local to remote (or vice versa). It then loads new service wrappers as instructed by Topology Manager, thereby instantiating local services or setting up remote service proxies as needed.

[0074] Each service wrapper (e.g., from) Figure 2 The ServiceWrapper implements a generic interface and can operate in two modes: as a local instance, handling requests directly within the Flask application; or as a remote proxy, forwarding requests over the network to independent microservice instances.

[0075] Figure 3 Further details and optional aspects can be found in conjunction with the above (e.g., Figures 1 to 2 ) or the following text (e.g., Figures 4 to 6 The example described is used for illustration.

[0076] Figure 4 A flowchart 400 illustrates the training process for a machine learning model. Historical metrics about network traffic, response time, resource usage, and errors are collected from a data source 401. This data is then preprocessed 402 to ensure it is clean and normalized (creating a sliding window to generate the input sequence for the LSTM). After preprocessing, feature engineering 403 is performed to extract and construct relevant features from the data that enhance the model's learning and predictive capabilities. This may include creating new variables, transforming existing variables, or selecting key attributes that capture important patterns in the data. The LSTM network is trained 404 on historical data, and a validation set 405 is used to monitor overfitting and optimize hyperparameters. Finally, the trained model is integrated (406) into a monitoring module for real-time data processing and timely prediction. The machine learning model can establish a threshold in the monitoring module, which triggers a system reconfiguration process (potential high-load scenarios or resource bottlenecks) when exceeded. A feedback loop is also required for continuous learning, where post-reconfiguration performance data is used to continuously improve the ML model.

[0077] Machine learning, broadly speaking, refers to the algorithms and statistical models that enable computer systems to perform specific tasks without explicit instructions, relying instead on models and inference. For example, in machine learning, data transformations can be inferred from the analysis of historical and / or training data, rather than rule-based transformations. A popular example of machine learning is using machine learning models or algorithms to analyze the content of images. To enable a machine learning model to analyze the content of an image, it can be trained using training images as input and training content information as output. By training the machine learning model with a large number of training images and / or training sequences (e.g., words or sentences) and associated training content information (e.g., labels or annotations), the machine learning model "learns" to recognize the content of images, and thus can be used to identify the content of images not included in the training images. The same principle can be applied to other types of sensor data, or more generally, to data: by training a machine learning model using training sensor data and a desired output, the machine learning model "learns" the transformation between sensor data and output, which can be used to provide outputs based on non-training sensor data provided to the machine learning model. The provided data (e.g., sensor data, metadata, and / or image data) can be preprocessed to obtain feature vectors that can be used as input to the machine learning model.

[0078] In many cases, machine learning models can be trained using training input data. The example specified above uses a training method called "supervised learning." In supervised learning, the machine learning model is trained using multiple training samples, where each sample can include multiple input data values ​​and multiple expected output values; that is, each training sample is associated with an expected output value. By specifying training samples and expected output values, the machine learning model "learns" which output value to provide based on input samples similar to those provided during training. Besides supervised learning, semi-supervised learning can also be used. In semi-supervised learning, some training samples lack corresponding expected output values. Supervised learning can be based on supervised learning algorithms, such as classification algorithms, regression algorithms, or similarity learning algorithms. Classification algorithms can be used when the output is limited to a finite set of values ​​(category variables). In other words, the input is classified into one of a finite number of values. Regression algorithms can be used when the output has any numerical value (within a range). Similarity learning algorithms are similar to classification and regression algorithms, but are based on learning from examples using a similarity function that measures the similarity or relevance between two objects. In addition to supervised or semi-supervised learning, unsupervised learning can also be used to train machine learning models. In unsupervised learning, (only) input data can be supplied, and unsupervised learning algorithms can be used to find structure in the input data (e.g., by grouping or clustering the input data to find commonalities). Clustering is the process of assigning input data, which includes multiple input values, into subsets (clusters) such that input values ​​within the same cluster are similar according to one or more (predefined) similarity criteria, while input values ​​in other clusters are different.

[0079] Reinforcement learning is the third group of machine learning algorithms. In other words, reinforcement learning can be used to train machine learning models. In reinforcement learning, one or more software agents (“software agents”) are trained to take actions in an environment. Rewards are calculated based on the actions taken. Reinforcement learning is based on training one or more software agents to select actions that increase cumulative rewards. This produces software agents that become better on the tasks they are given (as evidenced by increasing rewards).

[0080] Figure 4 Further details and optional aspects can be found in conjunction with the above (e.g., Figures 1 to 3 ) or the following text (e.g., Figures 5 to 6 The example described is used for illustration.

[0081] Figure 5A block diagram illustrating an example apparatus (or device) for configuring multiple microservices in a networked system according to one or more embodiments disclosed herein. The block diagram illustrates components, according to some example embodiments, capable of reading instructions from a machine-readable or computer-readable medium (e.g., a non-transitory machine-readable storage medium) and performing any one or more methods discussed herein. Specifically, Figure 5 A schematic representation of hardware resource 500 is shown, including one or more processors (or processor cores) 510, one or more memory / storage devices 520, and one or more communication resources 530, each of which can be communicatively coupled via bus 540. In embodiments utilizing node virtualization (e.g., NFV), a hypervisor 502 can be executed to provide an execution environment for one or more network slices / subslices to utilize hardware resource 500.

[0082] Processor 510 (e.g., a central processing unit (CPU), a reduced instruction set computing (RISC) processor, a complex instruction set computing (CISC) processor, a graphics processing unit (GPU), a digital signal processor (DSP) (such as a baseband processor), an application-specific integrated circuit (ASIC), a radio-frequency integrated circuit (RFIC), another processor, and / or any suitable combination thereof) may include, for example, processor 512 and processor 514.

[0083] Memory / storage device 520 may include main memory, disk storage devices, or any suitable combination thereof. Memory / storage device 520 may include, but is not limited to, any type of volatile or non-volatile memory, such as dynamic random access memory (DRAM), static random-access memory (SRAM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory, solid-state memory, etc.

[0084] Communication resource 530 may include interconnect or network interface components or other suitable devices for communicating with one or more peripheral devices 504 or one or more databases 506 via network 508. For example, communication resource 530 may include wired communication components (e.g., for coupling via Universal Serial Bus (USB)), cellular communication components, NFC components, Bluetooth® components (e.g., Bluetooth® Low Energy), Wi-Fi® components, and other communication components.

[0085] Instructions 550 may include software, programs, applications, applets, apps, or other executable code for causing at least any one of the processors 510 to perform any or more of the methods discussed herein. Instructions 550 may reside wholly or partially within at least one of the processor 510 (e.g., within the processor's cache memory), memory / storage device 520, or any suitable combination thereof. Furthermore, any portion of instructions 550 may be transferred from any combination of peripheral device 504 or database 506 to hardware resource 500. Therefore, the memory of processor 510, memory / storage device 520, peripheral device 504, and database 506 are examples of computer-readable and machine-readable media.

[0086] A component of a device or apparatus is defined as a component assembly, which may correspond to or be implemented by a corresponding structural component of the device. For example, Figure 5The device includes: means for processing, which may correspond to or be implemented by a processing circuit system (e.g., a processor, computer, or programmable hardware component); means for communication, which may correspond to or be implemented by an interface circuit system; and (optionally) means for storing information, which may correspond to or be implemented by a storage circuit system (e.g., a non-transitory computer-readable medium). The functionality of the device is illustrated in the following diagrams. Thus, the features described in connection with the device can also be applied to the corresponding device.

[0087] The apparatus may include an interface circuitry, a memory circuitry, machine-readable instructions, and a processor circuitry for executing the machine-readable instructions. The apparatus may be part of a system. For example, the processing circuitry may be configured to provide the functionality of the apparatus in conjunction with the interface circuitry. For example, the interface circuitry may be configured to exchange information internally or externally (e.g., with other components) between the apparatus and the memory circuitry. Similarly, a device may include means configured to provide the functionality of a device.

[0088] An interface circuit system or means for communication may correspond to one or more inputs and / or outputs for receiving and / or transmitting information within a module, between modules, or between modules of different entities, such information may be in the form of digital (bit) values ​​based on specified codes. For example, an interface circuit system or means for communication may include a circuit system configured to receive and / or transmit information.

[0089] For example, a processing circuit system or a processing device can be implemented using one or more processing units, one or more processing devices, or any means of processing, such as a processor, computer, or programmable hardware component that can operate with correspondingly adapted software. In other words, the described functionality of the processing circuit system or the means of processing can also be implemented in software, which then executes on one or more programmable hardware components. Such hardware components may include general-purpose processors, digital signal processors (DSPs), microcontrollers, etc.

[0090] For example, a storage circuit system or means for storing information may include at least one element of the group of computer-readable storage media, such as magnetic or optical storage media, such as hard disk drives, flash memory, floppy disks, random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or network storage devices.

[0091] Generally, the functionality of a processing circuit system or a means for processing can be achieved by executing machine-readable instructions (e.g., program code) by the processing circuit system or the means for processing. Therefore, any feature attributable to a processing circuit system or a means for processing can be defined by one or more of a plurality of machine-readable instructions. A means or device may include (e.g., within a storage circuit system or a means for storing information) machine-readable instructions.

[0092] Figure 5 Further illustrated are apparatus or devices for configuring multiple microservices in a networked system. The apparatus includes an interface circuitry, a memory circuitry, machine-readable instructions, and a processor circuitry that executes the machine-readable instructions to: monitor one or more metrics of the networked system; determine the topology of the networked system based on the one or more metrics; and configure multiple microservices based on the topology.

[0093] For example, a processor circuit system or a device for processing can perform the methods shown in this disclosure, such as combining Figure 1 The methods of discussion.

[0094] The monitored metrics may include at least network traffic metrics and service quality metrics. Each of the multiple microservices may be configured to selectively operate as a plugin and / or an independent service. Configuring multiple microservices may include executing two or more of the multiple microservices as plugins. Plugins may communicate with each other via in-process communication.

[0095] Each of the multiple microservices can implement a service interface that can be invoked by the service wrapper. Configuring multiple microservices can include: loading the first microservice as a first plugin into the service wrapper when the first microservice selectively operates as a plugin; or invoking the first microservice via a network request from the service wrapper when the first microservice selectively operates as an independent service.

[0096] The device may include machine-readable instructions for: receiving a request for a first microservice from a client device; and routing the request to a service wrapper. Monitoring one or more metrics of the networked system may further include: monitoring multiple shared hardware infrastructure resources. Determining the topology of the networked system may be based on a machine learning model trained on historical data of the networked system to predict its future state.

[0097] The apparatus may further include machine-readable instructions for: obtaining one or more feedback metrics regarding the configuration of multiple microservices based on the topology; and adding one or more feedback metrics as further historical data for retraining the machine learning model. Determining the topology may include identifying or selecting a subset of multiple microservices for operation as plug-ins. Each microservice within a microservice package can be configured to operate together via a port or socket.

[0098] When a network topology change requires a subset of multiple microservices operating as plug-ins to operate as independent services, that subset can be stopped or paused. Priority levels can be assigned to each microservice, and each microservice can be configured to modify its execution based on its priority level and system policies. Modifying microservice execution can include pausing a microservice or adjusting quality metrics. Each of the multiple microservices can be configured to handle 5G payload data. Groups of microservices can be configured to form microservice packages.

[0099] The device may further include machine-readable instructions for: setting thresholds for one or more metrics based on the determined topology; and continuously monitoring one or more metrics of the networked system. Further topologies of the networked system can be determined, and multiple microservices can be reconfigured based on these further topologies when thresholds are met. Monitoring of one or more metrics can be continuous, and topology determination and configuration of multiple microservices can be based on this continuous monitoring.

[0100] This device can be configured to set AI guardrails or AI thresholds for specific AI applications, including hardware buses that are considered performance constraints, particularly in terms of AI inference per unit time. These AI guardrails or thresholds can be set manually or automatically by AI, and are created due to ongoing microservice network system monitoring and telemetry. For example, the Peripheral Component Interconnect Express (PCIe) bus can be considered crucial for transferring memory and AI results between CPU and GPU memory. In this case, the PCIe bus can connect the CPU and GPU. The CPU can instruct the GPU (e.g., using an allocation operation) to allocate memory. The CPU then transfers data from the CPU system RAM to the GPU card RAM via the PCIe bus, and the GPU uses this data to perform AI inference. The GPU performs AI inference on the data transferred from the CPU system RAM and copied to the GPU RAM. The GPU then transfers the AI ​​inference results back to the CPU system RAM. The CPU receives the results and performs an action (e.g., reporting on object detection in video AI analysis). The CPU then displays the results and / or the action.

[0101] In this example, the PCIe bus could be a performance bottleneck. Therefore, the performance and capacity of the PCIe bus need to be monitored, especially when several microservices compete for limited PCIe resources on the same system (such as Kubernetes). Kubernetes is an open-source platform for automating the deployment, scaling, and management of containerized applications across clusters of machines. In this scenario, the service wrapper can decide to issue warnings and / or redirect processing between CPU and GPU to dynamically reduce the performance bottleneck. Alternatively, it can report to the system administrator that the current hardware configuration is insufficient and recommend additional resource changes, including adding more GPU PCIe cards and / or reconfiguring the entire system. Furthermore, as mentioned above, a consequence could be that, in certain scenarios, if pre-documented policies allow, a microservice could block other microservices and execute them as independent microservices. In this case, the microservice priority ordering system (e.g., the Kubernetes execution manager) would suspend some microservices.

[0102] Furthermore, particularly for deployments supporting over-the-air or 5G radio access network (RAN)-based microservice clusters, the network monitoring service wrapper can be applied to the actual data and network traffic of ongoing payload networking. Payload networking is categorized into network traffic generated by the loaded microservices, including control and data traffic from the 5G system.

[0103] Based on network traffic and QoS, this device can dynamically adapt between microservice architectures, monolithic architectures, and / or hybrid models. To this end, when services need to interact closely, they can be dynamically loaded as plugins within the same process. This reduces network traffic between these services, as they can now communicate directly within the process. When services are independent and do not require frequent communication, the system can still maintain a microservice architecture. Each microservice is also refactored to function as a plugin. This means it can be dynamically loaded into the host service, allowing it to run in the same process space and communicate directly with other plugins without network overhead.

[0104] Figure 5 Further details and optional aspects can be found in conjunction with the above (e.g., Figures 1 to 4 ) or the following text (e.g., Figure 6 The example described is used for illustration.

[0105] Figure 6 The illustration shows a computing device 700 according to one implementation of the present invention. The computing device 700 houses a board 702. The board 702 may include multiple components, including but not limited to a processor 704 and at least one communication chip 706. The processor 704 is physically and electrically coupled to the board 702. In some implementations, at least one communication chip 706 is also physically and electrically coupled to the board 702. In a further implementation, the communication chip 706 is part of the processor 704.

[0106] Depending on its application, computing device 700 may include other components that may be physically and electrically coupled to board 702 or may not be physically and electrically coupled to board 702. These other components include, but are not limited to, volatile memory (e.g., DRAM), non-volatile memory (e.g., ROM), flash memory, graphics processor, digital signal processor, cryptographic processor, chipset, antenna, display, touch screen display, touch screen controller, battery, audio codec, video codec, power amplifier, global positioning system (GPS) device, compass, accelerometer, gyroscope, speaker, camera, and mass storage devices (such as hard disk drive, compact disk (CD), digital versatile disk (DVD), etc.).

[0107] Communication chip 706 implements wireless communication for transferring data to and from computing device 700. The term "wireless" and its derivatives can be used to describe circuits, devices, systems, methods, techniques, communication channels, etc., that enable data transmission through a non-solid medium using modulated electromagnetic radiation. This term does not imply that the associated device does not contain any wires, but in some embodiments, the associated device may not contain any wires. Communication chip 706 can implement any of a variety of wireless standards or protocols, including but not limited to Wi-Fi (IEEE 802.11 series), WiMAX (IEEE 802.16 series), IEEE 802.20, Long Term Evolution (LTE), Ev-DO, HSPA+, HSDPA+, HSUPA+, EDGE, GSM, GPRS, CDMA, TDMA, DECT, Bluetooth and its derivatives, and any other wireless protocols referred to as 3G, 4G, 5G, and higher generations. Computing device 700 may include multiple communication chips 706. For example, the first communication chip 706 can be dedicated to shorter-range wireless communication, such as Wi-Fi and Bluetooth; while the second communication chip 706 can be dedicated to longer-range wireless communication, such as GPS, EDGE, GPRS, CDMA, WiMAX, LTE, Ev-DO, etc.

[0108] The processor 704 of the computing device 700 includes an integrated circuit die packaged within the processor 704. In some implementations of the invention, the processor's integrated circuit die includes one or more devices assembled in a PoP package based on an ePLB or eWLB, the package including a molded layer that directly contacts the substrate. The term "processor" can refer to any device or part of a device that processes electronic data from registers and / or memory to convert that electronic data into other electronic data that can be stored in registers and / or memory.

[0109] The communication chip 706 also includes an integrated circuit die packaged within the communication chip 706. According to another implementation of the invention, the integrated circuit die of the communication chip includes one or more devices assembled in a PoP package based on an ePLB or eWLB, the package including a molded layer that directly contacts the substrate.

[0110] Figure 6 Further details and optional aspects can be found in conjunction with the above (e.g., Figures 1 to 5 (or the examples described below)

[0111] The concept for configuring multiple microservices in a networked system may include one or more additional optional features corresponding to one or more aspects of the proposed concept or one or more examples described above or below.

[0112] It should also be understood that the disclosure of certain steps, processes, operations, or functions in the specification or claims should not be construed as implying that these operations must necessarily be performed in the described order, unless explicitly stated in a separate use case or necessary for technical reasons. Therefore, the preceding description does not limit the execution of certain steps or functions to a particular order. Furthermore, in further examples, a single step, function, process, or operation may include and / or be decomposed into several sub-steps, sub-functions, sub-processes, or sub-operations.

[0113] If aspects have been described in conjunction with an equipment or system, then those aspects should also be understood as descriptions of the corresponding method. For example, a block, device, or functional aspect of an equipment or system may correspond to a characteristic (such as method steps) of the corresponding method. Accordingly, aspects described in conjunction with the method should also be understood as descriptions of the attributes or functional characteristics of the corresponding block, element, device, or system.

[0114] Examples (e.g., Example 1) relate to a method for configuring microservices in a networked system, the method comprising: monitoring one or more metrics of the networked system; determining the topology of the networked system based on the one or more metrics; and configuring multiple microservices based on the topology.

[0115] Another example (e.g., Example 2) relates to the previously described example (e.g., Example 1), wherein one or more metrics include at least one of the following: network traffic metrics; and quality of service metrics.

[0116] Another example (e.g., Example 3) relates to the previously described examples (e.g., either Example 1 or 2), where each of a plurality of microservices is configured to selectively operate as a plugin; and as a standalone service.

[0117] Another example (e.g., Example 4) relates to the previously described example (e.g., Example 3), where configuring multiple microservices involves executing two or more of the multiple microservices as plugins.

[0118] Another example (e.g., Example 5) relates to the previously described example (e.g., Example 4), where the plugins communicate with each other via in-process communication.

[0119] Another example (e.g., Example 6) relates to the previously described examples (e.g., any one of Examples 3 to 5), wherein each of a plurality of microservices implements a service interface that can be invoked by a service wrapper, wherein configuring the plurality of microservices includes at least one of the following: loading the first microservice as a first plugin into the service wrapper when the first microservice selectively operates as a plugin; or invoking the first microservice via a network request from the service wrapper when the first microservice selectively operates as a standalone service.

[0120] Another example (e.g., Example 7) relates to the previously described example (e.g., Example 6), wherein the method further includes: receiving a request for a first microservice from a client device; and routing the request to a service wrapper.

[0121] Another example (e.g., Example 8) relates to the previously described examples (e.g., any one of Examples 1 to 7), wherein monitoring one or more metrics of a networked system further includes monitoring multiple shared hardware infrastructure resources.

[0122] Another example (e.g., Example 9) relates to the previously described examples (e.g., any one of Examples 1 to 8), in which the topology of the networked system is determined based on a machine learning model trained on historical data of the networked system to predict the future state of the networked system.

[0123] Another example (e.g., Example 10) relates to the previously described example (e.g., Example 9), wherein the method further includes: obtaining one or more feedback metrics about the configuration of multiple microservices based on the topology; and adding one or more feedback metrics as further historical data for retraining the machine learning model.

[0124] Another example (e.g., Example 11) relates to the previously described examples (e.g., any one of Examples 3 to 10), where determining the topology includes determining a subset of multiple microservices for operation as plug-ins.

[0125] Another example (e.g., Example 12) relates to the previously described example (e.g., Example 11), where multiple microservices are stopped or paused when they are determined to be a subset of plugin operations as independent service operations.

[0126] Another example (e.g., Example 13) relates to the previously described examples (e.g., any one of Examples 1 to 12), in which a group of microservices in a plurality of microservices can be configured to form a microservice package, wherein each microservice within the microservice package is configured to operate together via a port or socket.

[0127] Another example (e.g., Example 14) relates to the previously described examples (e.g., any one of Examples 1 to 13), where each microservice is assigned a priority level and each microservice is configured to modify its execution based on its priority level according to a system policy.

[0128] Another example (e.g., Example 15) relates to the previously described example (e.g., Example 14), where modifying its execution includes pausing the microservice or adjusting quality metrics.

[0129] Another example (e.g., Example 16) relates to the previously described examples (e.g., any one of Examples 1 to 14), where each of a plurality of microservices is configured to process 5G payload data.

[0130] Another example (e.g., Example 17) relates to the previously described examples (e.g., any one of Examples 1 to 16), wherein the method further includes: setting thresholds for one or more metrics based on the determined topology; and continuously monitoring one or more metrics of the networked system, wherein a further topology of the networked system is determined, and multiple microservices are reconfigured based on the further topology when the threshold is met.

[0131] Another example (e.g., Example 18) relates to the previously described examples (e.g., any one of Examples 1 to 17), in which monitoring of one or more metrics is performed continuously, and topology determination and configuration of multiple microservices are based on continuous monitoring.

[0132] Examples (e.g., Example 19) relate to a non-transitory computer-readable medium including program code that, when executed on a processor, computer, or programmable hardware component, causes the processor, computer, or programmable hardware component to perform any of the methods of the previously described examples (e.g., any one of Examples 1 to 18).

[0133] Examples (e.g., Example 20) relate to an apparatus for configuring multiple microservices within a networked system, the apparatus including an interface circuitry, a memory circuitry, machine-readable instructions, and a processor circuitry, the processor circuitry being configured to execute the machine-readable instructions to: monitor one or more metrics of the networked system; determine the topology of the networked system based on the one or more metrics; and configure the multiple microservices based on the topology.

[0134] Another example (e.g., Example 21) relates to the previously described example (e.g., Example 20), wherein one or more metrics include at least one of the following: network traffic metrics; and quality of service metrics.

[0135] Another example (e.g., Example 22) relates to the previously described examples (e.g., either Example 20 or 21), where each of a plurality of microservices is configured to selectively operate as a plugin; and as a standalone service.

[0136] Another example (e.g., Example 23) relates to the previously described example (e.g., Example 22), where configuring multiple microservices involves executing two or more of the multiple microservices as plugins.

[0137] Another example (e.g., Example 24) relates to the previously described example (e.g., Example 23), where the plugins communicate with each other via in-process communication.

[0138] Another example (e.g., Example 25) relates to the previously described examples (e.g., any one of Examples 22 to 24), wherein each of a plurality of microservices implements a service interface that can be invoked by a service wrapper, wherein configuring the plurality of microservices includes at least one of the following: loading the first microservice as a first plugin into the service wrapper when the first microservice selectively operates as a plugin; or invoking the first microservice via a network request from the service wrapper when the first microservice selectively operates as a standalone service.

[0139] Another example (e.g., Example 26) relates to the previously described example (e.g., Example 25), wherein the apparatus further includes machine-readable instructions for: receiving a request for a first microservice from a client device; and routing the request to a service wrapper.

[0140] Another example (e.g., Example 27) relates to the previously described examples (e.g., any one of Examples 20 to 26), wherein monitoring one or more metrics of a networked system further includes monitoring multiple shared hardware infrastructure resources.

[0141] Another example (e.g., Example 28) relates to the previously described examples (e.g., any one of Examples 20 to 27), in which the topology of a networked system is determined based on a machine learning model trained on historical data of the networked system to predict the future state of the networked system.

[0142] Another example (e.g., Example 29) relates to the previously described example (e.g., Example 28), wherein the apparatus further includes machine-readable instructions for: obtaining one or more feedback metrics about the configuration of multiple microservices based on the topology; and adding one or more feedback metrics as further historical data for retraining the machine learning model.

[0143] Another example (e.g., Example 30) relates to the previously described examples (e.g., any one of Examples 22 to 29), where determining the topology includes determining a subset of multiple microservices for operation as plug-ins.

[0144] Another example (e.g., Example 31) relates to the previously described example (e.g., Example 30), where multiple microservices are stopped or paused when they are determined to be a subset of plugin operations as independent service operations.

[0145] Another example (e.g., Example 32) relates to the previously described examples (e.g., any one of Examples 20 to 31), in which a group of microservices in a plurality of microservices can be configured to form a microservice package, wherein each microservice within the microservice package is configured to operate together via a port or socket.

[0146] Another example (e.g., Example 33) relates to the previously described examples (e.g., any one of Examples 20 to 32), where each microservice is assigned a priority level and each microservice is configured to modify its execution based on its priority level according to a system policy.

[0147] Another example (e.g., Example 34) relates to the previously described example (e.g., Example 33), where modifying its execution includes pausing the microservice or adjusting quality metrics.

[0148] Another example (e.g., Example 35) relates to the previously described examples (e.g., any one of Examples 20 to 34), where each of a plurality of microservices is configured to process 5G payload data.

[0149] Another example (e.g., Example 36) relates to the previously described examples (e.g., any one of Examples 20 to 35), wherein the apparatus further includes machine-readable instructions for: setting thresholds for one or more metrics based on a determined topology; and continuously monitoring one or more metrics of the networked system, wherein a further topology of the networked system is determined, and multiple microservices are reconfigured based on the further topology when the thresholds are met.

[0150] Another example (e.g., Example 37) relates to the previously described examples (e.g., any one of Examples 20 to 36), in which monitoring of one or more metrics is performed continuously, and topology determination and configuration of multiple microservices are based on continuous monitoring.

[0151] The aspects and features described in relation to a particular example in the foregoing examples may also be combined with one or more of the further examples to replace the same or similar features of the further examples or to additionally introduce these features into the further examples.

[0152] The examples may further be or relate to (computer) programs, including program code for performing one or more of the methods described above when the program is executed on a computer, processor, or other programmable hardware component. Thus, the steps, operations, or processes of the different methods described above may also be performed by a programmed computer, processor, or other programmable hardware component. The examples may also cover program storage devices, such as digital data storage media, which are machine-readable, processor-readable, or computer-readable and encoded and / or contain machine-executable, processor-executable, or computer-executable programs and instructions. For example, a program storage device may include or be a digital storage device, magnetic storage media (such as disks and tapes), hard disk drives, or optically readable digital data storage media. Other examples may include computers, processors, control units, (field)programmable logic arrays (F)PLAs, (field)programmable gate arrays (F)PGAs, graphics processor units (GPUs), application-specific integrated circuits (ASICs), integrated circuits (ICs), or system-on-a-chip (SoC) systems programmed to perform the steps of the methods described above.

[0153] It is also understood that the disclosure of steps, processes, operations, or functions in the specification or claims should not be construed as implying that these operations must be performed in the described order, unless explicitly stated in a separate use case or necessary for technical reasons. Therefore, the preceding description does not limit the execution of steps or functions to a particular order. Furthermore, in further examples, a single step, function, process, or operation may include and / or be decomposed into several sub-steps, sub-functions, sub-processes, or sub-operations.

[0154] If aspects have been described in conjunction with an equipment or system, then those aspects should also be understood as descriptions of the corresponding method. For example, a block, device, or functional aspect of an equipment or system may correspond to a characteristic (such as method steps) of the corresponding method. Accordingly, aspects described in conjunction with the method should also be understood as descriptions of the attributes or functional characteristics of the corresponding block, element, device, or system.

[0155] As used herein, the term "module" refers to logic that can be implemented using hardware components or devices, software or firmware running on a processing unit, or a combination thereof, for performing one or more operations conforming to this disclosure. Software and firmware can be embodied as instructions and / or data stored on a non-transitory computer-readable storage medium. As used herein, the term "circuit system" can individually or in any combination include non-programmable (hardwired) circuit systems, programmable circuit systems (such as processing units), state machine circuit systems, and / or firmware storing instructions executable by programmable circuit systems. Modules described herein can be embodied collectively or individually as circuit systems forming part of a computing system. Thus, any of the modules can be implemented as a circuit system. A computing system described as being programmed to perform a method can be programmed to perform that method via software, hardware, firmware, or a combination thereof.

[0156] Any method (or a portion thereof) disclosed herein may be implemented as computer-executable instructions or a computer program product (e.g., machine-readable instructions, program code, etc.). Such instructions may cause a computing system or one or more processing units capable of executing computer-executable instructions to perform any method disclosed herein. As used herein, the term "computer" refers to any computing system or device described or mentioned herein. Thus, the term "computer-executable instructions" refers to instructions executable by any computing system or device described or mentioned herein.

[0157] Computer-executable instructions can be part of, for example, the operating system of a computing system, an application stored locally on the computing system, or a remote application accessible to the computing system (e.g., via a web browser). Any of the methods described herein can be executed by computer-executable instructions, which may be executed by a single computing system or by one or more networked computing systems operating in a network environment. Computer-executable instructions and updates to them may be downloaded to the computing system from a remote server.

[0158] Furthermore, it should be understood that the implementation of the disclosed technology is not limited to any particular computer language or program. For example, the disclosed technology can be implemented by software written in C++, C#, Java, Perl, Python, JavaScript, Adobe Flash, C#, assembly language, or any other programming language. Similarly, the disclosed technology is not limited to any particular computer system or any particular type of hardware.

[0159] Furthermore, any example of the software-based examples (including, for example, computer-executable instructions for causing a computer to perform any of the methods disclosed) can be uploaded, downloaded, or remotely accessed by suitable means of communication. Such suitable means of communication include, for example, the Internet, the World Wide Web, intranets, cables (including fiber optic cables), magnetic communication, electromagnetic communication (including RF, microwave, ultrasonic, and infrared communication), electronic communication, or other such means of communication.

[0160] The disclosed methods, apparatuses, and systems should not be construed as limiting in any way. Instead, this disclosure addresses, individually and in various combinations and sub-combinations with each other, all novel and non-obvious features and aspects of the respective disclosed examples. The disclosed methods, apparatuses, and systems are not limited to any particular aspect, feature, or combination thereof, nor are the disclosed examples required to provide any one or more particular advantages or to solve any one or more particular problems.

[0161] The operational theories, scientific principles, or other theoretical descriptions of the apparatuses or methods described herein are provided for the purpose of better understanding and are not intended to limit the scope. The apparatuses and methods in the appended claims are not limited to those that operate in a manner described by such operational theories.

[0162] The appended claims are thus included in the detailed description, wherein each claim may serve as a separate example. It should also be noted that while a dependent claim in the claims statement refers to a specific combination with one or more other claims, other examples may also include combinations of the subject matter of that dependent claim with any other dependent claim or independent claim. Such combinations are expressly stated herein unless, in individual cases, it is stated that a particular combination was not contemplated. Furthermore, even if a claim is not directly limited to referencing any other independent claim, the features of that claim should be included with respect to that other independent claim.

Claims

1. A computer-executed method for configuring microservices in a networked system, the method comprising: Monitor one or more metrics of the networked system; The topology of the network system is determined based on the one or more metrics; as well as Configure multiple microservices based on the topology described above.

2. The method as described in claim 1, wherein, The one or more metrics include at least one of the following: network traffic metrics; and quality of service metrics.

3. The method as described in claim 1, wherein, Each of the multiple microservices is configured to selectively function as a plugin or a standalone service.

4. The method of claim 3, wherein, Configuring the multiple microservices includes executing two or more of the multiple microservices as plugins.

5. The method of claim 4, wherein, The plugins communicate with each other via in-process communication.

6. The method of claim 3, wherein, Each of the plurality of microservices implements a service interface that can be invoked by the service wrapper, wherein configuring the plurality of microservices includes at least one of the following: when the first microservice is selectively operated as a plugin, loading the first microservice as a first plugin into the service wrapper; or when the first microservice is selectively operated as an independent service, invoking the first microservice via a network request from the service wrapper.

7. The method of claim 6, wherein, The method further includes: receiving a request for the first microservice from a client device; and routing the request to the service wrapper.

8. The method of claim 1, wherein, Monitoring the one or more metrics of the networked system further includes monitoring multiple shared hardware infrastructure resources.

9. The method of claim 1, wherein, The topology of the networked system is determined based on a machine learning model trained on historical data of the networked system to predict the future state of the networked system.

10. The method of claim 9, wherein, The method further includes: obtaining one or more feedback metrics regarding the configuration of the plurality of microservices based on the topology; and adding the one or more feedback metrics as further historical data for retraining the machine learning model.

11. The method of claim 3, wherein, Determining the topology includes: determining a subset of the plurality of microservices for use as plugin operations.

12. The method of claim 11, wherein, When the subset of the multiple microservices is determined to be used as a plugin operation, it is stopped or paused as an independent service operation.

13. The method of claim 1, wherein, The group of microservices among the multiple microservices can be configured to form a microservice package, wherein each microservice within the microservice package is configured to operate together via a port or socket.

14. The method of claim 1, wherein, Each microservice is assigned a priority level, and each microservice is configured to modify its execution based on its priority level according to system policies.

15. The method of claim 14, wherein, Modifications to its execution include: pausing microservices or adjusting quality metrics.

16. The method of claim 1, wherein, Each of the multiple microservices is configured to process 5G payload data.

17. The method of claim 1, wherein, The method further includes: setting thresholds for the one or more metrics based on the determined topology; and continuously monitoring the one or more metrics of the networked system, wherein a further topology of the networked system is determined, and when the thresholds are met, the plurality of microservices are reconfigured based on the further topology.

18. The method of claim 1, wherein, Monitoring of the one or more metrics is performed continuously, and the topology and configuration of the multiple microservices are based on this continuous monitoring.

19. An apparatus comprising: processor; A memory coupled to the processor, the memory being used to store instructions that, when executed by the processor, perform the method as described in any of the preceding claims.

20. A machine-readable storage device comprising machine-readable instructions that, when executed, cause a computer to perform the method as described in any one of claims 1 to 18.

21. A computer program comprising instructions that, when executed by a computer, cause the computer to perform the method as claimed in any one of claims 1 to 18.

Images