Service Discovery = Configuration?
In principle it is conceivable to implement Service Discovery by configuration solutions (see section 7.10). In the end, only the information that service is reachable at which location is supposed to be transferred. However, configuration mechanisms are, in effect, the wrong tools for this. For Service Discovery, high availability is more important than for a configuration server. In the worst case a failure of Service Discovery can have the consequence that communication between microservices becomes impossible. Consequently, the trade-off between consistency and availability is different compared to configuration systems. Therefore, configuration systems should be used for Service Discovery only when they offer an appropriate availability. This can have consequences for the necessary architecture of the Service Discovery system.
There are many different technologies for Service Discovery:
- • One example is DNS17 (Domain Name System). This protocol ensures that a host name like www.ewolff.com can be resolved to an IP address. DNS is an essential component of the Internet and has clearly proven its scalability and availability. DNS is hierarchically organized: There is a DNS server that administrates the .com domain. This DNS server knows which DNS server administrates the subdomain ewolff.com, and the DNS server of this subdomain finally knows the IP address of www.ewolff.com. In this way a namespace can be hierarchically organized, and different organizations can administrate different parts of the namespace. If a server named server.ewolff.com is supposed to be created, this can be easily done by a change in the DNS server of the domain ewolff.com. This independence fits well to the concept of microservices, which especially focus on independence with regard to their architecture. To ensure reliability there are always several servers, which administrate a domain. In order to reach scalability DNS supports caching so that calls do not have to implement the entire resolution of a name via multiple DNS servers, but can be served by a cache. This does not only promote performance, but also reliability.
- • For Service Discovery it is not sufficient to resolve the name of a server into an IP address. In addition, there has to be a network port for each service. Therefore, the DNS has SRV records. These contain the information on which computer and port the service is reachable. In addition, a priority and a weight can be set for a certain server. These values can be used to select one of the servers and thereby to prefer powerful servers. Via this approach, DNS offers reliability and Load Balancing onto multiple servers. Advantages of DNS are apart from scalability also the availability of many different implementations and the broad support in different programming languages.
- • A frequently used implementation for a DNS server is BIND (Berkeley Internet Name Domain Server)}18 BIND runs on different operating systems (Linux,  
BSD, Windows, Mac OS X), is written in the programming language C and is under an open-source license.
- • Eureka is part of the Netflix stack. It is written in Java and is available under the Apache license. The example application in this book uses Eureka for Service Discovery (see section 13.8). For every service Eureka stores under the service name a host and a port, under which the service is available. Eureka can replicate the information about the services onto multiple Eureka servers in order to increase the availability. Eureka is a REST service. A Java library for the clients belongs to Eureka. Via the sidecar concept (section 7.9) this library can also be used by systems, which are not written in Java. The sidecar takes over the communication with the Eureka server, which then offers Service Discovery to the microservice. On the clients the information from the server can be held in a cache so that calls are possible without communication with the server. The server regularly contacts the registered services to determine which services failed. Eureka can be used as basis for Load Balancing since several instances can be registered for one service. The load can then be distributed onto these instances. Eureka was originally designed for the Amazon Cloud.
- • Consul is a key/value store and therefore fits also into the area of configuration servers (section 7.10). Apart from consistency it can also optimize availability. Clients can register with the server and react to certain events. In addition to a DNS interface it also has a HTTP/JSON interface. It can check whether services are still available by executing health checks. Consul is written in Go and is available under the Mozilla open-source license. Besides, Consul can create configuration files from templates. Therefore, a system expecting services in a configuration file can likewise be configured by Consul.
Every microservice-based architecture should use a Service Discovery system. It forms the basis for the administration of a large number of microservices and for additional features like Load Balancing. If there is only a small number of microservices, it is still imaginable to get along without Service Discovery. However, for a large system Service Discovery is indispensable. Since the number of microservices increases over time, Service Discovery should be integrated into the architecture right from the start. Besides, practically each system uses at least the name resolution of hosts, which is already a simple Service Discovery.