DNS

Service discovery with DNS

Let’s start with the basics and look at DNS. For small teams this is likely to be our best choice, particularly in a slowly changing infrastructure. That would include dedicated physical machines and dedicated, long-lived virtual machines. In these environments, IP addresses will remain stable enough for DNS to be useful.

Service discovery usually implies some kind of automated query and response, but not in this case. When we use DNS to call another service, discovery is more Sherlock Holmes than Siri. Our team needs to find the service owners and pry the DNS name or names out of them. An exchange of favors may be required, maybe a six-pack of beer in the extreme. Once we’ve finished the human protocol, we just put the host name into a configuration file and forget about it. When a client calls a service, the provider of that service may only have a single DNS name. That implies the provider is responsible for load balancing and high availability. If the provider has several names, then it’s up to the caller to balance among them.

Logical service name

When using DNS, it’s important to have a logical service name to call, rather than a physical hostname. Even if that logical name is just an alias to the underlying host, it’s still preferable. An alias only needs to be changed in one place (the name server’s database) rather than in every consuming application.

Load balancing with DNS

DNS round-robin load balancing is one of the oldest techniques, dating back to the early days of the web. It operates at the application layer (layer 7) of the OSI stack, but instead of operating during a service request, it operates during address resolution.

DNS round-robin simply associates several IP addresses with the service name. So instead of finding a single IP address for shipping.example.com, a client would get one of several addresses. Each IP address points to a single server. The client therefore connects to one out of a pool of servers, as shown in the figure below.