
Service Directory: Manage all your services in one place at scale - tomweingarten
https://cloud.google.com/blog/products/networking/introducing-service-directory
======
csears
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.

~~~
pas
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](https://cloud.google.com/service-
directory/docs/overview)

------
gyre007
am I reading this wrong or is this really "just" some sort of "private" DNS
zone management for your services?

~~~
stingraycharles
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.

~~~
zxienin
It’s a mistake to assume anything free on hyperscalers like GCP. Even ones
with free tag. A _future_ price tag needs to be baked into your _current_
designs.

Case in point, recent pricing change of GKE cluster management fee.
([https://news.ycombinator.com/item?id=22485625](https://news.ycombinator.com/item?id=22485625))

------
zxienin
sounds pretty close to OSB [1][2]

So, does this replace or complement (open) service broker?

[1] [https://github.com/GoogleCloudPlatform/gcp-service-
broker](https://github.com/GoogleCloudPlatform/gcp-service-broker)

[2]
[https://www.openservicebrokerapi.org](https://www.openservicebrokerapi.org)

~~~
alpb
Not quite. OSB actually is more like "I need a mysql database, give me one, I
don't care about the implementation". This is more like service discovery. The
GCP OSB-like solution nowadays is
[https://cloud.google.com/blog/products/containers-
kubernetes...](https://cloud.google.com/blog/products/containers-
kubernetes/config-connector-bridges-kubernetes-gcp-resources)

------
mooneater
Can someone map this to AWS? Im pretty sure its not related to AWS Directory
Service!

~~~
politelemon
It feels like AWS Cloud Map, their service discovery solution:
[https://aws.amazon.com/cloud-map/](https://aws.amazon.com/cloud-map/)

I've used it by way of ECS Service Discovery which lets you register a
container as 'hub.local' or 'xyzparser.svc' for example

------
jl6
“All your X in one place” is snake oil vendor lock-in dressed as convenience.

N.B. I have no opinion on Service Directory. It may be a great tool. I just
object to the pitch in the headline

