4 ms·

> Facilities that linkerd provides to assist with this include service discovery, load balancing, encryption, tracing and logging, handling retries, expiration

> 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/ 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, enabling blue-green deployments, staging, canarying, failover, and more. OK, some of that does sound useful, but some of it still feels like something the caller should handle. > Drop-in service discovery > Integrates with most service discovery systems, decoupling applications from specific implementations. What's this mean? Why not just use SRV records? > Production-tested and proven at scale > Powers the production infrastructure of banks, artificial intelligence companies, social networks, government labs, and more. I know why this is here, but it feels like _everyone_ claims the same thing, so, to me, it just becomes noise. > "linkerd allows you to drop in a transparent layer of application resilience and provides the operational affordances critical for modern, cloud native environments." > —Oliver Gould, CTO, Buoyant This sounds doesn't make sense to me, you can't "drop in" resiliency. It needs to be built. The whole thing just feels like it's all marketing and doesn't tell me exactly what problems it's solving for me as a developer. ------------ Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving.

cookiecaper 10y ago
Disclaimer: I'm still researching linkerd and haven't tried to use it. One component we're interested in is its "automatic" tracing. It claims to be able to annotate requests with Zipkin stats without requiring any instrumentation at the software level. You are correct that other solutions exist for service discovery, but that's an in-demand feature right now as well, and afaik the main reason that people use linkerd. >Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving. Quick, turn back now from this whole containerization thing, because I assure you this is basically the answer for everything in this space. And you will be aggressively accused of being an old fogie for resisting it. Simplicity is just not appreciated anymore; at this point, "containers" may as well be an antonym for it (and by extension, an antonym for "sane engineering").
- jimktrains2 10y ago
  I'm personally a big BSD jails fan. The idea of containerization is nice, but people often forget that it requires tooling and care, just like anything. And isn't a magic bullet
daenney 10y ago
> > 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. Why does that require eating bandwidth? It's a proxy. It can derive statistics from past and current connections and make decisions based on that data for new ones without talking to anyone else. > Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving. So? If you're happy with your solution, keep it! But maybe others haven't solved all these problems, or don't like your approach to how you've solved them for other reasons or don't even want to spend time solving these problems in the first place. For many a component like this means it's 10 less things to deal with and more time to focus on building features that'll matter to their end users. Besides, just because it can already be solved doesn't mean it's not worth trying out other approaches.

cookiecaper 10y ago

Disclaimer: I'm still researching linkerd and haven't tried to use it. One component we're interested in is its "automatic" tracing. It claims to be able to annotate requests with Zipkin stats without requiring any instrumentation at the software level. You are correct that other solutions exist for service discovery, but that's an in-demand feature right now as well, and afaik the main reason that people use linkerd. >Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving. Quick, turn back now from this whole containerization thing, because I assure you this is basically the answer for everything in this space. And you will be aggressively accused of being an old fogie for resisting it. Simplicity is just not appreciated anymore; at this point, "containers" may as well be an antonym for it (and by extension, an antonym for "sane engineering").

jimktrains2 10y ago
I'm personally a big BSD jails fan. The idea of containerization is nice, but people often forget that it requires tooling and care, just like anything. And isn't a magic bullet

daenney 10y ago

> > 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. Why does that require eating bandwidth? It's a proxy. It can derive statistics from past and current connections and make decisions based on that data for new ones without talking to anyone else. > Maybe I'm just an old fogie, or being dense, but I still don't see how this solves any problems I can't and aren't already solving. So? If you're happy with your solution, keep it! But maybe others haven't solved all these problems, or don't like your approach to how you've solved them for other reasons or don't even want to spend time solving these problems in the first place. For many a component like this means it's 10 less things to deal with and more time to focus on building features that'll matter to their end users. Besides, just because it can already be solved doesn't mean it's not worth trying out other approaches.