In traditional or old-fashioned application architecture, IP addresses and ports are mainly static and fixed so that they can be easily managed for client applications. In a static, configuration-based application, each service is deployed at the same location and only rarely do we need to change the location of the services. However, in the case of cloud-based microservices applications, IP addresses and ports are very difficult, and sometimes even impossible, to manage.

In the microservice architecture, we cannot guarantee that there will be static configuration because microservices are independently deployable and individual teams work on individual microservices; each team can deploy and scale their microservices independently. More services and instances may also be added to the system to provide scalability to the distributed application. Because of this scaling, service locations can change frequently, so locations cannot be thought of as static. This means that a more dynamic configuration is needed for the microservice architecture.

Let's assume that we have many instances of several services on a different server. Due to the dynamic location of these services, it is much more difficult to manage service discovery in the client application. This problem is illustrated in the following diagram:

In the preceding diagram, you can see that all service instances have dynamic IP addresses and ports. However, the service clients and the API Gateway, which we will discuss in the next chapter, need to be able to communicate with the services. The client code, or the API Gateway, therefore need a better mechanism to find services—one which doesn't require the hardcoded location of a service. In the following section, we'll take a look at the service discovery patterns.