Dynamic Restore Policy for Microservice Dependencies
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Cloud native applications with microservices face challenges in data corruption and lack of fine-grained control during restore processes, particularly due to frequent updates and interdependent microservices, which are not well-suited for dynamic cloud environments.
Innovation Solution
A data protection system with automated smart restore functionality that creates granular restore policies for microservices, using service mesh connections to identify and restore only necessary microservices to a previous point in time, ensuring interdependent services are restored together while independent services can be updated separately.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Measurement precision
If manual restore processes are used to identify and restore failed microservices, then fine-grained control over restore operations is achieved, but the process is time-consuming and not suitable for dynamic cloud environments
Solution Approach 1:
The system implements self-service by automatically detecting microservice failures, identifying affected dependent microservices, and executing restore operations without manual administrator intervention. The automated smart restore functionality monitors the system state, determines which microservices need restoration, and performs the restore process autonomously, eliminating the time-consuming manual steps while maintaining fine-grained control.
Solution Approach 2:
The system performs preliminary action by pre-establishing dependency relationships between microservices and pre-configuring restore policies. When a failure occurs, the system already has the information needed to quickly determine which microservices are affected and should be restored together, enabling rapid automated response without needing to analyze dependencies in real-time during the restore process.
2Productivity
If bulk random restore processes are used, then restore operations can be performed, but fine-grained control over restore order and scope is lost
Solution Approach 1:
The system applies segmentation by dividing the restore process into discrete, controllable units at the microservice level. Instead of treating restores as bulk operations, the system identifies individual failed microservices and their specific dependent services, creating segmented restore tasks that can be precisely controlled and executed in the correct order based on dependency relationships.
Solution Approach 2:
The system implements dynamics by making the restore process adaptive to the specific failure scenario. The restore scope and order are dynamically determined based on the actual failure state and dependency relationships, rather than following a fixed bulk restore pattern. This allows the system to adjust the restore granularity and sequence automatically based on the situation.
3Productivity
If microservices are updated frequently to improve productivity, then application development efficiency increases, but the risk of data corruption and system failure increases
Solution Approach 1:
The system provides beforehand cushioning by implementing automated restore capabilities that stand ready to compensate for potential update failures. Before frequent updates can cause data corruption or system failure, the system has pre-configured restore policies and automated detection mechanisms in place to quickly respond to and recover from update-related issues, cushioning against the increased risks of frequent updates.
Solution Approach 2:
The system uses feedback by continuously monitoring microservice health and automatically detecting failures caused by updates. This real-time feedback enables the system to identify when an update has caused a failure and trigger appropriate restore operations, creating a closed-loop system where update risks are continuously monitored and corrected, allowing frequent updates while maintaining reliability.
4Ease of operation
If interdependent microservices are restored independently, then individual service restoration is simplified, but failures can propagate to dependent microservices
Solution Approach 1:
The system applies merging by automatically identifying and grouping interdependent microservices that need to be restored together. When a failure is detected, the system traces dependency relationships to determine which microservices are affected and combines them into a coordinated restore operation, ensuring that dependent services are restored together while maintaining the simplicity of automated execution.
Data Source
AI summary
One example method includes identifying a group of microservices that form respective portions of an application, capturing any relations among microservices in the group of microservices, generating one or more restore policies for the application, based on identified relations among the microservices in the group of microservices, and configuring one of the restore policies so that such restore policy specifies restoring, together, a microservice that was identified as a partial cause of a problem, and any other microservices that are dependent on that microservice.