Spring Cloud Config Server — Discovery First Vs Config First

In the previous article, we saw how to bootstrap your first config server. In this article, we will discuss how to set up Config clients using Discovery first approach and Config first approach.

Config First:

Config first in the context of a Config client is — when client bootstraps, it knows and connects to Config server and then obtains rest of the property required.

Let’s look at the example service I have “client-config-first”

spring:
  application:
    name: client-config-first
  profiles:
    active: local
  cloud:
    config:
      uri: http://localhost:8672
      fail-fast: true
      retry:
        max-attempts: 20
        max-interval: 15000
        initial-interval: 10000
server:
  port: 8763

During bootstrap “client-config-first” connects to config server via url localhost:8762 and then loads all the properties. One of the properties is Eureka server configuration and “client-config-first” app registers to Eureka discovery server.

Pros:

1. Fixed URL — let’s say instead of an amateur localhost:8762 url, we are able to create a proper public URL like mycloud.configserver.com and under the hood you can have multiple instances of config server running on different ports. In that case, config server is load balanced and clients are not impacted due restart of config server for maintenance and environmental issues. Restarts due to health check and environmental issues are common in some container orchestration engines.

Cons:

1. Most of the micro services applications today will have a Discovery service in the architecture and that will be the first point of contact for all services. But doing config first for some applications will make the apps deviate from Discovery based architecture and will make the app rely on one more extra service.
2. If the location of the config server is changed, meaning the URL changes, then it requires a change in the configuration for all applications.

Discovery First:

Discovery first is the opposite of config first. On bootstrap the client connects to discovery server, looks up config server with a name, connects to config server to load properties. This adds one more work on Config server, yes it has to now be a Discovery client.

spring:
  application:
    name: client-discovery-first
  profiles:
    active: local
  cloud:
    config:
      fail-fast: true
      retry:
        max-attempts: 20
        max-interval: 15000
        initial-interval: 10000
       discovery:
        enabled: true
        service-id: config-server
server:
  port: 8764

eureka:
  client:
    enabled: true
    register-with-eureka: true
    fetch-registry: true
    serviceUrl:
      defaultZone: http://localhost:8761/eureka

Look at the above config and let’s spot some difference. There is no more spring.cloud.config.uri and instead we see 2 more new properties

spring.cloud.config.discovery.enabled = true

spring.cloud.config.discovery.service-id = config-server.

What this means is, discovery lookup is enabled and the app to look up is “config-server”. This is the spring.application.name of the config server that is registered with Eureka.

Pros:

1. Stay with the architecutre. If all of the services connect to Discovery as the first point of contact and do this way, you could still stay with the architecture.
2. Config server location can change, as long as it registers with Discovery and available, client apps will be able to look it up.
3. No hassle of creating and maintaining a URL.

Cons:

1. Restarts due to health check and environmental issues are common in some container orchestration engines and ports change dynamically. In such cases, Discovery server is not the best approach.
2. Apps fetch information of Config server from discovery on bootstrap and that’s it. So if host and port of config server changes anytime after client fetched it, then client will no longer be able to connect to the host and port it originally fetched on bootstrap. Clients will fetch the new location only when rebooted.

Choose carefully what works best for your architecture !!

Clap if this was helpful !!!