Microservices have to communicate with each other, and to do that, services need to find each other's location. One can bundle the IPs and URL path inside the microservice. This will cause a problem if the IP of another microservice changes. Any change in the IP or any service requires it to make a change in the code of the microservice using it and forces the release of that microservice. A solution for that is if the IP address is extracted from code and placed in an external configuration; we will talk more about the externalization of microservices in the next section. If you have a few services in your bag, it can solve our purpose. As your system starts evolving, then the number of microservices will increase. With an increasing number of microservices, the environment becomes more and more dynamic. Microservices can be coming up and down, assigning IPs on the fly based on traffic's need. This will make the process of locating a particular service or machine more and more difficult. Also, monitoring these increasing microservices will lead you to another challenge. In this situation, identifying the location of any particular service will not be an easy task and book keeping will not work here. This raises the need for a mechanism to locate any particular microservice in our system. That mechanism should give developers confidence to start and stop services in any order, and reconfigure services easily. To achieve this, the mechanism or external service should be capable enough to provide information about microservices coming up and down dynamically in the system. There are a few ways to solve this service location problem; one has to study enough to find the best suited method of their microservice architecture.