1.3.3.4 Service Discovery Contrast

Service discovery contrast examines how containers find and connect to each other on a single host versus across a multi-node cluster, and how the mechanism for doing so changes as the number of hosts involved grows.

Service Discovery on a Single Host

On one host, Docker's built-in networking lets containers reach each other by container name, resolved automatically through Docker's embedded DNS server, without needing to know each other's IP addresses.

docker network create myapp-net
docker run -d --name db --network myapp-net postgres:16
docker run -d --name app --network myapp-net -e DB_HOST=db myapp:1.0

Inside the app container, the hostname db resolves correctly because both containers share the same user-defined network on the same host.

Why This Breaks Down Across Multiple Hosts

A single host's Docker network does not automatically span other hosts. If db and app are placed on different machines, the simple name-based resolution used above has no mechanism to work, since each host's Docker daemon only knows about networks and containers local to itself.

docker run -d --name app myapp:1.0

Run on a separate host from db, this container has no built-in way to resolve the hostname db to the correct machine.

Service Discovery in an Orchestrated Cluster

Orchestrators solve this with overlay networks and a cluster-aware DNS service, so a service name resolves correctly to whichever node currently happens to be running it, even as containers are rescheduled across the cluster over time.

docker network create -d overlay myapp-net
docker service create --name db --network myapp-net postgres:16
docker service create --name app --network myapp-net myapp:1.0

The name db continues to resolve correctly even if the underlying container is rescheduled to a different physical node, because the orchestrator's service discovery layer tracks the mapping, not a static configuration.

Service Discovery and Load Balancing

In a multi-node setup, service discovery is often combined with load balancing: a service name can resolve to any one of several replicas running across different nodes, distributing requests rather than always pointing to one fixed instance.

docker service create --name app --replicas 3 --network myapp-net myapp:1.0

Why This Distinction Matters

Understanding that single-host name resolution and multi-node service discovery are solved by different mechanisms prevents a common mistake: assuming a setup that works correctly with containers on one machine will continue to work unmodified once those same containers are spread across a cluster.