About ambient mesh

Ambient is an alpha feature. Alpha features are likely to change, are not fully tested, and are not supported for production. For more information, see Gloo feature maturity.

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

What is ambient mesh?

Ambient mesh was initially developed by Solo engineers in collaboration with Google and introduces a new sidecarless architecture that you can leverage in your Istio service mesh. It was developed with the intention to reduce the complexity of adopting a service mesh and remove the risk of injecting sidecars into workloads without losing secure, mutual TLS (mTLS) pod-to-pod communication.

An ambient mesh removes the requirement of running a sidecar alongside each app in your mesh. Instead, you use node-level ztunnels to route Layer 4 traffic between apps, and waypoint proxies to enforce Layer 7 traffic policies whenever needed. To onboard workloads into the ambient mesh, you simply label the namespace the workload belongs to. Because no sidecar must be injected, workloads do not need to be restarted or changed in order to participate in the ambient mesh.

What is the difference between a sidecarless and sidecar architecture?

Deciding between a sidecar and sidecarless architecture for your service mesh is highly dependent on the workloads that are part of the service mesh, and the security, visibility, operational, and management requirements that you have. Istio offers the flexibility to mix different service mesh architectures within the same service mesh so that you can decide what architecture best meets the needs of your app. To understand what architecture fits your workload, 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

With a sidecarless architecture, you secure communication between services via mutual TLS (mTLS) without the need to inject a sidecar into each workload. This approach significantly reduces operational cost and the cluster resources that are required for your workloads, and simplifies the onboarding process of apps into the service mesh as they do not need to be changed or restarted. Furthermore, traffic is routed over Layer 4 of the OSI networking stack by default, and Layer 7 waypoint proxies are used only when needed which can further simplify the service mesh architecture and improve performance in the service mesh.

Sidecar architecture

A sidecar architecture, on the other hand, uses sidecars that run alongside each workload to provide strong pod identity and mTLS encryption to secure the communication between microservices in the mesh. This approach reduces the surface of vulnerability, as compromising a sidecar affects only the app the sidecar belongs to. Because sidecars always operate on Layer 7 of the OSI networking stack, you get L7 visibility into the service mesh traffic. You can use the metrics to detect bottlenecks, troubleshoot issues, or improve workload parameters, such as resource requests and limits.

Why ambient and Gloo Mesh Enterprise?

Running ambient workloads in Gloo Mesh provides the following benefits:

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