> Service Mesh == Dynamic Linker For Cloud

TMYK: Linkerd was actually named for the dynamic linker ("linker daemon"). It's also the service mesh most focused on transparency--in the vast majority of cases you can add Linkerd to an existing application without config and the application will continue functioning. https://linkerd.io/2/design-principles/

Thanks for the Linkerd shoutout! Many our Linkerd adopters these days in fact seem to be Istio refugees, looking for something simpler and lighter. Happy to have them :)

Great to hear Linkerd is treating you well. If you run into any issues please join us in the community Slack (slack.linkerd.io). Big friendly group of people ready to help you :)

Have you given Linkerd a try for comparison? Mutual TLS in 0 seconds (it's on by default) and a significantly lighter footprint. Canary traffic via SMI. Etc

I'm also curious about this (author here btw). The majority of people we see coming to Linkerd today are coming from Istio. They get the service mesh value props, but want Linkerd's simplicity and lower operational overhead. Would love some more details, especially GitHub issues.

Thanks for the Linkerd shoutout! For those who aren't familiar with the project, Linkerd will give you per-service metrics (success rates, RPS, latency distributions), mutual TLS, load balancing, and a bunch of other cool stuff, on almost any Kubernetes app, right out of the box. No config necessary.

Dapr is definitely not Microsoft's answer to Istio (see e.g. [1]). But if you are looking for something like Istio but that actually works out of the box (zero config), I'd highly recommend checking out Linkerd.

[1] https://news.ycombinator.com/item?id=21283956

Good to know - I haven't been keeping up with this thread.

I'll have to check out linkerd, thanks for the rec!

Really cool. Tokio is the core of Linkerd (https://linkerd.io) and I am really excited to see exactly what kind of impact this will have on Linkerd performance. A super fast, super light userspace proxy is key to service mesh performance.

Ubuntu's MOTD displays dynamic ads and at least one of these ads was about Istio. E.g. as best I can tell, every Ubuntu installation that hadn't disabled dynamic MOTDs displayed this Istio ad for most of August: https://bazaar.launchpad.net/~ubuntu-motd/ubuntu-motd/trunk/... .

(Of course as a Linkerd person I think it's ironic to advertise Istio on MicroK8s because Istio is anything but micro. But Microk8s has great Linkerd support these days, so maybe we'll get a Linkerd ad one day, and harmony in the universe will be restored.)

Because every system that needs to return a response within N ms (which is pretty much every app, service, API call, etc) ends up being implemented with synchronous calls, with messaging only used for truly offline bits. There's a good writeup of why here: https://programmingisterrible.com/post/162346490883/how-do-y... , with this great quote: "In practice, a message broker is a service that transforms network errors and machine failures into filled disks".

(I used to work at Twitter, which went through this same transformation, but if you watch tech talks from pretty much any other modern company that it building a big distributed system, you'll see the same pattern.)

Are we then paying the price in latency and added hops for development agility? I would have guessed a user request would never be subjected to that. With a mesh, don't you get even more latency because of the sidecar? The link you provided looks interesting; will give it a read, thanks!

Yes, you pay a latency and resource cost to have the service mesh features decoupled from the application code. Same with any abstraction e.g. containers or Kubernetes.

You could alternatively get service mesh features in the application layer with libraries like Finagle, Hysterix, etc, and not pay that cost. But then you're tied to particular languages, and changing platform features requires making code changes.

It's a tradeoff. I talked about this at Kubecon earlier this year: https://www.youtube.com/watch?v=Z3nfLI3z0hc#t=4m58

That was a great talk, thanks for sharing. I guess it all makes sense once you have bought into having synchronous dependencies between microservices - which is the part I was struggling with. But I guess if that is what you have to do, that is what you have to do.