Re: RSocket Followup (post TOC meeting)
alexis richardson
Tim,
Thanks! I think we would all be interested in your reasons for liking gRPC.
alexis
On Sat, Aug 11, 2018 at 4:07 AM, via Lists.Cncf.Io
<tim=netflix.com@...> wrote:
Thanks! I think we would all be interested in your reasons for liking gRPC.
alexis
On Sat, Aug 11, 2018 at 4:07 AM, via Lists.Cncf.Io
<tim=netflix.com@...> wrote:
I see Kailash CCd me into the thread given Netflix's experience with both
RSocket and gRPC.
It should be noted that at this point (as of roughly 6 months ago) all use
of RSocket has been completely abandoned at Netflix in favor of gRPC, and
the only team that build an app with RSocket chose to rewrite their app
leveraging gRPC and the associated components. gRPC has also allowed us to
build (and easily integrate) a suite of resilience-oriented tech, such as
our Adaptive Concurrency Limiters
(https://medium.com/@NetflixTechBlog/performance-under-load-3e6fa9a60581)
that solve the retry-storm problem with no additional client-side complexity
or configuration.
While I am not best-suited to address statements on the matrix of specific
points being discussed, if anyone has questions, I can speak to the many
usability/ergonomic, simplicity, community, and
development-velocity/productivity related reasons that ultimately led
Netflix (both the Platform team, and the users) to choose gRPC as our
microservice RPC foundation.
Tim Bozarth
Director, Platform @ Netflix
On Thu, Aug 9, 2018 at 10:52 AM, Kailash Sethuraman <hsaliak@...>
wrote:
Adding Tim Bozarth from Netflix, who's had some practical experience
working with both gRPC and RSocket. Full thread here:
https://lists.cncf.io/g/cncf-toc/topic/rsocket_followup_post_toc/24221841
+1 to a public feature comparison table.
In such a table, it will be good to figure out how to do justice to
deliberate design choices and the tradeoffs. For example, broker vs
no-broker, or choosing to base on top of http/2. Projects have valid reasons
to go one way or another, and those considerations are very beneficial for
the user to understand.
FYI : I saw a few minor misconceptions for gRPC and I have called out a
few that stood out.:
- binary - must be wrapped in protobuf. This is not necessary, though
offers a convenience. There are other formats (eg: flatbuffers) that
support gRPC service generation.
- max payload size is confiugrable
- full duplex -- not sure what this means. gRPC supports bi directional
streams.
- IPC is not protobuf only.
On Wed, Aug 8, 2018 at 3:45 PM <colin@...> wrote:
Reading through the responses, imo this speaks to a need for a public
project feature comparison I mentioned elsewhere in this thread
(https://lists.cncf.io/g/cncf-toc/message/2192).