Cloud Deployment Upgrades With Constraint Checks and Rollback

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Managing software and hardware deployments is complex due to interdependencies and data migrations that can break after version upgrades, impacting health and performance metrics, with conventional methods failing to ensure compatibility and minimize downtime.

Innovation Solution

A system that obtains a current deployment status from logs, adheres to a deployment plan with constraint checks, and performs tasks like upgrades or changes while ensuring compatibility and health, using a central upgrade server to manage deployments across nodes.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If version upgrade is implemented to improve software functionality, then product capabilities are enhanced, but interdependencies between services may be broken and system reliability deteriorates

Engineering Contradiction:
Improveproduct capabilitiesVSAvoidservice interdependency stability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The system performs preliminary constraint checks before executing upgrade tasks. The constraint checking mechanism validates service interdependencies, data migration compatibility, and resource availability in advance, preventing upgrades that would break service relationships or cause system failures.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system continuously monitors deployment status and provides feedback to the constraint checking mechanism. This feedback loop allows the system to detect issues during upgrade execution and trigger rollback procedures or pause operations when constraints are violated, maintaining system reliability throughout the upgrade process.

Inventive Principle:
Principle #23Feedback

2Adaptability or versatility

If data migration is performed to transfer data between storage types or formats, then data compatibility is improved, but system downtime increases and productivity decreases

Engineering Contradiction:
Improvedata compatibilityVSAvoidsystem availability
Core Design Contradiction:
Adaptability or versatilityVSProductivity

Solution Approach 1:

The system checks data migration constraints before initiating migration tasks, validating schema compatibility and resource availability in advance. This preliminary validation ensures that migrations can proceed with minimal disruption and appropriate scheduling.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The system dynamically adjusts migration execution based on real-time monitoring of system load and service dependencies. Migration tasks are scheduled and executed with dynamic resource allocation, allowing the system to maintain productivity by performing migrations during low-activity periods or using available resources efficiently.

Inventive Principle:
Principle #15Dynamics

3Reliability

If comprehensive constraint checking is performed to ensure upgrade compatibility, then system reliability is improved, but deployment complexity increases

Engineering Contradiction:
Improveupgrade compatibilityVSAvoiddeployment management complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The constraint checking mechanism serves multiple functions: validating service interdependencies, checking data migration compatibility, verifying resource availability, and coordinating upgrade scheduling. This multi-functional approach consolidates what would otherwise require separate complex systems into a single unified mechanism.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The system automatically performs constraint checking and executes or pauses upgrade tasks based on constraint validation results, without requiring manual intervention for each check. The centralized upgrade server autonomously manages the deployment process, reducing operational complexity despite comprehensive validation.

Inventive Principle:
Principle #25Self-service

4Adaptability or versatility

If multiple deployments are managed simultaneously with interdependent services, then system functionality is enhanced, but managing upgrades and changes becomes more complex

Engineering Contradiction:
Improvesystem functionalityVSAvoiddeployment management complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system merges the management of multiple deployments under a single centralized upgrade server that coordinates upgrades across all deployments. This centralization consolidates what would otherwise require separate management processes, reducing overall complexity while maintaining the ability to manage multiple interdependent services.

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The centralized upgrade server acts as an intermediary between multiple deployments and their respective upgrade tasks. It manages constraints, coordinates execution timing, and ensures compatibility across deployments, simplifying the management of interdependent services by providing a single point of control.

Inventive Principle:
Principle #24Intermediary (Mediator)

Data Source

PatentUS20260010362A1Constraint-based upgrade and deployment
Publication Date: 2026.01.08 PALANTIR TECHNOLOGIES INC
  • US20260010362A1 patent drawing
  • US20260010362A1 patent drawing
  • US20260010362A1 patent drawing

AI summary

One or more software products/services may be installed on a cloud deployment. Product versions of such services can be upgraded (or rolled back) based on a deployment plan comprising tasks adapted to reach a target deployment state. A central upgrade server can forward tasks to an upgrade agent for execution, the tasks being based on a current operational state of the cloud deployment (obtained by the upgrade agent) and one or more constraints. In multiple node deployments, some nodes may be upgraded to a new product version, while other nodes are kept at a current product version until stability of the new product version is determined. Traffic across nodes can be shaped to ensure a deployment is healthy before upgrading other nodes/deployments. If the health of a node/deployment does not meet specified criteria, an upgrade can be stopped, an alert can be triggered, and the node/deployment can be rolled back.