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 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: 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: 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 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: Methods and systems for managing pods and containers that provide computer implemented services are disclosed. The pods and containers may be managed to improve efficiency of resource use and reduce exposure to threats to operation of systems that host the pods and containers. To ascertain how to manage the pods and containers, the pods and containers may be monitored and analyzed. The results of the monitoring and analyzation may be used to select how to change the pods and containers over time.

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 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 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 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 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: Methods and systems for managing operation of a deployment are disclosed. The operation of the deployment may be managed by simulating devices with a digital twin within the deployment. The digital twin may serve to replace operation of failed devices. By replacing failed devices with the digital twin, cooperative processes requiring participation of the failed devices may be continued while the failed devices are unable to participate.

Abstract: Methods and systems for managing operation of a deployment are disclosed. The deployment may be managed by employing redundant devices within the deployment. The redundant devices may serve to replace operation of failed devices. Despite replacement of operations of a failed device, the redundant device may not have similar functionality as the failed device. To make the functionality similar to the failed device, a correction factor may be applied to the redundant device. In applying the correction factor, the output from the redundant device may be expected to match output from the failed device. In matching output from the failed device, the redundant device may operate in place of the failed device.

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: Methods and systems for remediating impaired devices in a deployment are disclosed. The devices may be remediated by repairing or replacing the devices. Whether to repair or replace the devices may depend on the operational and performance costs of running the impaired devices in the deployment. Operational costs may include the retail price of the device and any energy requirements to run the impaired device. Performance costs may include effects of the output of the impaired device on other devices along the pathway of devices. If the integrated costs of the operational costs and performance costs outweigh the sum of the individual operational costs and performance costs, then the device may be replaced; otherwise, the device may be repaired.

Abstract: Methods and systems for managing operation of a deployment are disclosed. The deployment may be managed by monitoring the failures of operation of devices within the deployment. The failures of operation may be monitored through utilization of a failure aggregator. The failure aggregator may catalogue notices of failures of operations for devices within the deployment. Notices of failures of operation may be received by the failure aggregator from devices that may experience a failure of operation. Notices of failure of operation may also be received from devices operably connected to other devices that may experience failures of operation. In response to failures of operation, the failure aggregator may generate network maps of operable devices and initiate remediation of devices that may experience failures of operation.

Abstract: Methods and systems for prioritizing resources are disclosed. The resources in a deployment may be prioritized by training machine learning models for use in repairing impaired devices with failures of operation. The trained machine learning models may learn differences in operation. Differences in operation may pertain to output between each device of the set of devices and the digital twin in the deployment. The differences in operation may be used to prioritize a list of impaired devices that may be repaired. The prioritized list of impaired devices may be followed when available resources may be expended to repair the impaired devices.

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.

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.