Emc IP Holding Company LLC

Dell Products Inc.

Roi Gamliel

Avitan Gefen

Amihai Savir

Anat Parush Tzur

Shai Harmelin

Idan Levy

Joseph LaSalle White

Techniques are provided for data-driven organization adjustment. In an example, a service mesh of microservices of a platform can be determined. An organizational chart of workers in an organization that maintain the microservices can be determined. Which workers manage which microservices can be determined from a repository in which code for the microservices is maintained. Then, the organizational chart can be analyzed to determine whether workers are organized in a way that meets policies based on which microservices they manage. For example, a policy can be that all workers who manage a given microservice should report to the same manager in the organization.

Data-driven organization adjustment

An organizational graph and a microservice graph can be generated. For two neighboring microservices, a combined organizational distance can be determined based on a distance for respective workers of each microservice in the organizational graph. The combined organizational distance can be used to determine a priority for a connection between the two microservices, and chaos testing can be performed on that connection based on its priority.

Data driven chaos engineering based on service mesh and organizational chart

One example method includes collecting telemetry data for each of a group of virtual machines (VM), and each of the VMs is associated with a user, collecting usage data for each of the VMs, creating a user profile definition for each user, and the user profile definition is created based on the telemetry data and usage data of the VMs associated with that user, creating, for each user, a user profile that is based on the user profile definition for that user, clustering the users based on similarity of their respective user profiles, and generating a recommended VM hardware configuration for a VM of one of the users.

Elastic cloud service with data driven cost reduction for VMS in the cloud

Identifying risky code in microservices is described. A system identifies a modification to code segments in an application. The system determines a segments similarity score based on comparing the code segments, which are in a microservice of the application, against other code segments, which are in another microservice of the application. The system determines whether the segments similarity score satisfies a segments similarity threshold. The system outputs a recommendation to make the modification, which was made to the code segments in the microservice of the application, to the other code segments in the other microservice in the application, in response to a determination that the segment similarity score satisfies the similarity threshold.

Micro services recommendation system for identifying code areas at risk

One example method includes identifying a changed microservice whose code has been changed, mapping, for each microservice in a group of microservices that includes the changed microservice, microservice dependencies associated with the changed microservice, determining, for each microservice in the group, a relative risk that the microservice will be adversely affected by the change to the code of the changed microservice, and based on the respective relative risks, generating a test order indicating an order in which the microservices in the group will be tested.

Micro services tests prioritization

Techniques are provided for chaos engineering in microservices using a service mesh. In an example, a plurality of microservices can operate together as part of a software as a service product. A graph of the service mesh of the plurality of microservices can be determined. From that graph, weight can be assigned to the respective nodes. Those weights can be used to determine a probability of where chaos is introduced in the corresponding microservice architecture as part of chaos testing.

Chaos engineering in microservices using a service mesh

Systems and methods for detecting cost anomalies in a data protection system. Data is collected for assets of a data protection system operating in a cloud. The data often relates to cost and may constitute time series. The time series are then analyzed by performing a fitting competition using multiple models. The best fitting model is selected and the residuals are analyzes to find outliers and produce a normal zone for the signal. The outliers can identify cost anomalies that may reflect the health of the data protection system.

Cost anomaly detection in cloud data protection

Described is a system for creating an intelligent testing queue for improved quality assurance (QA) testing of services (or microservices). The system may perform a graphical analysis of interactions between services to derive testing constraints. For example, the system may monitor services to identify interactions (e.g. API accesses) between the services, and store the interactions as a directed graph representation. The system may traverse the directed graph (e.g. via a breadth-first search) to determine service dependencies. Based on the probability of failure for the testing operations and the service dependencies, the system create a specialized testing queue. By performing testing operations according to the specialized queue, the system may improve certain metrics associated with QA processes such as mean time to failure (MTTF) and mean time to diagnose (MTTD).

Creating an intelligent testing queue for improved quality assurance testing of microservices

Described is a system and method that provides a data protection risk assessment for the overall functioning of a backup and recovery system. Accordingly, the system may provide a single overall risk assessment score that provide an operator with an 'at-a-glance' overview of the entire system. Moreover, the system may account for changes that occur over time based on leveraging statistical methods to automatically generate assessment scores for various components (e.g. application, server, network, load, etc.). In order to determine a risk assessment score, the system may utilize a predictive model based on historical data. Accordingly, residual values for newly observed data may be determined using the predictive model and the system may identify potentially anomalous or high risk indicators.

Generating a data protection risk assessment score for a backup and recovery storage system

An alert configuration system facilitates accurate and reliable configuration of alerts for data protection policy in a data protection system, including eliminating or reducing manual configuration of data protection policy. The system identifies risks through trend analysis and behavioral statistics as applied to historical data, and automatically configures alerts for the identified risks so that alerts are generated upon detection of the identified risks. After detecting differences between tracked values for a data protection system and predicted values obtained through trend analysis and behavioral statistics as applied to the historical data, the alert configuration system automatically adjusts the configuration of alerts for data protection policy in accordance with the predicted values. The tracked and predicted values include attributes of a data protection system embodied in key performance indicators associated with the identified risks based on the trend analysis and behavioral statistics as applied to historical data.

Alert configuration for data protection

A system recommends the refactoring of microservices. The system determines a segments similarity score based on comparing first code segments, associated with a first microservice in an application, against second code segments, associated with a second microservice in the application. The system determines whether the segments similarity score satisfies a segments similarity threshold. The system determines microservices similarity scores based on comparing a size of similar code segments in the first code segments and the second code segments against sizes of the first microservice and the second microservice, if the segments similarity score satisfies the segments similarity threshold. The system determines whether any microservices similarity score satisfies a microservices similarity threshold. The system outputs a recommendation to merge the first microservice with the second microservice, if any microservices similarity score satisfies the microservices similarity threshold.

Recommending the refactoring of microservices

A system recommends the refactoring of microservices. The system generates a graph of connected nodes including a first node, which represents a first atomic part of code in a microservice in an application, and a second node, which represents a second atomic part of code in the microservice. The system determines a nodes connection score based on any connections between the first node and the second node. If the nodes connection score satisfies a nodes connection threshold, the system determines a relative code size based on comparing a size associated with the first atomic part of code against a size of the microservice. If the relative code size satisfies a code size threshold, the system outputs a recommendation to disconnect the first atomic part of code from the microservice, create another microservice in the application, and connect the first atomic part of code to the other microservice.

Growing community of inventors

Moshav Tkuma, Israel

Roi Gamliel