williamallthing

Hi, Linkerd person here. I don't use HN much these days but I was pointed me to your comment. First, thank you for your empathy. The truth is that as much as I would prefer it otherwise, this change is required for Linkerd's survival and future growth. In turn I have empathy for you—we've put you in a tough situation with this, and while with 7 prod clusters it seems fair to ask your company to help fund the project (maybe you disagree), it doesn't seem fair that the onus to push this change through your company falls on you. I know this is a consequence of how we designed this transition but I wish there were a way we could make this part better. FWIW, we do have a team of folks who are very good at working the process, and at your scale we have flexibility on terms and pricing, so I think we can make it easy in your specific situation. Some of the new features are focused on cost reduction so there is an opportunity to appease the budgetary gods.

In terms of the stability guarantees you point out, that has always been the case for edge releases. They contain the latest changes on main, and while we try to keep that as stable as possible, things can break. Everything is well-documented and we try our best to at least have you able to make an informed decision.

Hope that helps, I'm always up for a deeper chat if you want to send me an email. (At the bottom of the blog post.)

Thank you!

Exactly. Linkerd is fast and simple in no small part because it doesn't have 20 competing, sharp-elbowed vendors pulling it in 21 different directions. Customer focused is everything.

You have no idea how many Istio companies have turned to Linkerd because of this very complexity. Here's one of my favorite writeups. https://nais.io/blog/posts/changing-service-mesh/

Maybe you're just not talking to the right companies. There are a ton of Linkerd adopters and the list is constantly growing! https://linkerd.io/community/adopters/

IMHO the operational cost of a service mesh only really makes sense in the context of Kubernetes. A service mesh works by deploying lots of proxies everywhere; in Kubernetes you can do that very cheaply but outside of Kubernetes you're going to have to do some work.

So: I would start with installing something like Linkerd in a Kubernetes environment and work outwards from there.

Thanks, I updated the curl command-line args.

Non-HTTP TCP traffic will be mTLS'd by Linkerd just as well as HTTP traffic is, as long as there's a proxy on both ends of the connection. No tunnel required.

Just published this earlier this morning. Would love your comments and corrections. TLS is a huge topic and I'm sure I got something wrong in here.

Mesh expansion is on the Linkerd roadmap, which will make it possible to run the data plane outside of Kubernetes.

If all your experience is with Istio and "layers on top of Istio", I'm not surprised you think service meshes need lots of config. Sounds like you need to try Linkerd!

> 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

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.)

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

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.)

This is one of the several reasons Linkerd moved from per-host to sidecars.

For mTLS, the moment you want to have identity per service (as opposed to one cert across everything in the mesh), you need the security boundary to be at the pod level.

The metrics data includes upstream and downstream calls for each service, so you can pull those together to draw the whole topology. Don't need end-to-end traces for that.

Author here! Happy to answer any questions people might have.

Linkerd uses <10mb per proxy

Very cool!

The service mesh doesn't have to be complex. If you want the value of the service mesh at a fraction of the complexity, start with Linkerd.

Have you considered doing a similar writeup for Linkerd? (https://linkerd.io)

Author here. Happy to answer any questions you might have.