Service Discovery: Dynamic communication enabler in microservices environments

Where URLs have a complete house

What is Service Discovery?

Service discovery is a pattern or design component that deals with the problem of microservices communication on the network level. It helps you have an abstracted layer of communication from the view of a microservice, and it lets you off the management of URLs in the service’s code. Also, it allows you to have more control on the chat-chat (communication) between microservices and balancing loads too.

Properties of Service Discovery

The following is a list of service discovery properties that help in the trade-offs:

• Adds a layer of abstraction between services in terms of communication
• Centralizes communication among services
• If it fails, services can’t talk to each other, even if they’re up (this happens if there’s no solution in the service code)
• Makes communication between services dynamic, in which you can change a service’s URL without changing other services’ code
• Helps in unifying communication among services since we centralized the communication
• There is always overhead added to each service-to-service communication, by 1, each time we ask for a service

Service Discovery Assumptions & Expectations

When we talk about service discovery, we have to be assuming that:

• We have ≥ 2 services
• They need to talk to each other over network/local calls

If we don’t have both, then SD is meaningless.

The main expectation you should look for when talking about SD is that you expect or need something that manages communication between services over a dynamic link that changes regularly. If you guarantee that the link between services won’t change, you can discard one of the main values of SD.

How Service Discovery Works?

When we dig into the workings of SD, there are two main use cases:

• Client-side SD: where the client asks for the URL to connect to a specific service
• Server-side SD: where the client prompts the SD server to deliver a message to a specific service

Let’s see how each one works visually:

Clinet-side SD

Server-side SD

Service Discovery Use Cases

The use cases where SD is a main component are:

• Microservices communication
• Integrations management

Why Service Discovery?

To justify SD, we should showcase that we have the problem of hard-coded URLs, less flexible communication, or that cloud dynamic URLs can’t be used. So if we encounter one of these problems, we justify SD as:

• A facilitator of communication in environments that have changeable URLs
• Giving control over services’ load balancing and measuring health
• Offloading the maintaining of communication by the application’s code, where devs can just deal with one unified layer of communication