11 ms·

Linkerd: Twitter-Style Operability for Microservices

136 points by samkone 11y ago

brown9-2 11y ago
The "sidecar" proxy model reminds me a lot of https://github.com/airbnb/synapse https://github.com/airbnb/synapse
- chuhnk 11y ago
  Netflix have something similar https://github.com/Netflix/Prana https://github.com/Netflix/Prana and I've got a Sidecar in Micro too https://github.com/micro/micro/tree/master/car https://github.com/micro/micro/tree/master/car. It's a solid model for integrating applications which you don't necessarily have client libraries for or don't speak the same protocol.
- olix0r 11y ago
  We definitely took some inspiration from projects like synapse. However, Finagle, the core tech behind linkerd, provides some extremely powerful tools to do things like: - per-request routing to support things like "when I browse the site, use the staging version of the users service and production versions of all other services". (https://twitter.github.io/finagle/guide/Names.html#interpreting-paths-with-delegation-tables https://twitter.github.io/finagle/guide/Names.html#interpret...) - request cancellation, so that when a user request timeouts downstream work can be reclaimed - budget-based timeout management (https://twitter.github.io/finagle/guide/Servers.html#request-deadline https://twitter.github.io/finagle/guide/Servers.html#request...) - circuit breaking (https://twitter.github.io/finagle/guide/Clients.html#failure-accrual https://twitter.github.io/finagle/guide/Clients.html#failure...) - etc, etc. We think that offering these sorts of features in a sidecar model will be extremely powerful.
mochamadrochim 11y ago
Tolong dipercepat.
yeukhon 11y ago
Suppose I designed something from scratch at former company, and then I decided to reimplement the same project after leaving the company (and perhaps turn that into an open source project), with mostly new code, but similar concept, would that be considered copyright infringement?
- Illniyar 11y ago
  I doubt it will be "copyright infringement" since the code was rewritten. It might fall under patent infringment if something was patented. The more likely scenario is that it will constitute a misuse of trade secret either under law or from the contract signed on employment. I am not a lawyer and the law is different in every place but it is likely that such a use would be protected under paw by protections given to professionals to retain expertease gained while practicing their professions. I don't remember how that protection is called.
- brown9-2 11y ago
  are there a lot of companies in the practice of copyrighting their internal architecture and patterns?
  - njharman 11y ago
    In usa everything that is copyrightable, becomes copyrighted at moment it is created. For instance that sentence, and this on, are protected works owned by me. The only reAson HN can legally use then is cause I gave them license, buried somewhere in Eula/site terms of use. Also, an architecture is not copyrightable. Maybe patentable. Copyrights protect specific expressions, not a general idea, plan, or architecture. At least not yet thankfully I haven't seen anyone try to argue an unrelated software doing same thing is a derivative work.
    - mavelikara 11y ago
      But Twitter has a patent pledge with its engineers [1]: The IPA is a new way to do patent assignment that keeps control in the hands of engineers and designers. It is a commitment from Twitter to our employees that patents can only be used for defensive purposes. We will not use the patents from employees’ inventions in offensive litigation without their permission. What’s more, this control flows with the patents, so if we sold them to others, they could only use them as the inventor intended. [1]: https://blog.twitter.com/2012/introducing-the-innovator-s-patent-agreement https://blog.twitter.com/2012/introducing-the-innovator-s-pa...
sulam 11y ago
This is actually closer to Google-Style operability than it is to Twitter-Style operability. :) Twitter doesn't have an equivalent of GSLB (software load balancer), which is essentially what this is.
- chuhnk 11y ago
  Have you seen Google's GSLB? It's not a proxy and it's a rather complex and powerful system. It aggregates and coordinates traffic flow but doesn't directly do any kind of forwarding. You could maybe think of Linkerd like GFE but even still, GFE acts as an edge gateway rather than internal RPC system. This is like a wrapper around stubby or grpc.
  - jamescun 11y ago
    Do you have any public resources about Google's GSLB? Searching for it results in general articles about GSLB.
    - chuhnk 11y ago
      I've only ever found two things publicly available on this. The patent related to DNS GSLB http://www.google.com/patents/US7581009 http://www.google.com/patents/US7581009 and the video by Simon Newton which describes the global footprint and some of the services https://www.youtube.com/watch?v=DWpBNm6lBU4 https://www.youtube.com/watch?v=DWpBNm6lBU4. Most of what I know about GSLB is from my time working at Google.
  - lobster_johnson 11y ago
    Is GSLB different from Google Seesaw, the load balancer that was open-sourced recently?
    - chuhnk 11y ago
      Yea, it's a completely different use case. Internally Google has something called Maglev which looks a little more like Seesaw but even still its quite different. I haven't actually seen anything like GSLB anywhere else. With classic load balancing we've always been taught to proxy traffic through a single point of entry. GSLB flips that on its head and rather provides routing information which clients can then use for the next set of requests. I'm attempting to develop something similar within https://github.com/micro https://github.com/micro but it's going to be a long time before I even get marginally close to something as powerful as Google has.
