Web scale architectures and horizontal scalability have seen the growth of micro services and the breakdown of monolithic applications into a set of standalone services. The rise of micro services enables each service to be scaled, monitored and upgraded independent of the other services. Also, innovative interaction of these services can result in new applications.
In this blog, we will address an important aspect of building micro services based distributed system called service discovery.
Let’s assume an application consists of few more services and a service wants to invoke another service using its REST API. In order to invoke the service endpoint, one needs to know its access point i.e IP address and port of the service.
The problem seems simple at first: How to determine the IP and port of a service?
In traditional approach all systems that needs to access a service needs to be configured with the access point and this information was read from a configuration file which is updated as and when the access point was updated. But, with the evolution of micro services architecture and containerization, where the services are run on multiple hosts and are being scaled up or down as the traffic needs, this is not feasible. With containerization, the location of a service can change dynamically.
DNS is another approach to enable service discovery and is probably the largest service discovery system out there, but is designed primarily for services running on standard ports. With modern applications making use of containerization, private NATs and IPv6, services might listen on completely non standard or even random ports. We may even have multiple applications running on the same host.
To address this, DNS came with SRV (service) records, which gives IP as well as port in the query response. But where do you tell application to do an SRV record lookup? It’s too late for application to explicitly support SRV records making DNS effectively a tool for resolving domain names to host IPs.
Systems has been explicitly designed to address the challenge of service discovery. These service discovery systems manage how services discover and talk to each other. This can be a registry where one can register services, lookup and connect to services in that registry which is updated continuously.
Providers use service discovery systems to advertise their services, or in some cases, the services themselves advertise their whereabouts to these systems. Consumers interact with the service discovery systems to discover the services, they are interested in interacting with..
Key aspects of a service discovery system :-
- Service Registration- Mechanism to register service by name with its location information – IP and port along with configuration or environment detail.
- Service Discovery- Mechanism to lookup service by their name.
- Authentication- Mechanism to authenticate producer and consumer of services.
- High Availability- Discovery system itself should be highly available with no single point of failure.
- Load Balancing- Load balance between services of same type.
- Monitoring- Mechanism to check the status of registered services and ensure that only available and healthy services are returned on a lookup.
Service discovery patterns
Client side discovery- Clients query the service registry to get a list of available service instances. This pattern couples the client with service registry. The client has to implement their own logic depending on programming language and framework in order to interact with the service discovery system to discover services.
Server side discovery- Instead of client talking to service registry, client makes a request to intermediate gateway server which handles the discovery of the right service endpoint (or endpoints) for a request and forwards the request to the appropriate service. The Gateway can be common for all service types or gateways per service type. There is no overhead of implementing client side logic to discover services. Gateways need to be replicated for highly availability. Network hops are more compared to client side discovery pattern.
For example Kubernetes runs proxy on each node that functions as an server side discovery gateway. You can read more about Kubernetes in our earlier post on Kubernetes architecture.
Technologies that are commonly used as service registries includes:
Conclusion
This blog should provide an introduction to service discovery, an important aspect of developing micro services based applications. Service discovery plays an important role in building interaction patterns across services and one should recognize the need of it to build loosely coupled scalable systems. Also, one should understand the various failure modes of service discovery system and how these applications or services behave in wake of such failures.
In the upcoming post we’ll dig deep into each of the available service discovery system in market and compare them with each other.