I enjoyed @timbray "Cloud Traffic" post which highlights the complexity of Kubernetes and service meshes in general. A lot of that complexity is rooted in the flexibility and portability of these platforms. tbray.org/ongoing/When/2…
The talked referenced in Tim's post focused on how to leverage a service mesh without a sidecar proxy using gRPC and Traffic Director. While this setup, on the surface, feels less complex than running something like Istio, it's still too complex.
Traffic Director is a fully managed control plane that supports Envoy's xDS protocol. Traffic Director helps you describe and configure your service architecture. You can set up traffic splitting, fault injection, and even global load balancing. cloud.google.com/traffic-direct…
Ideally with a central fully managed control plane you can focus on the data plane, typically with something like Envoy, which can be configured by Traffic Director. This means services can live across VMs, Kubernetes, and as the talk demonstrated, Cloud Run (Serverless).
Envoy works as an edge loadbalancer. You don't have to mesh if you don't want to. I could also see a world where Traffic Director is used to configure Google managed load balancers. In that case you can just spin up services and leverage a north/south network architecture.
But Tim is asking the right question. Why do we need Traffic Directory, Envoy, and all of this service mesh stuff in the first place?
It's about meeting people where they're at. I would love if everyone could go serverless and leverage managed load balancer and API gateways.
It's about meeting people where they're at. I would love if everyone could go serverless and leverage managed load balancer and API gateways.
We just aren't there yet. Trust me, I've checked. Actually, that's not quite true. Some people are living that Serverless life right now. I bet even more can make it work, but it will require some real changes, both in mindset, and code.
