11–15 of 15 posts
Can someone map this to AWS? Im pretty sure its not related to AWS Directory Service!
I've used it by way of ECS Service Discovery which lets you register a container as 'hub.local' or 'xyzparser.svc' for example
So, does this replace or complement (open) service broker?
[1] https://github.com/GoogleCloudPlatform/gcp-service-broker
am I reading this wrong or is this really "just" some sort of "private" DNS zone management for your services?
Yup, and it’s free so seems like a pretty good deal. Only downside I can see is the potential lock-in into the Google Cloud it has, but that’s with most cloud services anyway. EDIT: It’s only free during beta. Would feel better if they gave a price point indication of what this may cost, but sounds like you’ll want to be conservative with the amount of requests you send.
Case in point, recent pricing change of GKE cluster management fee. (https://news.ycombinator.com/item?id=22485625)
sounds pretty close to OSB [1][2] So, does this replace or complement (open) service broker? [1] https://github.com/GoogleCloudPlatform/gcp-service-broker [2] https://www.openservicebrokerapi.org
What's the relationship between this and a service mesh like Istio? Is Service Directory just for external/public clients? Wouldn't most of the changes to service endpoints be hidden behind load balancers? They mention Redis and MongoDB as examples of services that could be discovered through Service Directory, but those seem like they would traditionally be used by internal clients.
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