What is service discovery, and why do you need it?

As far as I can tell, "service discovery" means a way for a client to find out about a server (or cluster of servers) that it wants to connect to.

I've built web applications that communicate with other back-end processes using protocols like HTTP and AMQP. In those, each client has a config file that contains a host name or whatever information it needs to connect to the server, which gets set at deployment time using a configuration tool like Ansible. That's simple and seems to work pretty well.

Is service discovery an alternative to just putting server information in a client's config file? If so, why is it better? If not, what problem does it solve?

Let's start by reviewing what service-discovery is - here's a good explanation: https://www.nginx.com/blog/service-discovery-in-a-microservices-architecture/ (this link should pretty much clarify the issue asked)

And here's an example how it is used in practice: Suppose you have service B which is used by service A. Service B (like most services in SOA) is actually a cluster of applications of type B. Service A requires to use one of the nodes of cluster B, yet the cluster of B nodes is dynamic. i.e. B nodes are created and terminated, depending on the load on the overall B service. Now, we would like service A to communicate with a live B node every time it needs to use service B. In order to do so, we will use the service-discovery tool to provide us, at any given time, an address of one of the live B nodes.

So, trying to answer your above questions, putting the end-point server information (specifically endpoint address) as static configuration in a config file which is read at the startup of service A, won't give you the dynamics you'd like when service B endpoints may constantly change.

The cloud server architecture is changing the way we build web applications that we are moving from single large monoliths to breaking them up into smaller and smaller individually deployable services called microservice together form the large application.

Let's consider the scenario when a service wants to communicate with other service let's say Service-A needs to communicate with Service-B. The Service-A needs to know the IP address and Port number of the Service-B. The easiest solution to the problem is by maintaining a configuration file that holds the IP address and port to Service-B at Service-A. There are several cons for this approach

Consider the following situation : -

• When the number of micro-services in the application increases
• It is difficult to manage in a configuration file
• It is error prone when some mismanagement happens
• It lacks the flexibility to change the IP or port in a later point of time
• It cannot utilize the capability of the cloud to dynamically scale or shrink based on the requirements.

This simple approach is too static and freezes the cloud Thus comes the new solution

Alternative solution: Service Discovery

Service discovery helps to solve the above problem by providing a way

• To register a service ie when a new service becomes online it registers itself to the service discovery service with its IP and port
• Helps service's to find other services ie helps Service-A to find Service-B
• Health check to check the health of instance and to remove it when it is not well.
• To deregister when a service becomes offline.

Thus it helps to utilize the full capability of the cloud to dynamically scale and shrink based on the requirements and also make the architecture loosely coupled to each other

In a cloud environment where docker images are dynamically deployed on any machine or IP + Port combination, it becomes difficult for dependent services to update at runtime. Service discovery is created due to that purpose only.

Service discovery is one of the services running under microservices architecture, which registers entries of all of the services running under the service mesh. All of the actions are available through the REST API. So whenever the services are up and running, the individual services registers themselves to service discovery service and service discovery services maintains heartbeat to make sure that those services are alive. That also serves the purpose of monitoring services as well. Service discovery also helps in distributing requests across services deployed in a fair manner.

I have to admit that the method you said is feasible, but if there are so many services, the complexity you need to manage will increase, and manually configuring the service list is also very error-prone.

Service discovery is not a simple way to put the list of services to be called in the client configuration, but to save the list of instances of all services themselves.

you can simply understand that we have a registration service that can automatically manage the list of service instances to be accessed. When you add a service or close the service, the registration service will automatically update your service list. When you call it, you will get the latest service list from the registration center to call. In order not to affect the performance, you can also Cache the service list on the client

If you have 2 microservices, say A and B and you want A to communicate with B, A will use a service discovery method(tool) to find B in a microservice architecture.

Not only client to server communications but also a 2 microservices that maybe running on the same server.

The problem it solves is 2 microservices running on 2 different nodes in a cluster can discover each other, without service discovery, this would have not been possible.

You can look at how kurbernetes supports service discovery say through DNS using coreDNS. https://kubernetes.io/docs/concepts/services-networking/service/