| This is the very first step toward the glorious service catalog + service broker flow. Whereas Istio is an orthogonal aspect to that. (Istio secures/measures/distributes/provides the network for service-to-service interactions.) This seems more aimed at providing a "private catalog" (really a secure name resolver (gRPC) + load-balancing reverse-proxy) for your well known services (database, message queue, job queue, email in, email out, push notification, SMS, video transcoding, etc.). And while Istio primarily thinks about working withing one k8s cluster, this is primarily a hybrid cloud thing. (On-premise + cloud(s).) Also, Istio currently requires deployment. It injects its own sidecar container into pods. Whereas this thing is a decoupling to allow more flexibility, so you don't need to redeploy/reconfigure every service that depend on some other service when you change/replace that other service. In practice Istio (and other service mesh "platforms") provides a few really nice things (though it has relatively brutal resource needs, after all it has to proxy and process all of your network traffic to be able to provide mutual TLS and load balancing, and monitoring/telemetry and rules). But it does what it does, and in many environments pushing almost every packet through a "firewall" box is already established practice. And so compared to that this Service Directory thing is just a "private DNS zone"-based reverse-proxy to decouple stuff. You still need to manage/configure the upstream services, but ... in theory that can be streamlined later with simply declaring the important parameters as metadata. See also: https://cloud.google.com/service-directory/docs/overview |