Sidecar Proxy Gateway for Multi-Cloud Microservice Connectivity
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Connecting microservice workloads across heterogeneous environments, such as AWS, Azure, and private data centers with different deployment types like containers, virtual machines, and bare metal, is complex and often requires infrastructure involvement, limiting the use of best-in-class APIs.
Innovation Solution
Deploying a sidecar proxy agent with each microservice workload to establish direct or indirect tunnels through a constellation server for secure, global reachability and microservice discovery, using a reachability controller and ISTIO component for traffic management and authentication.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If microservice workloads are deployed across heterogeneous cloud environments (AWS, Azure, GCP, private data centers) with different deployment types (containers, virtual machines, bare metal), then applications can leverage cloud provider-specific APIs and improve scalability, but connecting these workloads becomes complex and requires infrastructure involvement
Solution Approach 1:
The patent introduces a service mesh infrastructure with proxies (sidecars) deployed alongside each microservice workload and a central control plane as an intermediary layer. This mediator abstracts the complexity of heterogeneous cloud connections by providing a unified interface for service discovery, traffic management, and security policies across AWS, Azure, GCP, and private data centers, eliminating the need for direct infrastructure-level connection management between workloads
2Reliability
If traditional infrastructure-based connectivity is used for microservices across multiple clouds, then secure connections can be established, but development time increases and best-in-class cloud APIs cannot be fully leveraged
Solution Approach 1:
The service mesh enables microservices to self-configure and self-manage their connectivity through automated service discovery and policy enforcement. Each workload's sidecar proxy automatically establishes secure connections, manages authentication credentials, and enforces security policies without requiring manual infrastructure configuration or developer intervention, thus maintaining security while accelerating development
3Reliability
If a service mesh with sidecar proxies is deployed alongside each microservice workload, then end-to-end secured connectivity and global reachability are enabled between microservices, but the system architecture becomes more complex
Solution Approach 1:
The patent segments the security and connectivity functionality into independent sidecar proxies deployed alongside each microservice workload. Each sidecar handles authentication, encryption, and traffic management for its associated service independently, allowing security to be enforced at the service level rather than requiring a monolithic complex security infrastructure. This modular segmentation manages complexity by distributing security functions across multiple simple, standardized components
Data Source
Figure 1
Figure 2
Figure 3
AI summary
A method includes, in a constellation of clients including a first client and a second client, receiving, at the first client, a connection request from the second client, retrieving endpoint reachability data associated with the second client and transmitting, to a server, a connection request based on the endpoint reachability data. The first client receives, from the server and based on the connection request, endpoint reachability information associated with the second client and starts a bidirectional connection with the second client. A direct or indirect tunnel is established between the first client and the second client. The tunnel is set up based on a table which maps a first connectivity option associated with the first client to a second connectivity option associated with the second client to determine whether to establish the direct tunnel or the indirect tunnel between the first client and the second client.