williamallthing

11 ms·

1.
by williamallthing 3y ago
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 survi
2.
by williamallthing 3y ago
Thank you!
3.
by williamallthing 3y ago
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 .
4.
by williamallthing 3y ago
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/
5.
by williamallthing 3y ago
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/
6.
eBPF Verification Is Untenable(twitter.com)
99 points by williamallthing 3y ago|111 comments
7.
by williamallthing 5y ago
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
8.
by williamallthing 5y ago
Thanks, I updated the curl command-line args.
9.
by williamallthing 5y ago
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.
10.
by williamallthing 5y ago
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.
11.
by williamallthing 5y ago
Mesh expansion is on the Linkerd roadmap, which will make it possible to run the data plane outside of Kubernetes.
12.
Linkerd is now a CNCF graduated project(linkerd.io)
15 points by williamallthing 5y ago|1 comments
13.
by williamallthing 6y ago
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!
14.
by williamallthing 6y ago
> 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 Linke
15.
Under the hood of Linkerd's state-of-the-art Rust proxy(linkerd.io)
17 points by williamallthing 6y ago|0 comments
16.
by williamallthing 6y ago
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 :)
17.
by williamallthing 6y ago
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 :)
18.
by williamallthing 7y ago
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
19.
by williamallthing 7y ago
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. Wou
20.
by williamallthing 7y ago
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 alm
21.
by williamallthing 7y ago
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:&#x2F
22.
by williamallthing 7y ago
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 p
23.
A guide to distributed tracing on Kubernetes with Linkerd(linkerd.io)
3 points by williamallthing 7y ago|0 comments
24.
by williamallthing 7y ago
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:/&#x2F
25.
by williamallthing 7y ago
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 la
26.
by williamallthing 7y ago
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
27.
by williamallthing 7y ago
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 l
28.
by williamallthing 7y ago
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.
29.
by williamallthing 7y ago
Author here! Happy to answer any questions people might have.
30.
Distributed tracing in the service mesh: four myths(linkerd.io)
20 points by williamallthing 7y ago|3 comments

More ›