Service Discovery with FACTS
FACTS allows services as they boot, or at any other stage during their life cycle to register themselves so that other applications can locate them. FACTS support the notion of a service catalog, that allows multiple endpoints for each service to be stored in the catalog, and identified using meta data, or simply just returning all possible endpoints for a given service endpoint. The Meta data in FACTS allows a system to mark a specific endpoint as the 'primary' of lead node so that as other service come on line, they know which node and endpoint is the lead.
This is useful for cluster membership in a highly dynamic environtment with cluster nodes coming and going all the time, it's important to know who the lead node is, and how to join the cluster. Other scenarios include Primary node replacement, such as mondog-db in which the Primary node is typically the only write end point. Should this endpoint disappear then the applications themselves need to automatically fail over to another node, but the rest of the cluster and other applications coming on line also need to know who the new 'lead' or primary node is.
Dyanimic service configuration
Reverse proxy and caching solutions need to keep a track of all of their downstream endpoints. With a single container host this is easy as you can watch the docker events, but with an nginx farm that is acting as the reverse proxy tier for multiple endpoints it gets a little harder. With FACTS the nginx service can be automatically reloaded as new services or containers come online. There are many tools that can watch an HTTP REST interface for a list of services such as ContainerBuddy, docker-gen or even consul-template. By watching a given path, or each time there is a docker event, this can simply trigger nginx to re-read all the given endpoints for a given service or application route and dynamically build an nginx configuration and restart the nginx service.