ADC Configuration via Desired State API

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

In microservices environments, maintaining an up-to-date application delivery controller (ADC) configuration is challenging due to the rapid pace of microservices deployments, leading to resource-intensive synchronization processes that are not scalable.

Innovation Solution

Implementing a desired state API on the ADC allows for instantaneous updates of the configuration, enabling the controller to manage microservices instances by identifying endpoint information, communicating changes to packet engines, and updating configurations accordingly, thereby simplifying the design and improving scalability.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional configuration synchronization approaches are used to keep ADC configuration up to date with microservices deployments, then configuration accuracy is maintained, but resource consumption increases and scalability deteriorates

Engineering Contradiction:
Improveconfiguration accuracyVSAvoidscalability
Core Design Contradiction:
ReliabilityVSProductivity

Solution Approach 1:

Instead of having the ADC actively synchronize with the microservices controller (traditional approach), the invention inverts the approach by having the controller push configuration updates to the ADC via desired state API. This inversion eliminates the need for continuous polling and state comparison at the ADC, reducing resource consumption while maintaining configuration accuracy.

Inventive Principle:
Principle #13The other way round (Inversion)

Solution Approach 2:

The invention extracts the configuration synchronization burden from the ADC by implementing a desired state API that receives configuration directives from the controller. This separates the synchronization logic from the ADC, allowing the ADC to focus on traffic management while the controller handles configuration updates, improving scalability.

Inventive Principle:
Principle #2Taking out (Extraction)

2Reliability

If traditional configuration synchronization approaches are used, then configuration accuracy is maintained, but system complexity and resource intensity increase

Engineering Contradiction:
Improveconfiguration accuracyVSAvoidsynchronization process complexity
Core Design Contradiction:
ReliabilityVSDevice complexity

Solution Approach 1:

The desired state API enables the ADC to receive configuration updates in a self-service manner from the controller. The ADC maintains its configuration state by accepting desired state directives from the controller through the API, eliminating complex bidirectional synchronization mechanisms and reducing overall system complexity.

Inventive Principle:
Principle #25Self-service

3Reliability

If ADC configuration is updated at the rate of microservices changes, then configuration currency is improved, but resource consumption increases

Engineering Contradiction:
Improveconfiguration currencyVSAvoidresource consumption
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The controller performs preliminary actions by preparing configuration updates in advance and pushing them to the ADC via the desired state API before the ADC would need to query for changes. This preliminary action ensures configuration currency matches microservices deployment rate without requiring continuous active synchronization, reducing resource consumption.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS11057271B2Systems and method updating ADC configuration with intended state using desired state API
Publication Date: 2021.07.06 CITRIX SYSTEMS INC
  • US11057271B2 patent drawing
  • US11057271B2 patent drawing
  • US11057271B2 patent drawing

AI summary

Described herein are systems and methods for updating configuration of a device based on changes to microservices. A device may receive a request via a desired state application programming interface (API) to update a configuration of the device to manage a desired set of instances of microservices. The device may identify from the request, a first set of endpoint information for each instance of a microservice in the desired set of instances of microservices. The first set of endpoint information may include an internet protocol (IP) address and port of an endpoint of a respective instance of the microservice. The first set or second set of endpoint information may include a weight for each instance of the microservice.