Scenario: Moving services to the cloud

As an example, let’s say you’re at a company that has been running a payments service on-premises, and uses Traffic Director for traffic management. To simplify operational overhead, you’d like to move this service to Google Cloud and gradually migrate traffic over.

Doing this today requires managing distinct, infrastructure-specific configuration paths. You need to:

• Configure one workflow to make the on-premises service available to Traffic Director
• Configure another workflow to make the Google Cloud service available
• Follow different steps depending on how the Google Cloud service is built (whether it runs on Compute Engine or Kubernetes Engine, for example)

The Service Directory and Traffic Director integration simplifies this, by allowing all of your services, regardless of the infrastructure they are built on, to be configured the same way. No matter whether your services are built on GCE, GKE, on-premises, or other clouds, Traffic Director just needs to know about their entry in Service Directory. In the following sections, we’ll take a look at both Service Directory and Traffic Director, and how they work together to make this happen.

Service Directory: Manage all services from a central place

Service Directory is a central service registry that allows you to manage and track all your services, and their metadata, in one place, whether your services are hosted on Google Cloud, on-premises, or other clouds. Services of all kinds can be registered to Service Directory via an API call. Services fronted by load balancers and those running on Kubernetes Engine can be automatically synchronized to Service Directory, instead of having to manage orchestration around service registration yourself.

Traffic Director: Routing, Load Balancing, and Traffic Management

Traffic Director is Google Cloud’s fully managed traffic control plane for the next-gen managed load balancers as well as open service mesh. With Traffic Director, you can establish a zero-trust security posture along with high visibility into service-to-service communication across GKE clusters and VM instances. Traffic director enables global load balancing in multiple regions, integrates with health checking, and supports a number of advanced traffic management policies such as traffic mirroring for forensics, weight-based traffic splitting for service migration and canary deployments.

Service Directory and Traffic Director

As we saw in the scenario, configuring Traffic Director with a heterogeneous deployment requires you to understand the infrastructure each service is built on. Different types of service infrastructure can each require their own configuration path. Now, you have the option of making Traffic Director work directly with services registered in Service Directory, with one common configuration path for all services for a simplified experience.

The process to do so is simple:

• Register a service, along with its endpoints and annotations in Service Directory. Registration can be done automatically for services fronted by load balancers or running on Kubernetes Engine.
• Create a service binding that binds your Service Directory service to a Traffic Director backend service, using commands like this:

• The service is now available to Traffic Director. Traffic Director can route and apply traffic management policies to this service. In the example below, we are splitting traffic between the Google Cloud and on-premises versions of the payments service in our scenario.
• The service binding process is exactly the same regardless of the technologies the service is built on. All you need to provide is the service’s entry in Service Directory.
• When the service’s endpoint information changes in Service Directory, Traffic Director will automatically be made aware of the new endpoints, without having to be manually reconfigured. Similarly, if the service’s infrastructure changes (for example, if it’s migrated to a different technology), the service binding process remains exactly the same.

Some of the benefits of Service Directory and Traffic Director include:

• Simplified API: Service Directory supports multiple services, such as services running on GKE, fronted by Internal TCP/UDP or HTTP(S) Load Balancers, Private Service Connect, and more. With Service Directory integration, all of these services are represented in Traffic Director with a simplified API construct called Service Binding which abstracts the status-quo granular backend representation from the platform administrator configuring Traffic Director. In the absence of Service Directory integration, that platform administrator needs to worry about different types of backends such as Network Endpoint Groups and Instance Groups depending on your infrastructure setup. The Service Binding API creates a standardized user experience and also helps in establishing clear boundaries between producers and consumers of services in the service mesh.
• Automatic service registration for easy onboarding: As mentioned, many Google Cloud services, like those fronted by load balancers or running on GKE, can be automatically synchronized to Service Directory. This can allow you to quickly onboard services to Service Directory, and in turn to Traffic Director.
• Respond easily to service changes: Service Directory automatically informs Traffic Director of changes in services. For example, if the IP of a service endpoint changes, Service Directory will convey the new state to Traffic Director without needing to reconfigure anything.
• Make more services available to your service mesh: Because a Service Directory registry can contain services from any environment, many more services can be first-class members of your service mesh. This includes cross-organization or managed third party services via Private Service Connect, Google Cloud managed services, as well as on-premises and hybrid services.

To get started with Service Directory and Traffic Director in Preview, check out the documentation.