Difference between Cloud DNS and Service Directory

Is there any difference between Service-Directory and Cloud DNS?

 

The way I understand it (so please, correct me if I am wrong):

Technically both don't have much difference, the only thing is that Service Directory seemingly has the benefit of more-fine-grained control of permission & access (especially in hybrid/multi-cloud landscape)

 

Any comment or input is highly appreciated, thanks for any enlightenment in advanced!

 

Best Regards,

Wai Keat

Solved Solved
1 3 757
1 ACCEPTED SOLUTION

If we look at the home page for Service Directory: https://cloud.google.com/service-directory and compare that to the the home page for Cloud DNS: https://cloud.google.com/dns we start to see the significant distinction between the two.  I'd encourage you to review the two links above.  At the highest level, service directory is a Google service where services that you manage/own can be registered for lookup.  Think of a service as an application or API capable of doing something for your solutions or business.  For example, if we look at this current web-site, it may have an internal service for "member lookup" which could be called by the web page to find the icon for my profile picture.  This would be an example of a service that could be registered in service directory.  It may be given a logical name such as "PictureLookup".  The service may have meta data such as who owns it, what versions are available, what APIs does it expose and many more.  The value of service directory is to allow programmers (and applications) to lookup services for use.   When a service is identified for use, it will likely have a location where it exists that should be used to invoke it.  This might be http://profile-picture-lookup.prod.mycompany.com .... when computers need to connect to a service, they need the IP address of that service.  Trying to remember and work with IP addresses is not sensible because we can't remember that 1.2.3.4 is server A and 1.2.3.5 is server B.  Instead, we need a catalog that allows us to map from "human" consumable names to the IP addresses.  This is where DNS comes into play.  DNS allows us to map server names to IP addresses.  Google's Cloud DNS provides the management of mapping of names to IP addresses that you own.  For example, if you own the domain name "mycompany.com", if you expose a machine with IP address 1.2.3.4 and want that to be "known" as "myserver", then you would use a product such as Cloud DNS to own the mapping to myserver.mycompany.com

View solution in original post

3 REPLIES 3

If we look at the home page for Service Directory: https://cloud.google.com/service-directory and compare that to the the home page for Cloud DNS: https://cloud.google.com/dns we start to see the significant distinction between the two.  I'd encourage you to review the two links above.  At the highest level, service directory is a Google service where services that you manage/own can be registered for lookup.  Think of a service as an application or API capable of doing something for your solutions or business.  For example, if we look at this current web-site, it may have an internal service for "member lookup" which could be called by the web page to find the icon for my profile picture.  This would be an example of a service that could be registered in service directory.  It may be given a logical name such as "PictureLookup".  The service may have meta data such as who owns it, what versions are available, what APIs does it expose and many more.  The value of service directory is to allow programmers (and applications) to lookup services for use.   When a service is identified for use, it will likely have a location where it exists that should be used to invoke it.  This might be http://profile-picture-lookup.prod.mycompany.com .... when computers need to connect to a service, they need the IP address of that service.  Trying to remember and work with IP addresses is not sensible because we can't remember that 1.2.3.4 is server A and 1.2.3.5 is server B.  Instead, we need a catalog that allows us to map from "human" consumable names to the IP addresses.  This is where DNS comes into play.  DNS allows us to map server names to IP addresses.  Google's Cloud DNS provides the management of mapping of names to IP addresses that you own.  For example, if you own the domain name "mycompany.com", if you expose a machine with IP address 1.2.3.4 and want that to be "known" as "myserver", then you would use a product such as Cloud DNS to own the mapping to myserver.mycompany.com

Hi Kolban,

 

Thanks for the detailed explanation! I would certainly read more on it.

 

Meanwhile, based on what you explained, can you help me to see if my summarization below is accurate when I put it this way?


"Service Directory let others know such Services/Endpoints exist; Cloud DNS... well...do the usual DNS stuff (i.e allowing others know what is the IP that mapped to the name of such Services/Endpoints)"

Howdy WaiKeat,

That feels like a good summary to me ... I think the first link and this one to Google's Blog Announcement for Service Directory are alternative summaries ... https://cloud.google.com/blog/products/networking/introducing-service-directory

But it feels like you have the core.