The Linkerd project's blog covers its Kubernetes service mesh, its Rust proxy, and design choices like not using Envoy.
HN commenters recommend Linkerd as a lighter service mesh that gives automatic mTLS, and note its Tokio-based proxy performance.
> As a relatively young dev, the idea of a "web server" as a standalone binary that serves your application (vs a library that you use to write your own "server") feels strange.
In my eyes, the ideal setup is one that's layered: where you have an ingress that's basically a load balancer that also ensures that you have SSL/TLS certificates, enforces rate limits, perhaps is used for some very basic logging, or can optionally do any URL rewriting that you need. Personally, i think that Caddy (https://caddyserver.com/) is lovely for this, whereas some people prefer something like Traefik (https://traefik.io/), though the older software packages like Nginx (https://nginx.org/en/) or even Apache (https://www.apache.org/) are good too, as long as the pattern itself is in place.
Then, you may additionally have any sorts of middleware that you need, such as a service mesh for service discovery, or providing internal SSL/TLS - personally Docker Swarm (https://docs.docker.com/engine/swarm/) overlay networks have always been enough for me in this regard, though some people enjoy other solutions, such as Hashicorp Consul (https://www.consul.io/), or maybe something intended for Kubernetes or other platforms that you already may be using, like Linkerd (https://linkerd.io/).
Finally, you have your actual application with its server. Personally, i think that the web server should be embedded (for example, embedded Tomcat with Spring Boot) or indeed just be a library that's a part of the…
You fail to address the core point of the parent: a no-GC language like Rust does not compete in the same space as Go.
You either need the low overhead of no-GC or you don't. If you don't, choosing Rust is a mistake.
---
As for your examples, I'm familiar with the Discord rewrite and I looked up the Linkerd2 proxy. Both programs are low-level services that are designed to handle as much load as possible, so yeah they should be written in a non-GC language.
---
> Linkerd2 proxy was written in Rust, despite Linkerd 2 being written in Go.
From [2]:
"The decision to use Rust came down to several factors. First, a service mesh proxy has some pretty stringent requirements: because it’s deployed as a sidecar on a per-pod basis, it has to have as small a memory and CPU footprint as possible. Because most or all of the application’s network traffic flows through the proxy, it needs to have minimal latency overhead, especially worst-case tail latency."
This should obviously be written in a non-GC'd language.
---
> The famous rewrite from Go into Rust done by Discord for their microservices.
> microservice**s**
Nope, just one microservice; at least according to the article ([1]).
From the article:
"In order to get quick atomic counter updates, each Read States server has a Least Recently Used (LRU) cache of Read States. There are millions of Users in each cache. There are tens of millions of Read States in each cache. There are hundreds of thousands of cache updates per…
> Facilities that linkerd provides to assist with this include service discovery, load balancing, encryption, tracing and logging, handling retries, expiration and timeouts, back-offs, dynamic routing, and metrics.
Why not use SRV records and TLS? Retries, expiration, timeouts, and back-offs can all be placed into the networking library, and are, commonly.
Also, regarding https://linkerd.io/, what's with landing pages having almost no useful information on them. "linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications" what's that even mean?
> Fast, lightweight, and performant
> Handles tens of thousands of requests per second per instance with minimal latency overhead. Scales horizontally with ease.
Well, since you're calling yourself "transparent" I would hope it'd be fast!
> Any language, any environment
> Runs as a transparent proxy alongside existing applications, integrates with existing infrastructure.
So, it's just proxying and retrying things and doing tls for me? Why isn't this better handled in the library I'm using to make the call in the first place?
> Latency-aware load-balancing
> Balances request traffic using real-time performance, reducing tail latencies across your application.
Sounds like it requires a lot of cross-talk on my network, eating up bandwidth. That doesn't sound lightweight.
> Runtime traffic routing
> Provides dynamic, scoped, logical routing rules,…
The service mesh is a bit different from an API gateway -- in it's current most popular implementations (linkerd[0] & Istio[1]), there are basically small programs that run next to each individual instance of the programs you want to run. Linkerd has been around for a while and IMO there weren't that many companies that were at a scale where they needed it (I didn't see it deployed that often), but it's basically that same concept, but on a more granular level -- if you delegate all your requests to some intermediary, then the intermediaries can deal with the messy logic and tracing so your program doesn't have to.
A better way to describe is "smart pipes, dumb programs". Imagine that all your circuit-breaking/retry/etc robustness logic was moved into another process that happened to be running right next to the program actually doing the work.
You can have both an API gateway and a service mesh deployment -- for example Kong's Service Mesh[2] works this way. They're saying stuff like "inject gateway functionality in your service", but that only make sense if you sent literally every request (whether intra-service or to/from the outside world) through the gateway. Maybe that's how some people used Kong but I don't think everyone thought of API gateways as a place to send every single request through. You'll have a Kong API gateway at the edge and the kong proxies (little programs that you send all your requests through) next to every compute workload.
[0]:…
Buoyant | San Francisco | Full Time | https://jobs.lever.co/buoyant
Buoyant builds open source, mission critical service mesh software (e.g. https://linkerd.io) that powers the production infra of companies around the world. Our mission is to democratize reliability and security in an increasingly complex system infrastructure landscape, by giving everyone the power to write safe, reliable software--not just the big tech companies.
We are Series A funded with a small engineering team and a modern tech stack (Go, Rust, Scala, React, Kubernetes, etc). We have strong values, a dynamic, diverse team, and awesome investors (Benchmark, SV Angel). Come help us build a company we can be proud of!
Positions:
Sr. Software Engineer, Full Stack - https://jobs.lever.co/buoyant/7e3b072c-1204-4e5f-ae57-100892b1d564
Sr. Software Engineer, Tools and Performance - https://jobs.lever.co/buoyant/01011edf-e9c8-446a-9fbe-4a87865b109c
Sr. Software Engineer, Systems - https://jobs.lever.co/buoyant/7a64f7d1-6fea-40b1-ba52-5ab44802c5f6
Software Engineer, Developer Advocate & Evangelist - https://jobs.lever.co/buoyant/2a638b1d-665d-48e8-b0bb-8d661acbaaef
To be clear, NATS is not a heavy messaging broker like RabbitMQ. For one, it's in-memory only, and queues only exist when there are consumers: If you publish and there are no subscribers, the message doesn't go anywhere. NATS is closer to ZeroMQ than RabbitMQ or Kafka.
A lot of people use HAProxy to route messages via HTTP to microservices — what's HAProxy if not a glorified message queue?
If you don't use an intermediate — meaning you to point-to-point HTTP between one microservice and another — you have to find a way to discover peers, perform health checks, load-balance between them, and so on. Which you can do — services like etcd and Consul exist for this — but using an intermediary such as NATS or Linkerd [1] is also a great, possibly simpler solution.
[1] https://linkerd.io/