Service Discovery in Microservices

Service Discovery

Background

Traditionally, the application was divided into modules and these modules were built in a single code base. This kind of architecture which we call “Monolithic Architecture”. Mono means ‘Single’ and lith means ‘a single block of stone or pillar’. In short, the entire application was built in a single code base. Let’s discuss the cons of this kind of architecture.

1. Deployment: If there is a small change in any part of the code, you will need to deploy the entire application again.
2. Re-usability: Monolithic applications are not reusable because they use tools out of the box. You will not be able to just extract a feature and integrate it into another project.
3. Testing: Even a small change causes to test the entire application which can be both time and resource consuming.

In modern cloud-based architecture, we use microservices to build and deploy applications. Microservices appeared as an alternative to monoliths in order to solve all issues and bottlenecks caused by the limitations of the monolithic architecture. Let’s discuss the pros of Microservice architecture.

1. Deployment: As each microservice is an individual unit, it’s easy to deploy a unit rather than an entire application.
2. Re-usability: We can reuse the microservice in any project without any fear due to its zero dependency.
3. Testing: It’s really easy to test the small code base rather than the entire application.

What is a Service Discovery?

So we discussed the pros of Microservice architecture, now Let’s imagine you have multiple microservices to collectively form an E-commerce application. So we have a Product catalog, Order management, and Consumer management microservices.

Now, how these microservices will talk to each other? So basically you will have REST API exposed which other services can consume it. For example, suppose Order Service needs the product information then the APIs of Product Service will be integrated inside Order microservice. So how will you store this API endpoint? Will you hard code it in your Order microservice? If you hard code the API endpoint, what if the endpoint is changed in the future?

So here, Service Discovery comes into the picture. In a microservice architecture, each microservice tells Service Discovery that if someone is looking for me, tell them that I am here. So service discovery acts as a registry where all the microservices are registered. The set of running service instances changes dynamically. Instances have dynamically assigned network locations. Consequently, in order for a client to make a request to service, it must use a service-discovery mechanism.

The Service Discovery can be implemented in two ways:

1. Client Side Service Discovery
2. Server Side Service Discovery

Client Side Service Discovery

Let’s take a simple example, You would like to order Pizza, what will be your steps. So first of all, you will google it, Pizza Store around me, Mr. Google will give some results, with the phone number or website links. So you will place your order by contacting using the phone or on the web.

So where is Service Discovery? In this scenario, if you look at again, Google is acting like a Service Discovery, because it has all the Pizza Store contacts, so when you request, it will provide the best suitable for you.

Let’s understand using the below diagram in steps.

So in the above diagram, there are four services. Initially, all services are registered with Service Discovery. Suppose service 1 wants to talk to service 4 then

1. Step 1: Service 1 will ask for the contact to the Service Registry.
2. Step 2: Service Registry will respond with the Service 4 contact number.
3. Step 3: Now Service 1 will request whatever it wants from the Service 4.
4. Step 4: Service 4 will return the response to service 1.

So in this way, different microservices can talk to each other using Client Side Service Discovery. Now let’s understand the Server Side Service Discovery.

Server Side Service Discovery

Let’s have another simple example, A person wants to talk Mr. George who is working in a large company, so a person calls at reception and requests to talk to Mr. George. The receptionist, a smart person, she knows about Mr. George, but she transfers a call using Mr. George desk extension. And in this way, a person is talked with Mr. George.

So can you guess, where is Service Discovery? In this scenario, the Receptionist is acting as Service Discovery, as she has a list of all extensions of employees working within the company.

Let’s understand using the below diagram in steps.

So in the above diagram, as explained in Client Side Service Discovery, there are four services. Initially, all services are registered with Service Discovery. Suppose service 1 wants to talk to service 4 then

1. Step 1: Service 1 will ask for the contact to the Service Registry.
2. Step 2: Service Registry will route the request to Service 4.
3. Step 3: Now Service 4 will responds with the result.
4. Step 4: Service 1 will get a response.

So in this way, different microservices can talk to each other.

Conclusion

This article explains how service discovery works in a microservice architecture system and the types of Service discovery.

Thanks for reading!

If you like the above article please clap the same and if you don’t like please put your thoughts in comments so that I can improve it.

You can reach me out on Linkedin, Quora.

References

1. https://dzone.com/articles/service-discovery-in-a-microservices-architecture
2. https://www.youtube.com/watch?v=GboiMJm6WlA