Building a Multi-Region Service Mesh

If you're not familiar with BGP and internet routing, ISPs, network operators, and cloud service providers rely on BGP to exchange routing information and determine the shortest path to an IP. As global network routing is not only influenced by technical paramaters but also by business and geopolitical subjects, this might not always be the shortest technical path. Now, the edge knows on which core location the service is located, but it doesn't know on which hypervisor the service is located. Our service mesh is critical in providing a seamless experience on the network: it provides key features including local load balancing, service discovery, and end-to-end encryption. If you're not familiar with service mesh technologies and concepts, we wrote a dedicated post about it Service Mesh and Microservices: Improving Network Management and Observability. When a request reaches the Ingress Gateway of a core location, the Ingress Gateway uses service discovery to locate an Envoy proxy instance running alongside an instance of the requested service. The role of the sidecar is to simplify and secure communications to its attached service by decrypting incoming traffic, encrypt outbound traffic to other services, and provide service discovery capabilities. Zero-Trust network: Securing the Service Mesh connections using mTLS. To secure the traffic between the edge and the core location but also inside of the core location, we use mTLS. mTLS ensures that all connections are:.coming from an authenticated server using a valid certificate.