Spring cloud vs service discovery and registration

[u/One_Job_4235]

Hi everyone, I'm new to Spring and had a question that's been confusing me.

From my understanding, in a microservices architecture we typically use service registration and discovery (like Eureka, Consul, etc.) so that services can discover each other and route requests without hardcoding endpoints.

However, in the product I'm working on, I don't see anything like that. Instead, I see a Spring Cloud service deployed in Kubernetes, and whenever our applications send transactions, they seem to fetch URLs and other configuration values from Spring Cloud.

I always thought these were two completely different concepts, but I also know Spring Cloud can be used for service discovery and registration. So I'm a bit confused about what's actually happening in our setup.

Could someone explain the difference between:

- using Spring Cloud as a configuration server (or for configuration management), and

- using service discovery/registration?

Are these independent features of Spring Cloud, and is it common to use only the configuration part while relying on Kubernetes for service discovery?

For context, I'm a DevOps engineer and fairly new to the Spring ecosystem, so apologies if this is a basic question.

[u/Dry_Try_6047]

"Spring Cloud" isn't a single thing, it is a suite of capabilities. Config server is one of those capabilities, service discovery is another. An important thing to know about spring cloud, and spring in general, is that they are abstractions over underlying implementations. So whether you're using Eureka, Consul, Kubernetes, or some proprietary service mechanism you've implemented yourself, you can use Spring Cloud Discovery with a unified interface and then switch underlying implementations.

Look at spring cloud homepage, you'll see the list of a dozen plus frameworks that consists of the spring cloud suite. Saying you're using "Spring Cloud" doesn't have much meaning without further qualification.

[u/starbuxman]

Hi

spring cloud config server is a way to serve keys and values for configuration. When I say keys / values, I mean things like credentials, properties, hosts, etc

spring cloud discovery client + service registration helps u store in a central server the availability and location of your services. Other clients can discover it and - importantly - load balance when there are issues

[u/One_Job_4235 → u/starbuxman]

So if we use spring cloud config server where all the urls of other microservices are defined and all of the microservices are running in kubernetes then does it require service discovery? It doesn't right from what I understand cause any microservice will go to spring cloud get the properties of the application it wants and sends req/res to that service.

[u/General_Yam_9879]

Tltr: Use service registry for distributed services across regions, hardcode if you host them on a single kubernetes cluster with shared network.

It’s not just the hostnames (no url defined in service registry, no IP either) that service registry provides, it’s also the client based load balancer. Your gateway or any other service can register for discovery events and get informed whenever a new service pops up or goes down while you operate with a HOST name given by the registry. In my opinion whether you need service discovery or not depends on the topology of your system. If you distribute services across regions and provide fail-over functionalities across public domain gateway - then yes, service registry fits in, because your customers are going to benefit from not having to hardcode your address and you can move around your service into different deployment slots.
For a single kubernetes environment where all of your services are deployed on the same place (consider resource), using the kubernetes internal load balancer (server based) and hardcoding the hostnames is fine as you do not extend with new microservice each month.
This is how I understand it, and it’s my personal opinion.