Service mesh

Learn how you can improve the routing and security for your apps by adding your apps to a service mesh and using an API Gateway to control incoming traffic to the service mesh.

The deployment patterns shown on this page require your apps to be in a service mesh that is managed by Gloo Mesh Enterprise. Gloo Mesh is a multicluster and multimesh management plane that is based on hardened, open-source projects like Envoy and Istio. To implement these deployment patterns, you need a separate license for Gloo Mesh. For more information, see About Gloo Mesh.

What is a service mesh?

A service mesh is a dedicated infrastructure layer that you add your apps to. The service mesh provides central management for your cloud-native microservices architecture. This way, you can optimize your apps in areas like communication, routing, reliability, security, and observability.

For more information, see What is a service mesh?.

What is Istio?

The open source project Istio is the leading service mesh implementation that offers powerful features to secure, control, connect, and monitor cloud-native, distributed applications. Istio is designed for workloads that run in one or more Kubernetes clusters, but you can also extend your service mesh to include virtual machines and other endpoints that are hosted outside your cluster.

For more information, see What is Istio?.

Routing without Gloo Mesh

To understand the benefits of using Gloo Gateway in combination with Gloo Mesh, let's take a look at how high availability for an app works if your apps are not part of a service mesh that is managed by Gloo Mesh.

In this example, a global API Gateway is configured in a separate cluster that serves all traffic for an availability zone. An incoming request for app2.io is load balanced between the clusters where app2 is deployed, and forwarded from the global API Gateway to the API Gateway of each cluster. The Gloo management plane controls the rollout of the API Gateway configuration across clusters to reduce management overhead and the risk of configuration drift.

Figure: High availability and routing example without using Gloo Mesh.

If app2 now wants to send a request to app1 in the same cluster, the request is routed directly to app1. However, if app1 in cluster 1 is not available, the request is routed back to cluster 1's Gloo Gateway, and forwarded to the app1 instance in cluster 2. This setup requires additional network hops and increases network latency, response time, and infrastructure cost.

Figure: East-west routing between clusters without using Gloo Mesh.

Intelligent routing with Gloo Mesh

Now, let's take a look at how Gloo Mesh significantly improves this routing example. By adding your services to a service mesh, the services are automatically discovered across clusters and Gloo Mesh is aware what services are deployed in which cluster. For apps that spread across clusters, you can define unique internal hostnames with Gloo Mesh virtual destinations that apps in the service mesh use to send requests to another app.

To reach a multicluster endpoint, your apps inside the mesh simply send a request to the internal hostname, and Gloo Mesh then routes the request to the desired destination. Your apps do not need to know where the target app is deployed within the mesh. Instead, Gloo Mesh takes into account the context of the client request, such as the client location, where the target app is deployed within the mesh, and the routing rules that you defined to ensure that the request is routed in an efficient and secure manner.

By using locality-based routing, the request from app2 to app1 is first routed to the app1 instance in the same cluster. If this instance is not available, the request is then routed to the instance that is next closest. In addition, traffic between app2 and app1 is secured with mutual TLS (mTLS).

Figure: East-west routing between clusters with Gloo Mesh.

Combining Gloo Gateway and Gloo Mesh Enterprise enables the following benefits: