Since we don't want to deal with this fragile system of keeping and maintaining hardcoded IP addresses, we need to figure out a way so our connections are flexible and require no adjustments from the client if the target service dies or a new one is created. It would also be nice if each connection to the same service is equally balanced between all instances of the same service. Ideally, our services would look something like this:

For this exact use case for the Internet, DNS was created so that clients would have a way to find servers even if the IP address or network changes from anywhere in the world. As an added benefit, we have target addresses that are easier to remember (DNS names such as https://google.com instead of something such as https://123.45.67.89 ) and the ability to distribute the processing to as many handling services as we want.

If you have not worked with DNS in depth, the main principles are reduced to these basic steps:

1. The user (or app) wants to connect to a server (that is, google.com).
2. The local machine either uses its own cached DNS answer or goes out to the DNS system and searches for this name. 
3. The local machine gets back the IP address ( 123.45.67.89 ) that it should use as the target.
4. The local machine connects to the IP address.

If we coerce the DNS handling that is implemented in almost all clients already as a way to automatically discover services, we could make ourselves the service discovery mechanism that we have been looking for! If we make it smart enough, it can tell us where the running container is, load balance between all instances of the same container, and provide us with a static name to use as our target. As one may expect, almost all container service discovery systems have this exact pattern of functionality; it just generally differs if it is done as either a client-side discovery pattern, server-side discovery pattern, or some sort of a hybrid system.