Hacker News Reader

Comment by blibble | Hacker News Reader

could someone explain the purpose behind this software? nearly all of the features it provides should belong in the HTTP client itself

it seems unlikely that you make your software faster or more reliable by adding more hops

View on HN

Well, we have a dozen+ services running in a container platform and when (a) trying to present a uniform API to the outside world with versioning in the URL, (b) managing internal service discovery and (c) doing A-B testing + blue/green deployments, this gets tricky. Especially when you want to try and be event-driven and monitor service lifecycle events.

We could test out Kong, Consul, Fabio, and forget the event-driven callbacks; We could use Route 53 and ELBs; or we could just use Linkerd to drive this and get some pooling features and monitoring features as well.

I think of it as a layer both on top of the services and also a pool that the services swim around in and it ensures that there's one place to manage traffic, the services don't have to care how to do service discovery for other services and it's all being load balanced at a reasonable price.

things like naming, load balancing and service discovery can be done by a well managed dynamic dns system

monitoring / "circuit breakers" would probably require a proxy I guess

The CNCF also has [coredns.io](https://coredns.io/), which I think fits the use-case you describe well. I actually really like the concept behind linkerd, it makes a lot of sense when used in conjunction with Kubernetes.

Speaking as someone who has successfully implemented service discovery and load balancing using DNS and DNSSRV, let me emphatically state that these are not the right tools for the job. They are slow, client support is so variable it can only be called broken, and they're extremely difficult to rationalize and debug.

as a counter example I've implemented it myself for non-trivial systems using short TTL SRV records, and it's worked very well indeed

you can use existing tools to introspect state (e.g. dig), and with sufficient logging it's perfectly debuggable

> well managed dynamic dns system

oxymoron?

Yeah, that's the problem typically. In most large corps the DNS is broken and difficult to change.

linkerd contains some advanced features, that are not easily solvable with DNS.

By sending specific headers (and having your application forward them) one can have per request routing[1] and/or tracing[2].

[1] https://blog.buoyant.io/2016/11/04/a-service-mesh-for-kubern...

[2] https://blog.buoyant.io/2017/03/14/a-service-mesh-for-kubern...

I'm curious. You have a dozen+ services running in a container platform. How many people/teams run software on this platform? How many customers use this platform? How much money does this platform make?

So I work for a very large company, and there's many projects going on throughout the business. This only describes one particular project, but the entire system is a multi-billion £ business, and this project is replacing the customer-facing part of the system, so it will ultimately serve hundreds of thousands, possibly millions of customers. There are about 30-40 projects in the business that I know of, and there about 25 infrastructure/platform engineers working on these projects.

Envoy is a similar piece of software, and it is also on the Hacker News front page with much more discussion (https://news.ycombinator.com/item?id=14194026)

Read William's post entitled "What's a service mesh?": https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-...

You might like this post: https://blog.buoyant.io/2017/01/31/making-things-faster-by-a...

Reply on news.ycombinator.com