In a world of distributed computing, it is very common for services to become a disposable commodity. The typical life cycle of a service could be measured in days, if not in hours, and it is not unheard of for an instance to just crash for whatever reason, only to have a new one come up automatically seconds later. When the state of applications is so ephemeral, it becomes really hard to maintain a statically-connected architecture, with services knowing where exactly their dependent services are located, as the topology is always changing.

To help with this problem, the service discovery layer comes into play, maintaining a centralized and distributed state of service registrations, ready to reply on demand with the most current information. Applications register themselves upon startup, providing information about their location and possibly about their capabilities, level of service, health check status, and even more.

Earlier in the book, in Chapter 6, Application Packaging and Deployment, we were introduced to Consul, and used it for external application configuration consumption. In this recipe, we will continue to look further into the capabilities of Consul and will learn about how to use the spring-cloud-consul modules to automatically register our application with Consul.