Service Directory is generally available: Simplify your service inventory

Enterprises are increasingly adopting a service-oriented approach to building applications, composing several different services that span multiple products and environments. For example, a typical deployment can include:

• Services on Google Cloud, fronted by load balancers

• Third-party services, such as Redis

• Services on-premises

• Services on other clouds

As the number and diversity of services grows, it becomes increasingly challenging to maintain an inventory of all of the services across an organization. Last year, we launched Service Directory in beta to help simplify the problem of service management, and it’s now generally available. Service Directory allows you to easily register these services to a single fully managed registry, build a rich ecosystem of services, and uplevel your environment from an infrastructure-centric to a service-centric model.

Simplify service naming and lookup

With Service Directory, you can maintain a flexible runtime service inventory. Some of the benefits of using Service Directory include:

• Human-friendly service naming: Customers can associate human-readable names with their services in Service Directory, as opposed to autogenerated default names. For example, your payments service can be called payments, instead of something like service-b3ada17a-9ada-46b2, making it easier to reference and reason about your services

• Enrich service data with additional properties: In addition to control over names, Service Directory also allows you to annotate a service and its endpoints with additional information beyond names. For example, new services can be given an experimental annotation until they are ready for production, or be given a hipaa-compliant annotation if they are able to handle PHI. Customers can also filter services based on their annotations; for example, if you have services using multiple types of weather data, you can annotate those data sources with fields like sunnyvale-temp, sunnyvale-precipitation, and paloalto-temp. You could then use Service Directory’s query API to find services using only Sunnyvale weather data, by searching for all services annotated with sunnyvale-temp or sunnyvale-precipitation, but not paloalto-temp.

• Easily resolve services from a variety of clients: Service Directory allows you to resolve services via REST, gRPC, and DNS lookups. In addition, Service Directory’s private DNS zones automatically update DNS records as services change, instead of needing to manually add DNS entries as you add new services.

• Fully managed: Service Directory is fully managed, allowing you to maintain your service registry with minimal operational overhead.

New: automatic service registration

In this release, you can now automatically register services in Service Directory without needing to write any orchestration code. This feature is available today for Internal TCP/UDP and Internal HTTP(S) load balancers, and will be extended to several other products going forward. 

Registering services with Service Directory is easy. When you create an Internal Load Balancer forwarding rule, register it with Service Directory by specifying a --service-directory-registration flag with the name of the Service Directory service you want your load balancer to be registered in. This automatically creates a Service Directory entry for your ILB service, and populates it with data such as the forwarding rule’s IP and port. When you delete the forwarding rule, the Service Directory entry is automatically removed as well, without needing to write any cleanup or teardown code.

To learn more about Service Directory, visit the documentation, or walk through the configuration guide to get started.