 Welcome to the conference. My name is Justin Pettit and I'm a senior staff engineer at Google. I work on Istio and Google Service Mesh offerings. One of the most exciting projects in recent memory for Service Mesh is the Ambient Mesh data plane which we launched last year. Ambient Mesh brings the traffic management, security, and observability of Istio in a sidecarless model that makes it easier, safer, and cheaper to deploy Service Mesh. Across a cluster, Ambient Mesh uses less memory and CPU than sidecars. It is also no longer necessary to make complicated resource reservation calculations which makes Istio easier to deploy and it frees up node level resources since each pod doesn't need to allocate a proxy to handle its potential peak usage. This translates directly into cost savings of 90% or more. Keep in mind this slide shows a small three node deployment so the dollar amount will be quite substantial at a larger scale. Here we see a traditional Kubernetes network with a CNI and a few pods running on two nodes. With a sidecar data plane, we would need to modify the pod specification and restart the pod for each workload that participates in the mesh. With Ambient Mesh, we replace the sidecar with a node level component that handles the Zero Trust MTLS encryption, L4 policies, and observability. Workloads that wish to participate in the mesh are left unmodified and their traffic is simply redirected through this component. At the time of the Ambient announcement, we created a reference implementation in Rust called Ztunnel. This was done to make a fairly portable implementation that could be integrated with many existing CNIs. When L7 policies are used, the L4 component securely redirects traffic through a waypoint proxy, which is a full proxy that can handle the L7 requirements of Istio. Similar to the L4 component, the Ambient Reference Implementation provides an envoy-based waypoint proxy deployed in its own pod to handle L7 policy enforcement. The waypoint proxy is deployed in the customer's cluster and managed by Istio. While an improvement on traditional sidecars for many users, it still introduces another layer that must be managed and provisioned. While this is a great way to deploy Ambient, we've always had in mind that this Ztunnel functionality could be baked into new enhanced CNIs. This brings a number of benefits, fewer moving pieces, fewer redundant resources, and a cleaner integration, since there can be overlap between CNI and Istio functionality such as service resolution. Some work has already begun to add this functionality to existing popular CNIs to allow them to integrate with Ambient Mesh. We imagine a future with a clearly defined Ambient L4 interface to allow multiple implementations to interoperate. We will similarly define a standard interface for securely connecting to waypoint proxies to allow alternative implementations. One could imagine alternative waypoint proxy implementations with custom functionality and scaling mechanisms that could even run as managed load balancers that run outside the customer's cluster. As you can see, there's been a lot of exciting discussion around Ambient Mesh and its components, Ztunnel and Waypoint Proxy. These are really just a reference implementation. It's a good option to deploy Ambient Mesh for existing Kubernetes deployment, but it's still another layer users must manage. We envision a future with different interoperable implementations and Ambient becomes a design pattern for service mesh as opposed to simply a discreet set of components. These alternative components that we've been discussing, an enhanced CNI with Ztunnel functionality and a managed waypoint proxy, mere existing components in most cloud providers. By extending the capabilities of the CNI and making use of a managed load balancer, we can provide Istio Ambient Mesh without introducing a new layer for the user to manage. It becomes the responsibility of the cloud provider to maintain and scale the service mesh so users can focus on building their applications. Finally, we expect even greater resource savings because Ambient can leverage the provider's resources instead of them being deployed as part of the cluster. I hope this presentation has given you a glimpse at some of the exciting plans we have for Ambient Mesh going forward. Thank you and enjoy the conference.