Service discovery in microservices

Service discovery in microservices

Service discovery in microservices

Loosely coupled independent components are the essence of microservices architecture. The design principles aim at small services developed by independent teams using different technologies. The services can be scaled up and down irrespective of the other services. Although the services are independent, they are built as a solution which means there is a heavy need for interaction among the services… To add to the complexity, the services are deployed using many different technologies – a VM, a serverless container instance, and a Kubernetes cluster…. This design leads to many questions:

  • How do the services track each other?
  • After scaling up the service, how do the new instances start getting traffic?
  • Do we need static IPs or DNS names for each and every service?

The ‘service discovery’ pattern is the key to the tracking problem. Well, how does it work?

There is a central component called the service registry which keeps name-value pairs of all services – the logical name and the physical or network address, in a fast database like a Redis cache.  How does the service registry know about all the services? There are 2 patterns.

  • Self-registration – each service, as soon as it starts, registers itself with the registry and it deregisters itself just before stopping.
  • A third-party service acts as a service registrar. In the latter case, the registrar needs to be highly available with its own multiple instances running in different regions! The database to needs similar protection against accidental crashes
The service registry also eliminates the need for a static IP or DNS name for each service, thus making the solution more secure!

A load balancer is a savior for the scaling problem – it captures all requests and routes to the services using a scheduling algorithm like round-robin / least recently used / least loaded… The load balancer is typically a PaaS component on the cloud, and is hence already designed to be highly available!

In a nutshell, migrating from monolith to microservices architecture comes with its own set of new components. We cannot shy away from those. What is your experience of such a migration? Do leave a comment.

Share this post