HN user

williamallthing

199 karma

talky person at buoyant (https://buoyant.io)

Posts18
Comments64
View on HN
twitter.com 3y ago

eBPF Verification Is Untenable

williamallthing
99pts111
linkerd.io 4y ago

Linkerd is now a CNCF graduated project

williamallthing
15pts1
linkerd.io 5y ago

Under the hood of Linkerd's state-of-the-art Rust proxy

williamallthing
17pts0
linkerd.io 6y ago

A guide to distributed tracing on Kubernetes with Linkerd

williamallthing
3pts0
linkerd.io 6y ago

Distributed tracing in the service mesh: four myths

williamallthing
20pts3
linkerd.io 7y ago

Failure Injection on Kubernetes with SMI and Linkerd

williamallthing
38pts10
linkerd.io 7y ago

Linkerd 2.3: Towards Zero-Touch, Zero-Trust Networking for Kubernetes

williamallthing
12pts1
www.infoq.com 7y ago

Lessons from Prod Resulted in a Rewrite of Linkerd from Scala to Rust and Go

williamallthing
17pts0
kubernetes.io 7y ago

GRPC Load Balancing on Kubernetes Without Tears

williamallthing
17pts0
buoyant.io 8y ago

Debugging microservices on Kubernetes with the Conduit service mesh 0.4 release

williamallthing
52pts13
blog.buoyant.io 9y ago

Linkerd-tcp: A lightweight, service-discovery-aware, TLS-ing TCP load balancer

williamallthing
170pts15
blog.buoyant.io 9y ago

A Service Mesh for Kubernetes: Distributed Tracing

williamallthing
14pts0
blog.buoyant.io 9y ago

HTTP/2, gRPC, and the future of linkerd

williamallthing
10pts0
blog.buoyant.io 9y ago

A Service Mesh for Kubernetes, Part III: Encrypting All the Things

williamallthing
16pts0
blog.buoyant.io 10y ago

Squeezing blood from a stone: small-mem JVM techniques for microservice sidecars

williamallthing
6pts0
blog.buoyant.io 10y ago

Linkerd: Twitter-Style Operability for Microservices

williamallthing
13pts2
all-thing.net 16y ago

How to rank products based on user input

williamallthing
1pts0
all-thing.net 17y ago

Some git fu

williamallthing
2pts0

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

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.

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.

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.

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.