Config first bootstrap and discovery first bootstrap are two different approaches for using Spring Cloud Config client in Spring Cloud-powered microservices. Let’s discuss both of them: Config First Bootstrap  This is the default behavior for any spring boot application where Spring Cloud Config client is on the classpath. When a config client starts up it binds to the Config Server using the bootstrap configuration property and initializes Spring Environment with remote property sources. Config-first approach  The only configuration that each microservice (except config-server) needs to provide is the following:  File:-  /src/main/resources/bootstrap.yml  spring.cloud.config.uri: http://localhost:8888  In config-first approach, even the eureka-server can fetch its own configuration from config-server. Point worth noting down here is that config-server must be the first service to boot up in the entire ecosystem, because each service will fetch its configuration from config-server.  Discovery First Bootstrap  If you are using Spring Cloud Netflix and Eureka Service Discovery then you can have Config Server register with the Discovery Service and let all clients get access to config server via discovery service.  Discovery-first approach  This is not the default configuration in Spring Cloud applications, so we need to manually enable it using the below property in bootstrap.yml  Listing 17. /src/main/resources/bootstrap.yml
spring:
cloud:
config:
discovery:
enabled: true
This property should be provided by all microservices so that they can take advantage of discovery first approach.  The benefit of this approach is that now config-server can change its host/port without other microservices knowing about it since each microservice can get the configuration via eureka service now. The downside of this approach is that an extra network round trip is required to locate the service registration at app startup.