There are two networking features or services that you get for free with your Docker swarm networks. The first is Service Discovery, and the second is load balancing. When you create Docker services, you get these features automatically. We experienced these features in this chapter and in Chapter 5, Docker Swarm, but didn't really refer to them by name. So, let's call them out here.

First up is Service Discovery. When you create a service, it gets a unique name. That name gets registered with the swarm DNS. And, every service uses the swarm DNS for name resolution. Here is an example for you. We are going to leverage the specifics-over overlay network we created earlier in the creating Docker networks section. We'll create two services (tester1 and tester2) attached to that network, then we will connect to a container in the tester1 services and ping the tester2 service by name. Check it out:

# Create service tester1
docker service create --detach --replicas 3 --name tester1 
  --network specifics-over alpine tail -f /dev/null
# Create service tester2
docker service create --detach --replicas 3 --name tester2 
  --network specifics-over alpine tail -f /dev/null
# From a container in the tester1 service ping the tester2 service by name
docker container exec -it tester1.3.5hj309poppj8jo272ks9n4k6a ping -c 3 tester2

Here is what the preceding commands look like when executed:

Note that I typed the first part of the service name (tester1) and used command-line completion by hitting Tab to fill in the container name for the exec command. But, as you can see, I was able to reference the tester2 service by name from within a tester1 container. 

For free!

The second free feature we get is Load balancing. This powerful feature is pretty easy to understand. It allows traffic intended for a service to be sent to any host in a swarm regardless of whether that host is running a replica of the service. 

Imagine a scenario where you have a six-node swarm cluster, and a service that has only one replica deployed. You can send traffic to that service via any host in the swarm and know that it will arrive at the service's one container no matter which host the container is actually running on. In fact, you can direct traffic to all hosts in the swarm using a load balancer, say in a round-robin model, and each time traffic is sent to the load balancer, that traffic will get delivered to the app container without fail. 

Pretty handy, right? Again, for free!