There are many scenarios where it's useful, but I will illustrate a simple and important one.

When you do a rolling upgrade, a new service must be assigned to an available port different to the existing one. After starting you'll probably run some health checks, and once satisfied you'll want to switch traffic over to the new instance and halt the old. How do you tell the rest of your infrastructure what the new port is? Service discovery.

I make a new stack, new VMs, new loadbalancer and just update dns record of the service from old stack to new. Thats blue-green.

Rolling is trickier, but still, native cloud solutions do not use service discovery, imho.

What you’re describing took place with on-prem iron as well - nothing cloud about it. At all.

Service discovery is in part DNS with low ttl, but there’s a part of it that ties in to configuration management, monitoring and observability as well.

If you “update dns” that means you’re doing a part of what consul does (only f ex nomad does it for you). Nothing magic, but you still “need it”.

Tags and metadata is a large part of it though, as well as configuring things automatically based on state of the SD and K/V.

In the end - whatever works, I guess.

Many services, many teams. Coupled with health-checks, monitoring and tracing it’s an important piece of the puzzle if you want to move quick in a distributed setting - which most large organisations are.

Its name yes, just not where it is or how to get there. DNS on a smaller scale.