Service Directory: Manage all your services in one place at scale

https://cloud.google.com/blog/products/networking/introducing-service-directory

by tomweingarten • 6 years ago

86 14 6 years ago

cloud.google.com

gyre007• 6 years ago

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

jedberg• 6 years ago

That’s how most service directories work.

stingraycharles• 6 years ago

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.

techntoke• 6 years ago

They also have Istio with Kubernetes, so you could use this until you're able to migrate to something more adaptable to other environments.

zxienin2• 6 years ago

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)

ksajadi• 6 years ago

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!

e12e• 6 years ago

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?

csears• 6 years ago

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• 6 years ago

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.

mooneater• 6 years ago

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

politelemon• 6 years ago

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

jl6• 6 years ago

“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

zxienin2• 6 years ago

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

alpb• 6 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...

Service Directory: Manage all your services in one place at scale

Related Stories