Service Discovery & Service Mesh
You'll learn to
- -Explain what a service registry solves
Once services are split apart and each can scale, deploy, and restart independently, a new problem appears: how does the Orders service know the current network address of the Users service, when that address can change every time an instance restarts or a new one is added?
Service Discovery
In a microservice world, services are born, die, and move constantly. When your Order Service needs to call the Inventory Service, how does it know WHERE the Inventory Service is running? The IP address changes every time it restarts, and there might be 5 instances running at different addresses. A Service Registry is the live directory of all running services. Every service, when it starts up, registers itself: 'Hi, I'm Inventory Service, running at 10.0.3.42:8080, and I'm healthy.' The registry regularly health-checks all registered services. When Order Service needs to talk to Inventory Service, it asks the registry: 'Where is Inventory Service?' and gets back a list of healthy instances. This is SERVICE DISCOVERY. The ability to find services dynamically without hardcoding IP addresses. It's like the reception desk in a large hospital: instead of memorizing which room every doctor is in (rooms change all the time), you ask reception and they look up the current location.
Examples: Consul (HashiCorp, built-in health checks and key/value store), Eureka (Netflix, for Spring Boot services), AWS Cloud Map, Kubernetes Service + kube-dns (built into K8s), etcd (can be used for discovery)
Each service instance registers itself with a shared registry on startup (and deregisters, or is detected as gone, on shutdown). Callers query the registry (or use a client-side library that caches the registry's data) instead of hardcoding IP addresses that will inevitably go stale.
Every instance registers itself on startup; the Orders service asks the registry for a current address instead of using a hardcoded one.
An infrastructure layer that handles service-to-service communication concerns (mTLS, circuit breaking, retries, observability) transparently, without changes to application code.
Imagine every employee in a company personally negotiated security protocols, handled phone failures, tracked who they called, and logged every conversation manually. A service mesh is the company's centralized communication department - it handles all of that so employees just make the call without worrying about the mechanics.
A service mesh is built around the sidecar pattern: a lightweight proxy (e.g., Envoy) is deployed alongside every service container in the same pod. All network traffic flows through these sidecars, which implement: mutual TLS (mTLS), load balancing, circuit breaking, retries, timeouts, distributed tracing, and metrics - without any application code changes.
Mutual TLS (mTLS): Every service-to-service call is encrypted AND both sides authenticate with certificates. This eliminates the need for API keys or tokens for internal service calls. Istio auto-issues and rotates certificates.
Traffic management: Fine-grained control - send 10% of traffic to the new version (canary), send all traffic from users with header `debug: true` to the staging cluster, automatically retry failed requests with exponential backoff.
Observability: The mesh captures metrics (latency, error rate, throughput) and distributed traces for EVERY service call across the entire system - without any instrumentation in application code.
The cost: significant operational complexity. Running Istio requires understanding CRDs (Custom Resource Definitions), Envoy configuration, certificate rotation, and control plane management. Many teams add a service mesh prematurely as complexity for complexity's sake.
- -Only justified at scale: 10+ microservices with complex inter-service communication.
- -Envoy proxy is the universal data plane (used by Istio, Linkerd, Consul Connect).
- -mTLS in a service mesh is essentially free zero-trust networking.
- -Linkerd is simpler than Istio; use Linkerd for teams without a dedicated platform team.
- -Cilium (eBPF-based) is the emerging alternative - no sidecar overhead.
What breaks if a service just hardcodes the IP addresses of the other services it depends on?
"Nothing, as long as you update the config when addresses change."
"In a dynamic environment, addresses change constantly: autoscaling adds and removes instances, deployments replace them, crashes take them down and bring up replacements elsewhere. Hardcoded addresses go stale continuously, and manually updating config for every instance change doesn't scale past a handful of services. Service discovery replaces 'a human updates a config file' with 'services query a registry that's always current.'"