Connecting Kubernetes services with linkerd

Posted Apr 10, 2017 19:12 UTC (Mon) by federico3 (guest, #101963)
Parent article: Connecting Kubernetes services with linkerd

> service discovery, load balancing, encryption, tracing and logging, handling retries, expiration and timeouts, back-offs, dynamic routing, and metrics

Replacing a big monolithic application with microservices and a big, complex, monolithic load balancer?

Perhaps those functions should be implemented by independent, modular libraries and daemons.

Connecting Kubernetes services with linkerd

Posted Apr 10, 2017 21:50 UTC (Mon) by Cyberax (✭ supporter ✭, #52523) [Link]

How exactly? My $BIGCORP employer has an exactly same problem - a simple user-initiated request has to wind its way through many services (that I won't really call 'micro' in many cases) and the overall emergent behavior is often surprising.

Some of it can be mitigated in a decentralized way by over-provisioning and by making sure that retry policies are not provoking vicious loops (when most services are stuck retrying requests that have long since timed out on an upper level). But that can only be done to a certain degree.

My only personal objection coming from high-traffic service experience, is that this service should be designed as a metadata side-channel and leave the actual HTTP (or whatever) requests to individual services.

Connecting Kubernetes services with linkerd

Posted Apr 10, 2017 22:15 UTC (Mon) by nix (subscriber, #2304) [Link] (2 responses)

That's exactly what this is for -- allowing ways for lots of daemons to talk to each other while imposing policies on all of them that are inapplicable to single daemons alone (like maximum retry counts and global timeouts), and not requiring them all to replicate all the communications infrastructure.

So they're called 'microservices', but that's just a wizzy name for a small daemon that talks over the network, really.

Connecting Kubernetes services with linkerd

Posted Apr 11, 2017 4:04 UTC (Tue) by drag (guest, #31333) [Link]

> So they're called 'microservices', but that's just a wizzy name for a small daemon that talks over the network, really.

That's definitely all it really is.

It's the classic 'thread' vs 'fork' approach. A single process with lots of threads and shared memory and all that jazz versus a bunch of relatively small processes trying to do the same job. Microservices is just forking processes over a bunch of systems and using TCP/IP for IPC. Same limitations and problems apply as before as well as the challenge of coordinating this stuff over multiple Linux instances.

Connecting Kubernetes services with linkerd

Posted Apr 11, 2017 5:33 UTC (Tue) by Cyberax (✭ supporter ✭, #52523) [Link]

Well, if all your services are using the same framework then you can do global timeouts by propagating "request deadline timestamp" and/or time budget to your downstream services and checking that there's still some time left in the upstream services when they get back the results.

More advanced stuff like intelligent request distribution and global throttling are not really possible.