Service Directory: Manage all your services in one place at scale (opens in new tab)

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

From tfa: > Customers can use Service Directory to register different types of services and resolve them securely over HTTP and gRPC. For DNS clients, customers can leverage Service Directory’s private DNS zones, a feature that automatically updates DNS records as services change.

So it's a db with dns, http and grpc interface. But why? Are there any grpc or rest clients that do not speak dns? Wouldn't it be simpler to just use dns?

Ed: missed the resolve them securely part. AFAIK there's isn't really any viable secure dns (for the same value of secure that https/http2 provides). So seems dns is more of a fallback (and maybe bootstrap) thing?

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.

That’s how most service directories work.

We had to write something running on Google AppEngine and backed by Google Datastore to do exactly that. We canned Global Service Registry or GSR. Could have used this if it was available 3 years ago!

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

It feels like AWS Cloud Map, their service discovery solution: 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