Abstract: The technology described herein is directed towards combining multiple sidecar (e.g., Envoy-based) proxies into a single sidecar or reduced number of sidecars for use in association with a service. Described is identifying sidecars for merging, grouping by version compatibility, and determining their functions and configuration data. Any conflicts in the configuration data are resolved. A merged sidecar is built by combining functional code and configuration data. The merged sidecar is deployed along with its relevant service, e.g., deployed as a container in a Kubernetes environment. The merging facilitates reduction of resource utilization by having only a merged sidecar, instead of multiple sidecars, support a service.

Abstract: Methods and systems for managing the operation of data processing systems are disclosed. To manage the operation of the data processing systems, access control standards for software may be enforced during development and/or deployment of software. The access control standards may indicate the extent of access controls for data that are to be in place for various pieces of software. The access control standards may also indicate a level of consistency in the sources of truth for permissions enforced by the access controls.

Abstract: A system can identify, by a control plane, that a base image has been registered to a first registry that is stored outside of the computing cluster. The system can identify, by the control plane, a trust bundle that corresponds to the base image. The system can send, by the control plane and to a secure pipeline that operates outside of the control plane, a message to update the base image. The system can create, by the secure pipeline, an updated image based on the base image and the trust bundle. The system can send, by the secure pipeline, the updated image to the control plane. The system can store, by the control plane, the updated image in a local registry that is stored on the computing cluster.

Abstract: Methods and systems for managing a backup system are disclosed. Edge infrastructures may be made up of large numbers of edge devices that produce and store a wide variety of data. A data backup system is implemented to locate and monitor locations of data stored in these edge infrastructures such that users wanting to backup data from these edge infrastructures are not required to know an exact location and/or an exact name of the data to be backed up. In particular, the data backup system could backup data using only natural language descriptions of the data that is provided by the user.

Abstract: Methods and systems for managing operation of a distributed system comprising a data center and edge devices. The operation of the distributed system may be managed by monitoring the edge devices. The edge devices may be monitored by identifying the health state of an edge device. The health state of the edge device may be identified by collecting data from operation of similar edge devices and the edge device and comparing the differences in between the data. If the differences between the data from the operation of the similar edge devices and operation of the edge device may exceed criteria for deviation, then the edge device may be determined to be in an unhealthy health state.

Abstract: Methods and systems for managing trust in distributed are disclosed. To manage trust, a behavior and characteristic based trust model may be used. The trust model may utilize similarity between devices and public activity of devices over time to ascertain levels of trust that should be afforded devices of the distributed system. The levels of trust may be used to ascertain whether requests from devices of the distributed systems should be honored, or rejected. The trust models may facilitate establishment of trust in environments where physical intrusion based threats are present.

Abstract: Systems and methods for risk assessment of user accesses to data resources are described. In an illustrative, non-limiting embodiment, an Information Handling System (IHS) may include: a processor; and a memory coupled to the processor, where the memory includes program instructions store thereon that, upon execution by the processor, cause the IHS to: obtain a plurality of resource risk weights of a respective plurality of resources, and a plurality of access permissions of a user for the respective plurality of resources; and generate based, at least in part, on the plurality of resource risk weights and the plurality of access permissions of the user, a risk score for the user that represents a level of security impact of the user on the plurality of resources.

Abstract: A system can determine complexity data representative of a complexity of changes to computer code that is executable to operate at least one updated microservice that is part of a group of microservices, wherein at least one current microservice is deployed, and wherein the at least one updated microservice corresponds to an update of the at least one current microservice. The system can determine a rate at which invocations of the at least one current microservice are made. The system can determine a threshold number of calls to be processed to proceed from a first stage of a progressive deployment plan to a second stage of the progressive deployment plan based on the complexity data and the rate. The system can progressively direct traffic to the at least one updated microservice based on the progressive deployment plan.

Abstract: Methods and systems for device shutdown in a deployment are disclosed. Device shutdown may be considered to conserve energy and simplify processes in a deployment. To conserve energy and simplify processes, all devices within a deployment may undergo a redundancy analysis and qualification analysis. The redundancy analysis may produce lists of redundant and non-redundant devices. All redundant devices may be candidates for device shutdown. Next, qualification analysis may qualify devices for shutdown by energy consumption and output data accuracy and uncertainty qualification. Devices that may not meet prescribed qualifiers may also be candidates for shutdown. With all devices that may be candidates for shutdown assembled in a list, device shutdown may commence in the deployment.

Abstract: A system can determine respective health statuses for respective microservices of respective instances of a group of microservices. The system can monitor the requests to determine a correlation between respective requests of the requests and respective subgroups of microservices of the group of microservices that carry out the respective requests. The system can determine a subgroup of container clusters of container clusters that are available to serve a first request type, based on determining an intersection between the respective subgroups of microservices of the group of microservices that carry out the respective requests, and the respective health statuses for respective microservices of respective instances of the group of microservices. The system can, in response to receiving a first request of the first request type, assign, by a load balancer, the first request to be served by a first container cluster of the subgroup of container clusters.

