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.
