A data-centric network and non-Real-Time (RT) RAN Intelligence Controller (RIC) architecture are described. The data-centric network architecture provides data plane functions (DPFs) that serve as a shared database for control functions, user functions and management functions for data plane resources in a network. The DPFs interact with control plane functions, user plane functions, management plane functions, compute plane functions, network exposure functions, and application functions of the NR network via a service interface. The non-RT RIC provides functions via rApps, manages the rApps, performs conflict mitigation and security functions, monitors machine learning (ML) performance, provides a ML model catalog that contains ML model information, provides interface terminations and stores ML data and Near-RT RIC related information in a database. An ML training host trains and evaluates ML models in the catalog, obtains training and testing data from the database, and retrains and updates the ML models.

Embodiments include a resource allocation system for managing execution of a computing task by a hierarchically-arranged computing infrastructure. In embodiments, the resource allocation system can comprise a resource map, an index processor, and an allocation manager. The resource map can include data elements that are associated with each service provider, including parent-child relationships. Workloads can be assigned to providers based on one or more optimization indexes calculated for each service provider based on a plurality of level-specific performance metrics received from one or more monitoring engines.

Disclosed herein are system, method, and computer program product embodiments for deploying a configurable throttling library in a cloud platform that throttles requests according to fully customizable parameters across each origin and resource. An administrator can harness the full customization provided by the throttling library to specify increment, decrement, delay, threshold, expiration, and rejection policies. These policies allow administrators to specify parameters guiding throttling on a per-user and a per-resource basis, thus providing significantly enhanced configuration capabilities to the administrator to tailor the throttling to the unique requirements of their applications and the usage thereof.

This document describes modeling and simulation techniques to select a cloud architecture profile based on correlations between application workloads and resource utilization. In some aspects, a method includes obtaining infrastructure data specifying utilization of computing resources of an existing computing system. Application workload data specifying tasks performed by one or more applications running on the existing computing system is obtained. One or more models are generated based on the infrastructure data and the application workload data. The model(s) define an impact on utilization of each computing resource in response to changes in workloads of the application(s). A workload is simulated, using the model(s), on a candidate cloud architecture profile that specifies a set of computing resources. A simulated utilization of each computing resource of the candidate cloud architecture profile is determined based on the simulation. An updated cloud architecture profile is generated based on the simulated utilization.

A method comprises initiating a first application in a first one of a plurality of distributed processing nodes, and responsive to initiation of the first application, identifying a plurality of beacon entities to be contacted in conjunction with execution of at least a portion of the first application. The method also comprises, for each of at least a subset of the identified beacon entities, initiating an additional application in an additional one of the plurality of distributed processing nodes. The method further comprises aggregating processing results from the first and one or more additional processing nodes, and providing the aggregated processing results to a client. The plurality of distributed processing nodes may comprise a plurality of YARN clusters associated with respective data zones, with each of the clusters being configured to perform processing operations utilizing local data resources locally accessible within its corresponding data zone.

A controller device manages a plurality of network devices. The controller device includes one or more processing units implemented in circuitry and configured to determine that one or more stateful intents used to manage the plurality of network devices and represented by a graph model are degraded due to assigned resources for the stateful intents having become degraded; in response to determining that the one or more stateful intents are degraded, determine resources for the stateful intents, the resources corresponding to vertices of the graph model; provision the stateful intents using the determined resources; determine whether the provisioning of the stateful intents was successful; compile at least one of the stateful intents that was successful into low-level configuration data for at least one network device of the plurality of network devices; and configure the at least one network device using the low-level configuration data.

A method of determining trigger conditions for scaling a scalable unit of network function comprising identifying a primary set of metrics associated with usage of an instance of the unit of network function as a primary indicator of occurrence of a load state thereof, and determining usage points when the primary indicator indicates that the load state occurs. Deriving a secondary set of the metrics, different to the primary set, as a secondary indicator of occurrence of the load state of the instance at each of a group of one or more of the usage points when the primary indicator indicates that the load state occurs, and measured data corresponding to values of the metrics in the secondary set of metrics at each of the group of usage points. Storing a trigger condition for scaling the unit of network function based on the secondary set and the measured data.

A first portion of a distributed catalog service is implemented for a given one of a plurality of distributed processing node clusters associated with respective data zones, each of the clusters being configured to perform processing operations utilizing local data resources locally accessible within its corresponding data zone. The first portion of the distributed catalog service receives a request to identify for each of a plurality of data resources to be utilized by an application initiated in the given cluster whether the data resource is a local or remote data resource relative to the given cluster, and provides a response to the request. The first portion of the distributed catalog service in combination with additional portions implemented for respective additional ones of the distributed processing node clusters collectively provide the distributed catalog service with capability to resolve local or remote status of data resources in each of the data zones.

Data services are often provided with consistency guarantees of either strong consistency models, comprising uniform wall-clock consistency, or eventual consistency models, where temporary logical inconsistency is guaranteed to be resolved only after full data propagation. However, the performance characteristics of contemporary services often require an intermediate consistency model, where some aspects of the service have specific consistency expectations and other aspects of the service are flexible, such as bounded staleness (e.g., a maximum delay in reaching consistency); session consistency (e.g., individual sessions remain logically consistent, but ordering may vary across sessions); and prefix consistency (e.g., each view during a session is logically consistent, but ordering may vary between session views). Service guarantees may involve a selection within a range of consistency models that includes one or more intermediate consistency levels, and server configurations may be selected and applied to fulfill the intermediate consistency level selected in the service level agreement.

Databases are often provided according to various organizational models (e.g., document-oriented storage, key/value stores, and relational database), and are accessed through various access models (e.g., SQL, XPath, and schemaless queries). As data is shared across sources and applications, the dependency of a data service upon a particular organizational and/or access models may become confining. Instead, data services may store data in a base representation format, such as an atom-record-sequence model. New data received in a native item format may be converted into the base representation format for storage, and converted into a requested format to fulfill data requests. Queries may be translated from a native query format into a base query format that is applicable to the base representation format of the data set, e.g., via translation into an query intermediate language (such as JavaScript) and compilation into opcodes that are executed by a virtual machine within the database engine.