News for hackers. Stuff that matters.
Re:Linkerd: Twitter-Style Operability for Microservices by lobster_johnson on Sunday February 21, 2016 @12:04PM (#11145272)
[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.

Re:Linkerd: Twitter-Style Operability for Microservices by chuhnk on Sunday February 21, 2016 @12:13PM (#11145324)
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.
Re:Linkerd: Twitter-Style Operability for Microservices by lobster_johnson on Sunday February 21, 2016 @12:24PM (#11145393)
I see. My fault for going straight to the Github repo rather than to linkerd.io.
Re:Linkerd: Twitter-Style Operability for Microservices by williamallthing on Sunday February 21, 2016 @12:43PM (#11145482)
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.

Re:Linkerd: Twitter-Style Operability for Microservices by lobster_johnson on Sunday February 21, 2016 @12:55PM (#11145542)
Yup. I do wish there were more work done on the actual client/server side (the P and C of "RPC"), too, something Linkerd can't solve for you, and which I believe Finagle does.

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.

Re:Linkerd: Twitter-Style Operability for Microservices by williamallthing on Sunday February 21, 2016 @03:01PM (#11146181)
I'm curious to hear what your experience with NATS will be. We haven't played with it. I do know that a ton of the work that went into Finagle was around resilience at scale: things like backpressure, circuit breaking, and generally tolerating slow, bad, or flapping servers. Personally I would want to see that sort of thing in any RPC system before using it at scale.
Re:Linkerd: Twitter-Style Operability for Microservices by lobster_johnson on Sunday February 21, 2016 @03:06PM (#11146204)
We're a small shop; each of our clusters are currently a couple dozen static servers at most. So we don't really do anything at what would be considered "at scale". For us, developer ease of use and performance is a higher priority.

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.