Hacker03 11y ago
Hi My Hacker
Hacker03 11y ago
Hi :) ;)
hboon 11y ago
Totally unrelated: the effect/animation when you hover over the avatars (Safari) at https://buoyant.io/#team https://buoyant.io/#team is really weird. Not sure if it's intentional.
- hmottestad 11y ago
  It's fine in Chrome, but in Safari it's very jittery and animates the wrong images.
- olix0r 11y ago
  This was not intentional. Thanks for pointing this out.
lobster_johnson 11y ago
[Edit: Apparently this is language-agnostic, which wasn't clear from the blog post, so please ignore the complaints below. Will leave them here rather than deleting.] I loved the pitch, but then I discovered that this is Scala only, which was disappointing. Sure, if your entire organization runs on the JVM (like Twitter presumably does), then something like this is going to be fine. But many/most organizations use multiple languages, for various reasons. At my company we are currently looking into replacing our current microservie RPC (JSON over HTTP) with something better, and we do need to support Ruby, Go and Node.js, as well as plain HTTP from browsers. The only viable cross-platform RPC technologies right now are gRPC and Thrift, both of which are rather heavy-handed (lots of IDL + code generation + client/server setup code), and neither of which solve the really hard problems (discoverability, load balancing, fault tolerance, etc.). It's also doubtful that gRPC is really in a usable state yet. Thrift is by far the most mature solution in this space. Maybe we'll be able to take some inspiration from this project when building our upcoming solution, whatever it will be.
- chuhnk 11y ago
  No no, you're missing the point, it's an RPC proxy which is language agnostic. It sits along side your application as opposed to being a library that you bake in.
  - lobster_johnson 11y ago
    I see. My fault for going straight to the Github repo rather than to linkerd.io.
    - williamallthing 11y ago
      We can definitely improve the docs a bit on this point. But FWIW we totally agree with you. Finagle itself is a JVM library, and that worked well enough at Twitter [insert caveats here], but a big part of the reason we built linkerd is extending that model to non-JVM / polyglot services. There's SO much good stuff in Finagle... it would be a pity to confine it just to the JVM.
lobster_johnson 11y ago
Looks like the support protocols right now are HTTP, Thrift (framed transport) and something called Mux. Is this intended to be pluggable?
- williamallthing 11y ago
  Yup, absolutely. Any requests? :)
  - lobster_johnson 11y ago
    Cool! Is HTTP/2.0 already there, or planned? I think HTTP/2.0 is important to get proper pipelining of asynchronous calls.
    - olix0r 11y ago
      We agree 100% that multiplexing is vital. HTTP/2 is absolutely on the roadmap. We're actively working with some of the folks at Twitter to get it integrated and tested before introducing it into linkerd. That said, linkerd is able to provision multiple downstream connections to multiplex requests to other services; but we need to extend this to the serverside to get the best application integration. You may also be interested in Twitter's mux protocol (https://twitter.github.io/finagle/guide/Protocols.html#mux https://twitter.github.io/finagle/guide/Protocols.html#mux), which provides this featureset internally at Twitter, primarily for Thrift.
  - sayrer 11y ago
    GRPC. It's really the only practical choice if you have Go, Node.js, and PHP apps that need to consume one central service. It also has a lot of the benefits that Mux brings.
    - olix0r 11y ago
      Luckily GRPC can downgrade to HTTP/1.1, so if you want some of linkerd's features it isn't a total non-starter; but this is obviously less-than-desirable. We're working with the finagle team to complete finagle's netty4 integration, which will enable us to transparently introduce netty's http/2 codec into linkerd. This is a high-priority feature.
djtriptych 11y ago
"It can be done, but it takes years of thought and work to make everything work well in practice." Really wish they expressed the cost in man-years. It's a few calendar years, and thousands of man-years.
eikenberry 11y ago
This is a good step forward for Finagle as it eliminates the anti-pattern of encapsulating the communications functionality into a library. This inevitably turns any collection of services into a distributed monolith, killing the loose coupling that is the point.

136 points by samkone 11y ago

brown9-2 11y ago

The "sidecar" proxy model reminds me a lot of https://github.com/airbnb/synapse https://github.com/airbnb/synapse

chuhnk 11y ago
Netflix have something similar https://github.com/Netflix/Prana https://github.com/Netflix/Prana and I've got a Sidecar in Micro too https://github.com/micro/micro/tree/master/car https://github.com/micro/micro/tree/master/car. It's a solid model for integrating applications which you don't necessarily have client libraries for or don't speak the same protocol.
olix0r 11y ago
We definitely took some inspiration from projects like synapse. However, Finagle, the core tech behind linkerd, provides some extremely powerful tools to do things like: - per-request routing to support things like "when I browse the site, use the staging version of the users service and production versions of all other services". (https://twitter.github.io/finagle/guide/Names.html#interpreting-paths-with-delegation-tables https://twitter.github.io/finagle/guide/Names.html#interpret...) - request cancellation, so that when a user request timeouts downstream work can be reclaimed - budget-based timeout management (https://twitter.github.io/finagle/guide/Servers.html#request-deadline https://twitter.github.io/finagle/guide/Servers.html#request...) - circuit breaking (https://twitter.github.io/finagle/guide/Clients.html#failure-accrual https://twitter.github.io/finagle/guide/Clients.html#failure...) - etc, etc. We think that offering these sorts of features in a sidecar model will be extremely powerful.

mochamadrochim 11y ago

Tolong dipercepat.

yeukhon 11y ago

Suppose I designed something from scratch at former company, and then I decided to reimplement the same project after leaving the company (and perhaps turn that into an open source project), with mostly new code, but similar concept, would that be considered copyright infringement?

Illniyar 11y ago
I doubt it will be "copyright infringement" since the code was rewritten. It might fall under patent infringment if something was patented. The more likely scenario is that it will constitute a misuse of trade secret either under law or from the contract signed on employment. I am not a lawyer and the law is different in every place but it is likely that such a use would be protected under paw by protections given to professionals to retain expertease gained while practicing their professions. I don't remember how that protection is called.
brown9-2 11y ago
are there a lot of companies in the practice of copyrighting their internal architecture and patterns?
- njharman 11y ago
  In usa everything that is copyrightable, becomes copyrighted at moment it is created. For instance that sentence, and this on, are protected works owned by me. The only reAson HN can legally use then is cause I gave them license, buried somewhere in Eula/site terms of use. Also, an architecture is not copyrightable. Maybe patentable. Copyrights protect specific expressions, not a general idea, plan, or architecture. At least not yet thankfully I haven't seen anyone try to argue an unrelated software doing same thing is a derivative work.
  - mavelikara 11y ago
    But Twitter has a patent pledge with its engineers [1]: The IPA is a new way to do patent assignment that keeps control in the hands of engineers and designers. It is a commitment from Twitter to our employees that patents can only be used for defensive purposes. We will not use the patents from employees’ inventions in offensive litigation without their permission. What’s more, this control flows with the patents, so if we sold them to others, they could only use them as the inventor intended. [1]: https://blog.twitter.com/2012/introducing-the-innovator-s-patent-agreement https://blog.twitter.com/2012/introducing-the-innovator-s-pa...

sulam 11y ago

This is actually closer to Google-Style operability than it is to Twitter-Style operability. :) Twitter doesn't have an equivalent of GSLB (software load balancer), which is essentially what this is.

chuhnk 11y ago
Have you seen Google's GSLB? It's not a proxy and it's a rather complex and powerful system. It aggregates and coordinates traffic flow but doesn't directly do any kind of forwarding. You could maybe think of Linkerd like GFE but even still, GFE acts as an edge gateway rather than internal RPC system. This is like a wrapper around stubby or grpc.
- jamescun 11y ago
  Do you have any public resources about Google's GSLB? Searching for it results in general articles about GSLB.
  - chuhnk 11y ago
    I've only ever found two things publicly available on this. The patent related to DNS GSLB http://www.google.com/patents/US7581009 http://www.google.com/patents/US7581009 and the video by Simon Newton which describes the global footprint and some of the services https://www.youtube.com/watch?v=DWpBNm6lBU4 https://www.youtube.com/watch?v=DWpBNm6lBU4. Most of what I know about GSLB is from my time working at Google.
- lobster_johnson 11y ago
  Is GSLB different from Google Seesaw, the load balancer that was open-sourced recently?
  - chuhnk 11y ago
    Yea, it's a completely different use case. Internally Google has something called Maglev which looks a little more like Seesaw but even still its quite different. I haven't actually seen anything like GSLB anywhere else. With classic load balancing we've always been taught to proxy traffic through a single point of entry. GSLB flips that on its head and rather provides routing information which clients can then use for the next set of requests. I'm attempting to develop something similar within https://github.com/micro https://github.com/micro but it's going to be a long time before I even get marginally close to something as powerful as Google has.

Hacker03 11y ago

Hi My Hacker

Hacker03 11y ago

Hi :) ;)

