9 ms·
Linkerd 1.0
- MeteorMarc 10y agoIn dutch "linkerd" means a cunning person with an evil touch.
- emmelaich 10y agoInteresting, Google translate gives 'gauche' which means clumsy/awkward. Which makes sense since 'linker' means left and gauche is French for left. It sounds like linkerd is closer to 'onhandig' - does it really imply an evil touch? (sinister - there we go with the left hand thing again)
- MeteorMarc 10y agoIf you want to use Google translate, first expand with a dutch source and then translate: http://www.encyclo.nl/begrip/linkerd http://www.encyclo.nl/begrip/linkerd 1) Fraud 2) Adult Person 3) Most common guy 4) Convenient guy 5) Linkmichel 6) Nice handy guy 7) Beautiful guy 8) Smooth 9) Smarter 10) Slapped person 11) False nature I prefer my own translation
- emmelaich 10y agoThanks, I should have added I didn't mean to say mine was a better translation. Just musing out loud.
- blibble 10y agocould 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
- thethimble 10y agoRead William's post entitled "What's a service mesh?": https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-...
- bryanlarsen 10y agoEnvoy 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 https://news.ycombinator.com/item?id=14194026)
- vr46 10y agoWell, 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.
- blibble 10y agothings 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
- theossuary 10y agoThe CNCF also has [coredns.io](https://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.
- pbreit 10y agoCould someone explain this in plain english?
- tyingq 10y agoI think the real driver is being "elastic". Renting infrastructure is really expensive if you can't ramp it up and down as demand changes. So, if you're elastic, you now need some dynamic way of finding the various services...they are spinning up and shutting down all the time, so you can't have a static list of IP's and ports. So, some framework that maps questions like "what host and port should I use to connect to the pricing service" is desirable. There can be many instances of that service for scale, and when new ones spin up, they are added to the directory. When existing ones fail, or are purposefully shutdown, they are removed. This is more complex than a normal load balancer, as it has to handle service-to-service connections versus just client connections. And the number of instances of each service is highly dynamic, based on load.
- peterwwillis 10y agoIt's a message bus with a new name.
- tyingq 10y agoA (usually) synchronous one. Like rmi or corba or dcom.
- moondev 10y agoIt's basically a configurable proxy for communication between services. Kubernetes has the concept of "services" which allow you to declare a dns name for service discovery, but it's fairly barebones. By using linkerd, you manage and configure various things like load-balancing strategies, retry-windows, circuit breaking etc etc. Instead of doing these things with a library inside the application like hysterix, you move it to it's own layer. This also has the benefit of being code agnostic, so you can leverage the same service concepts for any type of app. You can also run linkerd outside of kubernetes.
- wyldfire 10y ago> linker∙d is a transparent proxy that adds service discovery, routing, failure handling, and visibility to modern software applications One or more decades ago, these problems were proposed (and solved?) by IETF working groups. I could believe that linkerd offers some new features not considered by those RFCs. But it would be nice if it were extensions of existing protocols instead. Having a transparent proxy could offer a level of convenient integration rarely found among disparate internet protocols. Then again, there might be really good reasons why collapsing too many features into one layer is a bad idea.
- jdc 10y agoWhich RFCs did they propose the solutions in?
- tyingq 10y agoGuessing they mean rfc2165 https://tools.ietf.org/html/rfc2165 https://tools.ietf.org/html/rfc2165 Corba had service location, and I assume many other predecessors did as well. Doesn't bother me though, stuff gets reinvented and rediscovered all the time. The more recent approaches, like linkerd tend to also include ways to easily wrap existing services without changing them, which is a plus.
- wyldfire 10y agoDNS-SD: RFC 6763 Service Location Protocol: RFC 2608 RSerPool: RFCs 5351-6
- wyldfire 10y agoAlso, of notable mention is DDS [1]. It's standardized by OMG (what's not to love about that name?) not IETF. It's a really interesting pub/sub style IPC. But really it's like a swiss-army knife. CORBA lovers (and haters) will recall IDL, it's used as the description for the interfaces used. IMO the commercial implementations are more feature complete than the open source ones. If you looked at CORBA in the 1990s and have a sour taste in your mouth, don't hold it against DDS. It's a really great approach. It describes interfaces with a dynamically negiotiated Quality-of-Service among participants. The set of reactions to QoS policy violations effectively create hooks for all of your interesting cases. IMO DDS works best when all of your participants share a broadcast domain, but it's not necessary to set it up that way. [1] https://en.wikipedia.org/wiki/Data_Distribution_Service https://en.wikipedia.org/wiki/Data_Distribution_Service
- threesixandnine 10y ago'Industrial-strength operability for cloud-native applications' --from the website front page What is a cloud native application?
- cschmittiey 10y ago"The concept of the service mesh as a separate layer is tied to the rise of the cloud native application. In the cloud native model, a single application might consist of hundreds of services; each service might have thousands of instances; and each of those instances might be in a constantly-changing state as they are dynamically scheduled an orchestrator like Kubernetes. Not only is service communication in this world incredibly complex, it’s a pervasive and fundamental part of runtime behavior. Managing it is vital to ensuring end-to-end performance and reliability." https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-why-do-i-need-one/ https://blog.buoyant.io/2017/04/25/whats-a-service-mesh-and-...
- dominotw 10y agoThe cloud native model combines the microservices approach of many small services with two additional factors: containers (e.g. Docker, which provide resource isolation and dependency management, and an orchestration layer (e.g. Kubernetes), which abstracts away the underlying hardware into a homogenous pool.
- peterwwillis 10y agoA container app that depends on 100 other container apps.
- agumonkey 10y agowild guess, the cloud is the machine, and all your application is built on cloud bits connected through and in the cloud
- lclarkmichalek 10y agoAn application I like
- deleted 10y ago
- Gaelan 10y agoThis post does a good job of telling me what linkerd is early on. I don't think a lot of projects realize posts like these are the first many see of the project. Maybe do a check for first visit and perhaps HN referrer?
- dkarapetyan 10y ago> ... service mesh for cloud native applications Need I say more? Paging Alan Kay to tell these folks what the origins of an unnecessary complicated mess looks like.
- moondev 10y agoUnnecessary and complicated for whom? If you don't need circuit breaking, retry windows, metrics, ack/nack and advanced load balancing techniques for your platform then you are not the target market. Nobody is forcing you to use it.
- fernandotakai 10y agoif you have a bunch of thrift servers, linkerd is a must. it really makes handling thrift connections much easier.
- dkarapetyan 10y agoLast I checked all of that was already handled at the TCP level but what do I know. Maybe all of that needs to be reinvented at the application level too just to be extra safe. Everything except the circuit breaking I guess which sounds like something an application should worry about itself instead of offloading to another service. Also don't know what this advanced load balancing business is about. What exactly is wrong with HAProxy? So instead of having composable tools we now have this monster called linkerd. Wishing everyone that needs it in their production systems good luck. I'll be fiddling with my VMs and processes while you guys build "distributed" systems.
- deleted 10y ago[deleted]
- defen 10y agoTo pick one example - TCP will get you automatic retry of sending bytes but it knows nothing about the semantics of the layers built on top of it. If your HTTP request to a backend service fails with a 502 - do you try again on the same server? different server? fail the whole thing that was depending on that HTTP request succeeding? TCP can't answer that question for you because it doesn't even know if you're doing a GET or a POST, or what a 502 means.
- mrmrcoleman 10y agoCongratulations to the team!
- ninkendo 10y agoA lot of people are confused about why something like this is necessary, and IMO it really comes down to one thing: sometimes the stuff you want to talk to moves around. As soon as you're not allowed to rely on the service you talk to saying on the a static set of machines (and even on a static set of ports) over time, using standard HTTP libraries becomes really awkward. (Did this request fail because an instance shut down and I should talk to another one? How do I convince my DNS resolving library to ignore its cache and re-lookup the service? Ok I found 3 instances, which one should I talk to? How do we prevent all the other copies of me from spamming the same instance? Gee, it'd be really nice to have something push a notification to me when the services change!) Not-so coincidentally, this constraint is really common in "cloud native" setups like Kubernetes and Mesos, where service instances come and go as part of normal operation. This is because, in this world you don't update your code by copying new files to some servers and SIGHUP'ing some daemon, you update your code by deploying new containers, waiting for them to be healthy, and tearing down the old ones. This means "failure" is a normal part of your normal software lifecycle. Linkerd is one of many attempts to make "normal software" behave well in this world, without relying on too much intelligence in the HTTP client libraries (or other non-HTTP stuff, for that matter.) In a perfect world, everything would respect and obey DNS SRV records. Oh if only most client software knew what they were, and how to handle them! Right there you can see which backends are available for a service, what ports they're on, what their priorities are, and how long that information should be considered valid. But alas, nothing really supports SRV records. So we need something like this until client software becomes more intelligent (if ever.)
- jmspring 10y agoEven if they did, the issue w/ caching DNS info will possibly still bit one. Java apps is one specific example that comes to mind.
- koolba 10y agoI suppose you could get around that with custom DNS server. Something like xip.io but resolving to the parent and allowing the prefix as a cache buster. Ex: foo.some-delim.baz.bam.example.com would resolve to baz.bam.example.com regardless of the foo prefix. The client could then iterate or randomly generate values for foo to ensure fresh DNS lookups.
- hestefisk 10y agoSo these guys just reinvented a Frankenstein of DNS and UDDI. Nice.
- sudeepj 10y agoIs it conceptually similar to ESB (https://en.wikipedia.org/wiki/Enterprise_service_bus https://en.wikipedia.org/wiki/Enterprise_service_bus)?
- zanchey 10y agohttps://lwn.net/Articles/719282/ https://lwn.net/Articles/719282/ is a good writeup on the features of linkerd in a reasonably easy-to-understand way.
- weavie 10y agoLinkerd, namerd, etcd ... what does the d stand for in all these apps?
- nailer 10y agoShort version: a service discovery, management and communication platform. Helps the instances doing X find and talk to the instances doing Y.
- jp_sc 10y agoI tought it was Linkedin for nerds