In a dynamic environment where service instances scale up/down and get rescheduled to different hosts/IPs (as in containerized deployments), hardcoding a downstream service's address is unworkable. Service discovery (e.g., via Netflix Eureka, Consul, or Kubernetes' own built-in DNS-based discovery) lets services register themselves with a central registry on startup and lets callers look up currently-healthy instances by logical service name instead of a fixed address.

Intermediate5 min

AccentureCapgeminiCognizantOracleIBMAmazon

#Service Discovery#Eureka

What is service discovery, and why do microservices need it?

Kubernetes Has Made Standalone Discovery Servers Less Necessary

In a Kubernetes-based deployment, a Service resource already provides stable DNS-based discovery and load balancing across pod instances natively, which is exactly why many newer Spring Cloud microservices setups skip a dedicated Eureka/Consul server entirely and rely on Kubernetes' own service discovery instead — Spring Cloud Kubernetes exists specifically to let Spring Cloud-aware code (like Feign clients) integrate with that native mechanism rather than reimplementing discovery.

Services register themselves by name → callers look up healthy instances by name, not a hardcoded IP that can change or scale