Service Graphs for Microservice Version Comparison

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing systems lack an efficient method to compare and transition between different versions of microservices during deployment, particularly in canary deployments, which can impact network traffic, latency, and error rates, making it difficult to determine the performance of new versions and smoothly phase out old ones.

Innovation Solution

The use of service graphs to monitor and compare metrics such as traffic volume, latency, and error rates between different versions of microservices, allowing for gradual traffic diversion from old to new versions based on performance differences, enabling controlled deployment and phasing out of old versions.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple versions of microservices are deployed concurrently for canary deployment, then the ability to compare performance and gradually phase out old versions is improved, but the complexity of monitoring and managing multiple versions increases

Engineering Contradiction:
Improveability to compare performance and phase out versionsVSAvoidcomplexity of monitoring and managing multiple versions
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The system segments microservice versions into distinct deployable units (canary versions vs. stable versions) that can be independently monitored and managed. Each version is tracked separately through version identifiers in the service graph, allowing granular control over deployment phases without managing all versions as a single complex system

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The service graph continuously monitors performance metrics (latency, error rates, traffic volume) for each microservice version and provides feedback to the deployment system. This feedback mechanism enables automatic comparison between versions and triggers phased traffic redistribution based on observed performance differences, reducing manual monitoring complexity

Inventive Principle:
Principle #23Feedback

2Reliability

If network traffic is gradually diverted from old to new microservice versions, then seamless transitions with minimal disruptions are achieved, but the time required for complete deployment increases

Engineering Contradiction:
Improveseamlessness of transition and minimal disruptionsVSAvoidtime required for complete deployment
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system dynamically adjusts traffic distribution ratios between microservice versions based on real-time performance monitoring. The service graph enables flexible, adaptive traffic routing that can accelerate or decelerate the transition pace according to observed system behavior, optimizing both transition smoothness and deployment speed rather than following a fixed timeline

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The deployment system changes traffic volume parameters gradually in controlled increments, shifting the proportion of network traffic directed to new versus old microservice versions. This parameter-based control allows precise management of transition speed and smoothness, balancing deployment time against transition reliability

Inventive Principle:
Principle #35Parameter changes

3Manufacturing precision

If performance metrics are closely monitored to determine deployment success, then deployment quality is improved, but the complexity of metric collection and analysis increases

Engineering Contradiction:
Improvedeployment qualityVSAvoidcomplexity of metric collection and analysis
Core Design Contradiction:
Manufacturing precisionVSDevice complexity

Solution Approach 1:

The service graph performs multiple functions simultaneously: it monitors performance metrics, compares versions, determines deployment success, and triggers traffic redistribution. This multi-functional approach consolidates what would otherwise be separate complex systems into a single unified platform, reducing overall system complexity while maintaining high deployment quality

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

Solution Approach 2:

The system automatically collects, analyzes, and interprets performance metrics without requiring external manual analysis. The service graph self-services by comparing metrics between versions, determining whether deployment goals are met, and autonomously initiating traffic redistribution decisions, eliminating the need for complex manual metric analysis processes

Inventive Principle:
Principle #25Self-service

Data Source

PatentEP3739812B1Using service graphs to compare performance of a plurality of versions of a microservice
Publication Date: 2022.10.19 CITRIX SYSTEMS INC
  • EP3739812B1 patent drawingFigure 1A
  • EP3739812B1 patent drawingFigure 1B
  • EP3739812B1 patent drawingFigure 1C

AI summary

Described embodiments provide systems and methods for using service graphs to compare performance of a plurality of versions of a microservice. A device may establish metrics from execution of a plurality of versions of a microservice of a service. The plurality of versions of the microservice are deployed concurrently for a portion of execution of the service. The device generates service graphs for each version of the plurality of versions of the microservice. The service graphs include metrics from monitoring execution of a respective version of the microservice. The device identifies differences in metrics between the service graphs for different versions of the microservice. The device requests a change in network traffic of the service between respective versions of the microservice based at least on the one or more differences.