Microservices vs. Monolith: The Trade You're Actually Making

Part 7 of 17 · ~1 min

Service Discovery

In the monolith, one module reaching another was resolved at compile time — HarvestLot was just a class you could import. Once Harvest is a separately deployed, separately scaled service, its instances come and go: autoscaling adds three more during Wednesday's upload window and removes them Thursday morning, a rolling deploy replaces every instance over ninety seconds, one of them occasionally just crashes. Subscriptions needs a way to find a currently healthy address for "the Harvest service" that doesn't rely on a hardcoded IP, since whatever pod owned that address an hour ago may well be gone by the time the next request goes out.

• Client-side discovery — the caller queries a registry directly for whichever instances currently report healthy, picks one itself, and spreads its own traffic across them.
• Server-side discovery — the caller hits one fixed address, and whatever sits behind it — typically a load balancer, or the gateway covered next — works out where to route it, so the caller never has to know discovery happened at all.

Furrow runs on Kubernetes, which hands it most of this for free: a Kubernetes Service gives Harvest a stable internal DNS name, and Subscriptions just calls that fixed hostname while Kubernetes routes each request to whichever pods currently report healthy — so scaling Harvest from one instance to six for Wednesday night is invisible to every caller, and it stays invisible when a pod dies mid-deploy and gets replaced.