Service Discovery

Automatically detect new services to improve performance.

The Challenge

Service discovery is important but hard. Microservices constantly communicate with instances of other microservices, intensifying the volume and frequency of communications.

The Solution

Grey Matter's service-level visibility and telemetry improves service inventory and dependency analysis.

How It Works

The Grey Matter Control server supports several service discovery options and platforms.

  • Control performs service discovery in the mesh and acts as the Envoy xDS server to which all proxies connect.

  • Service discovery lets services communicate transparently with a member of a cluster without knowing its identity, or even how many members there are.

  • When a service joins or leaves the cluster, it joins or leaves the load-balancing list.


Grey Matter supports *several service discovery implementations, with more to come. These include a central server or servers that maintain a global view of addresses (Kubernetes keeps this central server), and clients that connect to the central server to update and retrieve addresses.

*Except for flat-file cases; we farm out that functionality to some other service discovery system.

Service discovery is arguably the first piece of infrastructure you should adopt when moving to microservices.

When choosing your service discovery architecture, consider the following:

  1. What is the best strategy for deploying service discovery clients?

  2. What types of resources and services will you ultimately want to address in your service discovery system?

  3. What languages and platforms need to be supported?

Regardless of your choice, the implementation of an automated, real-time service discovery solution will simplify your microservices architecture.

Here is a short explanation of the workings of each of our service discovery implementations.


Grey Matter's Kubernetes service discovery scheme keeps track of labels placed on pods when they're deployed. Our software uses the Kubernetes API to ask "what pods are in this namespace?" Then we use the labels to match those pods to "clusters", so services can talk to other services just by saying "send this request to some instance of this cluster". When pods die, they get removed from Kubernetes' service discovery list, and therefore from our software's list of running instances for a cluster.


For existing infrastructures already using Consul, you can easily configure Grey Matter to discover services from the existing catalog without migration to Kubernetes or any other platform. Infrastructures with services running in heterogeneous environments, or looking to leverage features such as health checking, load-balancing, or distributed service configuration management can use Consul as a central service registry from which Grey Matter will discover.


Many cloud infrastructure use Envoy's Cluster Discovery Service (CDS) or Endpoint Discovery Service (EDS) to keep track of instances and upstream clusters. Since Grey Matter Control uses xDS as the configuration discovery mechanism, Grey Matter inherits all Envoy configs. Moreover, any Grey Matter proxy can act as a vanilla Envoy proxy instance, and any Envoy proxy can integrate with Grey Matter Control.


We also support service discovery for flat-file cases.

We are always working on new implementations for service discovery! Contact us to discuss your implementation requirements.


Grey Matter monitors cloud-native environments in real-time. Grey Matter can detect and address meaningful conditions in seconds.



Service Registry

Grey Matter's service registry tracks all running services and their health status to organize a dynamic microservice environment.

Service Registration

The service registry registers and deregisters all service instances using self-registration, or third-party registration (where another system component manages the registration of service instances).

Health Checks

Health checks find running nodes and services that can't handle requests. A service that has a health check API endpoint returns the health of the service. The API endpoint handler performs various tests, such as:

  • Status of connections to the infrastructure services used by the service instance

  • Status of the host, such as disk space

  • Application-specific logic

A service registry or load balancer routinely invokes the endpoint to check the health of the service instance. A service instance failure generates an alert and subsequent requests route to healthy instances.

Multi Datacenter

Grey Matter supports multiple datacenters out of the box with no complicated configuration. Look up services in other datacenters or keep the request local. Advanced features like Prepared Queries enable automatic failover to other datacenters.

DNS Query Interface

Grey Matter does not use DNS for service discovery, though nothing we do precludes doing so. Service discovery using a built-in DNS server helps existing applications integrate, as almost all applications support using DNS to resolve IP addresses. Using DNS instead of a static IP address allows services to scale up/down and route around failures easily.

HTTP API with Edge Triggers

Grey Matter provides an HTTP API to query the service registry for nodes, services, and health check information. The API also supports blocking queries, or long-polling for any changes. This allows automation tools to react to services being registered or health status changes to change configurations or traffic routing in real time.

Have a question about how Grey Matter performs service discovery? Contact us to discuss your specific use case.