About ambient mesh

Check out the following video to see ambient mesh in action.

What is ambient mesh?

Solo collaborated with Google to develop ambient mesh, a new “sidecarless” architecture for the Istio service mesh. This architecture reduces the complexity of adopting a service mesh. You no longer have to inject a sidecar into your apps. But, you still get the benefits of Istio, such as secure mutual TLS (mTLS) for pod-to-pod communication.

Ambient mesh removes the sidecar from each pod for your apps. Instead, Istio uses node-level ztunnels to route Layer 4 traffic between apps. Waypoint proxies enforce Layer 7 traffic policies whenever needed. To onboard apps into the mesh, you simply label the namespace the app belongs to. Because no sidecar must be injected, you don't need to worry about restarting or reconfiguring your apps. Your apps automatically become part of the ambient mesh.

What is the difference between a sidecarless and sidecar architecture?

You might wonder if you should use a sidecar or sidecarless architecture. Your approach depends on the requirements that your apps need to meet. These requirements include security, visibility, and lifecycle operations. Let's take a look at the benefits each architecture offers.

For detailed information about ambient mesh, see this Istio blog. For an example of how routing works in a sidecarless vs. sidecar service mesh architecture, see Architecture.

Sidecarless architecture

The sidecarless architecture means that you do not need a sidecar in the same pod as your app. Communication between pods is still secured via mutual TLS (mTLS). This approach reduces your lifecycle operations in several ways, including:

• Fewer cluster resources to run your workloads
• Easier onboarding with no app configuration changes
• Simpler lifecycle operations by not having to restart the app

By default, ambient mesh routes traffic over Layer 4 of the OSI networking stack. Waypoint proxies are used for Layer 7 only when needed. This networking approach also reduces complexity, including:

• Simpler service mesh architecture
• Smaller risk of CVEs on Layer 4 vs. Layer 7
• Greater network performance in the service mesh

Sidecar architecture

A sidecar architecture, on the other hand, uses sidecars that run in each app's pod. This approach gives several security benefits, such as:

• Stronger pod identity that enforces mTLS encryption per pod
• Reduced vulnerability surface, because any compromise impacts only that app

Network traffic is always on Layer 7 of the OSI networking stack. This way, you get greater visibility into the service mesh to help with things such as:

• Detecting bottlenecks
• Troubleshooting issues
• Improving workload parameters, such as resource requests and limits

Why ambient and Gloo Mesh Enterprise?

Running ambient workloads in Gloo Mesh provides the following benefits:

• Support for any CNI: You can run Gloo Mesh in ambient mode on any CNI, such as Cilium, Calico, or cloud provider-specific CNIs.
• Waypoint proxy lifecycle management: Gloo Mesh manages the entire lifecycle of the waypoint proxy for you. If you create a policy or routing rule that requires a waypoint proxy, the proxy is automatically created for you and tied to the service account of your app.
• Multitenancy and zero trust with Gloo workspaces: Organize cluster resources for different teams and tenants with Gloo workspaces. You can enable service isolation for ambient workloads so that services in one workspace cannot communicate with services in another workspace.
• Observability with the Gloo UI and built-in Prometheus: Get instant access to L4 and L7 metrics for ambient workloads and visualize them with the Gloo UI. Metrics are automatically collected by the ztunnels and waypoint proxies, and are scraped by the built-in Prometheus server. You can run PromQL queries in Prometheus to analyze the metrics and monitor the traffic in your ambient mesh.
• Protect ambient workloads with Gloo traffic policies: Apply advanced traffic policies, such as fault injection, outlier detection, failover, rate limiting, and more to ambient workloads in your cluster. Gloo automatically translates these policies into Istio resources so that they can be enforced via the waypoint proxies.
• Central management with Gloo: Ambient mesh is fully integrated into the Gloo Platform stack. With the Gloo management server, you can manage resources in multiple clusters in a single place. This significantly reduces management overhead and simplifies troubleshooting resources across clusters.

For a full list of supported features, see Supported features.