Cloud Proxy Sidecar Coalescence for Lower Resource Consumption

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Sidecar proxies in cloud-native applications increase complexity, resource consumption, and latency, particularly in applications with many microservices or limited resources.

Innovation Solution

Combine multiple Envoy-based sidecars into a single sidecar by analyzing their functionality and configuration data, resolving conflicts, and deploying the merged sidecar in a Kubernetes environment.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If multiple sidecar proxies are deployed alongside microservices, then functionality such as service discovery, load balancing, security, and traffic management is provided, but device complexity and ease of operation deteriorate due to increased management overhead

Engineering Contradiction:
ImprovefunctionalityVSAvoidmanagement complexity
Core Design Contradiction:
Adaptability or versatilityVSDevice complexity

Solution Approach 1:

The patent combines multiple sidecar proxy instances into a single unified sidecar proxy that serves multiple microservices. This consolidation merges the functionality of multiple proxies (service discovery, load balancing, security, traffic management) into one instance, reducing the number of managed components while maintaining comprehensive functionality across the microservice architecture

Inventive Principle:
Principle #5Merging (Combining)

2Adaptability or versatility

If multiple sidecar proxies are deployed, then comprehensive functionality is provided, but resource consumption increases due to additional CPU, memory, and network bandwidth usage

Engineering Contradiction:
ImprovefunctionalityVSAvoidresource consumption
Core Design Contradiction:
Adaptability or versatilityVSUse of energy by moving object

Solution Approach 1:

Multiple sidecar proxy instances are merged into a single unified proxy that handles traffic for multiple microservices. This consolidation reduces total resource consumption by eliminating duplicate processes, shared libraries, and infrastructure overhead associated with running multiple separate proxy instances, while maintaining the same comprehensive functionality through shared code and configuration

Inventive Principle:
Principle #5Merging (Combining)

Solution Approach 2:

The unified sidecar proxy is designed to perform multiple functions simultaneously - serving multiple microservices, providing service discovery, load balancing, security authentication, authorization, encryption, audit logging, rate limiting, retry logic, and protocol translation. This multi-functionality allows a single proxy instance to replace what previously required multiple specialized proxies, reducing overall resource consumption

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

3Adaptability or versatility

If multiple sidecar proxies are deployed, then comprehensive functionality is provided, but latency increases due to additional processing hops

Engineering Contradiction:
ImprovefunctionalityVSAvoidlatency
Core Design Contradiction:
Adaptability or versatilityVSLoss of time

Solution Approach 1:

By merging multiple sidecar proxies into a single unified instance, the patent eliminates the need for traffic to hop between multiple proxy processes. The unified proxy can handle requests for multiple microservices in a single processing pass, reducing the cumulative latency that would otherwise accumulate across multiple proxy boundaries and inter-process communications

Inventive Principle:
Principle #5Merging (Combining)

Data Source

PatentUS12386612B2Cloud proxy-based sidecar coalescence
Publication Date: 2025.08.12 DELL PROD LP
  • US12386612B2 patent drawing
  • US12386612B2 patent drawing
  • US12386612B2 patent drawing

AI summary

The technology described herein is directed towards combining multiple sidecar (e.g., Envoy-based) proxies into a single sidecar or reduced number of sidecars for use in association with a service. Described is identifying sidecars for merging, grouping by version compatibility, and determining their functions and configuration data. Any conflicts in the configuration data are resolved. A merged sidecar is built by combining functional code and configuration data. The merged sidecar is deployed along with its relevant service, e.g., deployed as a container in a Kubernetes environment. The merging facilitates reduction of resource utilization by having only a merged sidecar, instead of multiple sidecars, support a service.