When you are running microservices you are dealing with multiple services that somehow have to communicate with each other. A microservice can run anywhere in your landscape and doesn’t have a fixed IP address and port number. This seems complex. How do I know where my services are running and how can a service communicate with another service? In this article we will take a look at service discovery.
There are two types of service discovery from which you can choose. Each mechanism has it’s own advantages and disadvantages. Depending on the requirements one might fit better than the other. However, it is possible to mix the two types in your landscape. This makes it possible to make a default choice and then choose the other one when requirements dictate.
Client Side Discovery
With Client Side Discovery the client has the responsibility to find out where it can find the other service. The idea is that every service in the landscape announces it’s presence or is registered by other means in a central registry (see figure below).
Any service can contact the registry to find out where another service can be found.
Direct communication between Service A and B. This setup needs fewer components in your network. Another advantage of client side discovery is that it is reasonably easy to make service B high available. The service is available as long as there is at least one entry in the registry.
Client has to have knowledge of the service registry. This makes higher coupling between the client and the registry and therefore harder to change when you want to switch to another registry. It also means that every service needs to have some code to communicate with the registry. When creating a library, you have to create and maintain a library for every language you use with your microservices.
Server Side Discovery
With Server Side Discovery the responsibility of resolving the right service is delegated to the server side. This means that the client does not need to know how to find a service. The client only needs to know where it can find the router for the service and this router needs to be a stable address. The router can be either a single router for all service types or a router per service type.
The router needs to know where the services are located. This can either be via the Service Registry as with the client side discovery, or services can register with the router. In the picture below we use the service registry.
The client doesn’t need to know anything about a service registry. It doesn’t even have to know that there are multiple different instances of a service. It simply needs to connect to a router which has a stable address. This greatly simplifies the code. Another advantage of using a central router is that you have more control over the traffic. This allow you to implement things like A/B testing or canary releases.
The disadvantage of server side discovery is that router is an extra component in your infrastructure which has to be maintained. Cloud services like Amazon offer load balancers which you can use. If you are using your own infrastructure you have to make sure that the router is configured to be highly available. Not only running multiple instances, but also making sure that the IP is always available. This means that you have to configure Virtual IPs. This all adds to the complexity of your infrastructure. Using a router also means that every request is suffering from an extra network hop and introduces more latency.