hboon 11y ago

Totally unrelated: the effect/animation when you hover over the avatars (Safari) at https://buoyant.io/#team https://buoyant.io/#team is really weird. Not sure if it's intentional.

hmottestad 11y ago
It's fine in Chrome, but in Safari it's very jittery and animates the wrong images.
olix0r 11y ago
This was not intentional. Thanks for pointing this out.

lobster_johnson 11y ago

[Edit: Apparently this is language-agnostic, which wasn't clear from the blog post, so please ignore the complaints below. Will leave them here rather than deleting.] I loved the pitch, but then I discovered that this is Scala only, which was disappointing. Sure, if your entire organization runs on the JVM (like Twitter presumably does), then something like this is going to be fine. But many/most organizations use multiple languages, for various reasons. At my company we are currently looking into replacing our current microservie RPC (JSON over HTTP) with something better, and we do need to support Ruby, Go and Node.js, as well as plain HTTP from browsers. The only viable cross-platform RPC technologies right now are gRPC and Thrift, both of which are rather heavy-handed (lots of IDL + code generation + client/server setup code), and neither of which solve the really hard problems (discoverability, load balancing, fault tolerance, etc.). It's also doubtful that gRPC is really in a usable state yet. Thrift is by far the most mature solution in this space. Maybe we'll be able to take some inspiration from this project when building our upcoming solution, whatever it will be.

chuhnk 11y ago
No no, you're missing the point, it's an RPC proxy which is language agnostic. It sits along side your application as opposed to being a library that you bake in.
- lobster_johnson 11y ago
  I see. My fault for going straight to the Github repo rather than to linkerd.io.
  - williamallthing 11y ago
    We can definitely improve the docs a bit on this point. But FWIW we totally agree with you. Finagle itself is a JVM library, and that worked well enough at Twitter [insert caveats here], but a big part of the reason we built linkerd is extending that model to non-JVM / polyglot services. There's SO much good stuff in Finagle... it would be a pity to confine it just to the JVM.

lobster_johnson 11y ago

Looks like the support protocols right now are HTTP, Thrift (framed transport) and something called Mux. Is this intended to be pluggable?

williamallthing 11y ago
Yup, absolutely. Any requests? :)
- lobster_johnson 11y ago
  Cool! Is HTTP/2.0 already there, or planned? I think HTTP/2.0 is important to get proper pipelining of asynchronous calls.
  - olix0r 11y ago
    We agree 100% that multiplexing is vital. HTTP/2 is absolutely on the roadmap. We're actively working with some of the folks at Twitter to get it integrated and tested before introducing it into linkerd. That said, linkerd is able to provision multiple downstream connections to multiplex requests to other services; but we need to extend this to the serverside to get the best application integration. You may also be interested in Twitter's mux protocol (https://twitter.github.io/finagle/guide/Protocols.html#mux https://twitter.github.io/finagle/guide/Protocols.html#mux), which provides this featureset internally at Twitter, primarily for Thrift.
- sayrer 11y ago
  GRPC. It's really the only practical choice if you have Go, Node.js, and PHP apps that need to consume one central service. It also has a lot of the benefits that Mux brings.
  - olix0r 11y ago
    Luckily GRPC can downgrade to HTTP/1.1, so if you want some of linkerd's features it isn't a total non-starter; but this is obviously less-than-desirable. We're working with the finagle team to complete finagle's netty4 integration, which will enable us to transparently introduce netty's http/2 codec into linkerd. This is a high-priority feature.

djtriptych 11y ago

"It can be done, but it takes years of thought and work to make everything work well in practice." Really wish they expressed the cost in man-years. It's a few calendar years, and thousands of man-years.

eikenberry 11y ago

This is a good step forward for Finagle as it eliminates the anti-pattern of encapsulating the communications functionality into a library. This inevitably turns any collection of services into a distributed monolith, killing the loose coupling that is the point.