Service Directory is a service covered by Google's obligations set forthin theCloud Data Processing Addendum.

Service Directory is a single place to publish, discover, and connect toservices in a consistent and reliable way, regardless of their environment.Service Directory supports services in Google Cloud, multi-cloud,and on-premises environments and can scale up to thousands of services andendpoints for a single project.

Service Directory has the following features:

• ARegistration and Lookup API for creating and resolvingnamespaces,services, andendpoints
• Integration withCloud DNS. Service Directory zonesallow services to be made available on Virtual Private Cloud (VPC).
• IAM integration to assign and control servicevisibility and permissions
• Built-inGoogle Cloud CLIandGoogle Cloud consolesupport for interacting with Service Directory
• Cloud Monitoring and Cloud Logging integration for monitoring,auditing, and debugging Service Directory operations

Why Service Directory

As applications adopt services, being able to resolve the location of a servicebecomes more difficult as the endpoints of those services change. Servicesdeployed across hybrid environments present additional obstacles as neither mayshare the same naming system, making resolving and connecting serviceschallenging. To illustrate the problem, consider the following.

Imagine that you are building a simple API and that your code needs to call someother application. When endpoint information remains static, you can hard-codethese locations into your code or store them in a small configuration file.However, with microservices and multi-cloud, this problem becomes much harder tosolve as instances, services, and environments can all change.

With Service Directory, you can register all of your services in a singleplace and resolve them by using HTTP, gRPC, and DNS.

Let us revisit the previous diagram, but this time adding Service Directory.In the following diagram, each service instance is registered with Service Directory.These registrations are immediately reflected in DNS and can be queried by usingHTTP/gRPC regardless of their implementation and environment.

You can create a universal service name that works across Google Cloudproducts, like App Engine and GKE. You can make these servicesavailable over DNS. You can apply access controlsto services based on network, project, and IAM roles ofservice accounts.

Service Directory solves the following problems:

1. Interoperability: Service Directory is a universal naming servicethat works across Google Cloud, multi-cloud, and on-premises.You can migrate services between these environments and still use the sameservice name to register and resolve endpoints.
2. Service management: Service Directory is a managed service.Your organization does not have to worry about the high availability,redundancy, scaling, or maintenance concerns of maintaining your ownservice registry.
3. Access Control: With Service Directory, you can control who canregister and resolve your services using IAM. AssignService Directory roles to teams, service accounts, and organizations.
4. Limitations of pure DNS: DNS resolvers can be unreliable in terms ofrespecting TTLs and caching, cannot handle larger record sizes, and do notoffer an easy way to serve metadata to users. In addition to DNS support,Service Directory offers HTTP and gRPC APIs to query and resolveservices.

Use Cloud DNS with Service Directory

Cloud DNS is a fast, scalable, and reliableDomain Name System (DNS) service running on Google's infrastructure.

In addition to public DNS zones,Cloud DNS also provides a managed internal DNS solution for private networks onGoogle Cloud.Private DNS zones enable you to internally name your virtual machine (VM) instances, loadbalancers, or other resources. DNS queries for those private DNS zones arerestricted to your private networks.

The following diagram illustrates how you can use Service Directory zonesto make service names available using DNS lookups.

Overview of the individual components:

1. The endpoints are registered directly with Service Directory byusing the Service Directory API. You can register bothGoogle Cloud and non-Google Cloud services with Service Directory.
2. Both external and internal clients can look up those servicesat: https://servicedirectory.googleapis.com
3. To enable DNS requests,create a Service Directory zone inCloud DNSthat is associated with a Service Directory namespace.
4. Internal clients can resolve this service by using DNS, HTTP, and gRPC.External clients (clients not on the private network) must useHTTP or gRPC to resolve service names.

Example configuration

How to expose a service over DNS

The following diagram illustrates how a microservice architecture is modeled inService Directory and made available using DNS. Notice that Service Directorymaintains the services and endpoints entirely,but the private zone is in Cloud DNS.

In this diagram (left side), thepayments service is registered to anamespace with the namebackend-namespace, the regionus-east1, and theprojectgcp-project. The namespace is linked to the private zoneexample.com.

To do a DNS lookup, the client requests theSRV record for the domain name_payments._tcp.payments.example.com, whichresolves to the port numbers and address records for the payment service'sendpoints.

What's next

• To learn how to set up a Service Directory namespace, create a servicein the namespace, and assign endpoints to a service, seeConfigureService Directory.
• To learn how to create a Service Directory zone that leverages anan existing namespace, seeConfigure a Service Directory DNSzone.
• To learn how to make a query to an existing Service Directory zone usingDNS, seeQuery using DNS.
• To find solutions for common issues that you might encounter when usingService Directory, seeTroubleshooting.