Abstract: A system, method, and computer-readable medium for performing a data center management and monitoring operation. The data center management and monitoring operation includes: identifying a plurality of process flows; identifying a plurality of microservices associated with each of the plurality of process flows; mapping each of the plurality of microservices associated with each of the plurality of process flows; calculating a centrality value for each of the plurality of microservices associated with each of the plurality of process flows based upon the mapping; and, testing at least some of the plurality of microservices based upon the centrality value for each of the plurality of microservices.

Abstract: A system can receive, at an integration and deployment component, a changeset for an updated microservice and an identifier of a user account that is configured to access the updated microservice, wherein a current version of the microservice is deployed to a service mesh that comprises a group of microservices. The system can instantiate the updated microservice to the service mesh. The system can update routing rules for the service mesh to indicate that any traffic in the service mesh that is associated with the user account and that is directed to the current version of the microservice is to be routed to the updated microservice. The system can, in response to receiving traffic determined to be associated with the user account and directed to the current version of the microservice, route the traffic to the updated microservice instead of routing the traffic to the current version of the microservice.

Abstract: The technology described herein is directed towards combining multiple sidecar (e.g., Envoy-based) proxies into a single sidecar or reduced number of sidecars for use in association with a service. Described is identifying sidecars for merging, grouping by version compatibility, and determining their functions and configuration data. Any conflicts in the configuration data are resolved. A merged sidecar is built by combining functional code and configuration data. The merged sidecar is deployed along with its relevant service, e.g., deployed as a container in a Kubernetes environment. The merging facilitates reduction of resource utilization by having only a merged sidecar, instead of multiple sidecars, support a service.

Abstract: A system can determine complexity data representative of a complexity of changes to computer code that is executable to operate at least one microservice that is part of a group of microservices, wherein a portion of the changes corresponds to a library on which the computer code depends. The system can generate a progressive deployment plan for the at least one microservice based on the complexity of changes. The system can progressively direct traffic to the at least one microservice based on the progressive deployment plan.

Abstract: A system can monitor a containerized function for a number of iterations of the containerized function. The system can, for the respective iterations, determine respective upper limits of amounts of time for which the containerized function is idle, and determine respective numbers of cold starts of the containerized function. The system can determine whether a percentage of the respective iterations, for which corresponding upper limits, of the respective upper limits, on amount of time for which the containerized function is idle, is below a threshold idleness value, and for which corresponding numbers of cold starts, of the respective numbers of cold starts, are above a threshold cold start value. The system can, in response to determining that the percentage of the respective iterations is above a threshold successful probes value, deploy a microservice that is configured to execute the function.

Abstract: A system can determine to combine a first function that executes in a first container and a second function that executes in a second container in a third container. The system can determine a first runtime of the first function based on a first container configuration of the first container. The system can determine a second runtime of the second function based on a second container configuration of the second container. The system can deploy the third container that comprises the first function matched to the first runtime and the second function matched to the second runtime. The system can direct a first call to the first function to the third container. The system can direct a second call to the second function to the third container.

Abstract: A system can determine that a first containerized function invokes a second containerized function. The system can access first source code of the first containerized function from a repository. The system can access second source code of the second containerized function from the repository. The system can package the first source code and the second source code into an image that comprises a container in which the first source code and the second source code are configured to execute. The system can deploy the image to produce a deployed image. The system can terminate a first executing instance of the first containerized function. The system can terminate a second executing instance of the second containerized function. The system can direct a first call to invoke the first containerized function to the deployed image. The system can direct a second call to invoke the second containerized function to the deployed image.

Abstract: A system can determine that a first containerized function invokes a second containerized function. The system can identify a first number of instances of the first containerized function, and a second number of instances of the second containerized function. The system can determine a first cost of executing the first number of instances of the first containerized function, and the second number of instances of the second containerized function, wherein the first cost comprises a first computer memory cost, a first computer storage cost, and a first service level agreement violation cost. The system can determine a second cost associated with executing a third number of instances of a third container that comprises the first function and the second function. The system can, in response to determining that the second cost is less than the first cost, execute the third number of instances of the third container.

Abstract: A system can identify that computer code that is executable to operate at least one microservice that is part of a group of microservices has been modified. The system can determine complexity data representative of a complexity of changes to the computer code. The system can determine conditions under which the changes to the computer code are invoked based on at least one of performing a static analysis of the computer code or instrumenting the computer code. The system can generate a progressive deployment plan for the at least one microservice based on the complexity of changes. The system can progressively direct traffic to the at least one microservice based on the progressive deployment plan, and the conditions under which the changes to the computer code are invoked.

Abstract: Technology described herein relates to managing backdoor vulnerabilities of a computer system. A system for the managing can comprise a processor, and a memory that stores executable instructions that, when executed by the processor, facilitate performance of operations, comprising analyzing system information relating to operation of an application programming interface (API); based on a result of the analyzing of the system information, constructing a call function for execution of the API and executing the call function; based on monitoring a data flow of the system with respect to the execution of the API, generating impact data representative of an impact of the execution of the API; and determining whether the impact is counter to historical functioning of the system as represented by historical functioning data.