DNS SRV Record Routing for Service Version Discovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing systems for routing client requests to different versions of a service are inconsistent due to variations in REST APIs across orchestration frameworks, lacking standardization and requiring marshalling, which complicates version discovery and deployment management.
Innovation Solution
The use of DNS SRV records for routing client requests, allowing for universal language agnosticism and unified version discovery and deployment, enabling easier and more consistent management of service versions without significant disruption to client delivery.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If REST APIs are used for service version discovery and deployment management, then version discovery can be achieved, but inconsistency and lack of standardization occur across different orchestration frameworks
Solution Approach 1:
The patent applies DNS SRV records as a universal mechanism that works across all orchestration frameworks and intermediary devices. DNS SRV records provide a standardized way to discover service versions and their endpoints, eliminating the need for framework-specific REST APIs. This universal approach allows any DNS-capable intermediary device to understand and route to multiple service versions consistently.
Solution Approach 2:
The patent introduces DNS SRV records as an intermediary layer between the orchestration framework and the service versions. Instead of directly exposing framework-specific APIs, the system uses DNS SRV records to mediate the discovery process, translating various orchestration frameworks' service version information into a standardized DNS format that all intermediary devices can understand and route accordingly.
2Loss of information
If framework-specific REST APIs are used for deployment discovery, then deployment information can be obtained, but marshalling and standardization issues arise
Solution Approach 1:
DNS SRV records serve as an intermediary that simplifies the information exchange. Instead of complex marshalling of framework-specific deployment information, the system encodes service version endpoints, priorities, and weights directly into DNS SRV record fields. This intermediary format eliminates the need for complex data transformation and marshalling operations while preserving all necessary deployment information.
Solution Approach 2:
The patent transforms deployment information into DNS SRV record parameters such as priority and weight fields. By changing the representation of deployment information from framework-specific objects to standardized DNS record parameters, the system achieves lossless information transfer without complex marshalling, as DNS resolvers natively understand and process these parameters.
3Productivity
If new service versions are deployed, then service updates can be provided, but traffic management and client disruption challenges occur
Solution Approach 1:
The patent uses dynamic DNS SRV record updates to manage service version traffic. When new service versions are deployed, the orchestration framework updates DNS SRV records with the new version's endpoint information, priority, and weight. Intermediary devices dynamically adjust their routing based on these updated DNS records, enabling seamless traffic redistribution to new versions without client disruption. Clients continue to request the same service endpoint, while the intermediary transparently routes to the appropriate version.
Data Source
AI summary
Described embodiments provide systems and methods for routing client requests. A device may be arranged intermediary to a plurality of clients and a domain name system (DNS) controller. The device may generate a query for the DNS controller. The query may correspond to a service to be accessed by the clients. The device may receive, from the DNS controller, a response to the query. The response may include a value used by the device to route respective client requests for accessing the service to a corresponding version of a plurality of versions of the service. The device may receive, from a client, a client request for accessing the service. The device may route the client request to one of the versions of the service according to the value included in the response to manage traffic between various versions of the service.