Linkerd: Twitter-Style Operability for Microservices(blog.buoyant.io) |
Linkerd: Twitter-Style Operability for Microservices(blog.buoyant.io) |
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.
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.
It's silly and ridiculous but necessary because of the way patents are enforced.
I can promise you that the existence of the patent system did not motivate us to build any of that software, but it certainly motivated us to patent it after the fact, so that someone else couldn't patent it and then sue us for having independently built the same thing.
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.
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#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...)
- circuit breaking (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.
Really wish they expressed the cost in man-years. It's a few calendar years, and thousands of man-years.
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.
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 but it's going to be a long time before I even get marginally close to something as powerful as Google has.
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), which provides this featureset internally at Twitter, primarily for Thrift.
It seems like there's overlap beyond lack of HTTP/2 support, where some of Finagle's features are handled by GRPC in different ways. I'd quite like to use the GRPC way, since Google is maintaining the bindings to many languages, and doing a decent job.
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.
So far all our work has been JSON-over-HTTP, which is not performant. We've looked at gRPC and Thrift, but we've been dreading the prospect of having to pre-declare IDL, generate language glue and write client/server setup glue for every app.
At the moment, we're closing in on using NATS as a routing proxy, fulfilling a role very similar to Linkerd. Turns out it's fast enough that you can do RPC with it, and it seems very reliable. Language bindings are good to the point where you have to write almost no glue code. You have to pick a serialization format, and I think Msgpack might work well here.
But we're slowly moving towards a setup where we'll likely rely on autoscaling, and where we will likely need a more robust architecture.