Re: peanut-gallery thoughts about GRPC


alexis richardson
 

Jayant

Many thanks.



On Tue, Oct 25, 2016 at 4:50 PM, Jayant Kolhe <jkolhe@...> wrote:

gRPC protocol was designed to build high performance, cross platform and usable libraries for building microservices. It was designed on top of HTTP2 to explicitly make use of
  • Full duplex streams to support bi-directional streaming
  • HPACK compressed headers for efficiently transmitting metadata/sidechannel information. For example, reduces cost for authentication tokens
  • Connection multiplexing. Reduces the per-RPC connection cost for TLS and high latency connections
  • Binary Framing layer with good flow control


Many of gRPC features work well only on HTTP2 semantics.


Can you please list which ones are notable?  The main one seems to be "streaming" replies.  This shouldn't prevent someone building a http 1 compatibility layer, if that what helps people with adoption.





 
While implementing gRPC on top of HTTP1.1 downgrade is feasible, such implementation would lose many of gRPC advantages of efficient usage of network resources and high performance.

How much does that matter to real world users for the practical cases that such an implementation would facilitate?


 
It would add significant complexity across multiple language implementations and would have higher bar and complexity for implementing and testing interoperability across these implementations.

I'm sure we can find CNCF community engineers who would be willing and able to have a go.  How hard can it be?




 
We have also relied on adoption of HTTP2 which has been very rapid and hence the ecosystem is also evolving rapidly to support HTTP2 features.

I'm interested to understand how you measure this.


 
We have also relied on proxies to provide this functionality to allow http1.x only ecosystem to work with gRPC. Such support exists in many proxies (nghttpx, linkerd, envoy) and is coming to others like nginx..Hence we have not implemented gRPC on HTTP 1.x.

Please don't take this the wrong way -- I like gRPC and am excited about it!

But: expecting proxies to solve this stuff, kind of undermines the whole approach.  Not having an obvious Joe User adoption path will impede gRPC from being in some sense universal.  It may also lead to people feeling let down if they hear (a) that gRPC is the new hotness, and that everyone should try it, but (b) it has compatibility problems that may not be resolved.

I vividly recall Brad Fitz telling me back in 2009 (or thereabouts) that, for HTTP, it is prudent to assume the worst when it comes to widespread adoption.  He pointed out that many servers & proxies still spoke 0.9 at the time.  


 


On Fri, Oct 21, 2016 at 11:42 AM, Brian Grant <briangrant@...> wrote:
+Varun and Jayant to answer that

On Fri, Oct 21, 2016 at 10:57 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:

I'd like to understand why gRPC doesn't work with HTTP 1.x


On Fri, 21 Oct 2016, 18:45 Ben Sigelman via cncf-toc, <cncf-toc@...> wrote:
Hi all,

"I am not on the TOC, but" I did want to share a few thoughts about GRPC per the call the other day.

I was recently at one of those moderated VC dinners where everyone gets put on the spot to say something "insightful" (sic) – I'm sure we all know the scenario. Anyway, we had to go around the table and talk about "the one OSS project that's poised to change the way the industry functions". There were lots of mentions of Docker, k8s, etc, and for good reason. I had the bad luck of being last and felt like it wasn't useful to just +1 someone else's comment, and I realized that GRPC was in many ways an excellent answer.

Varun alluded to this in his presentation, but to restate it in different words: the value of an RPC system is mostly not actually about the RPC... it's the service discovery, client-side load balancing, well-factored monitoring, context propagation, and so on.

In that way, a high-quality RPC system is arguably the lynchpin of the "user-level OS" that sits just below the application code but above the actual (kernel) syscalls. An alternative approach moves things like RPC into its own process (a la linkerd(*)) and I think that makes sense in certain situations... but when the RPC system depends on data from its host process beyond the RPC payload and peer identity (which is often the case for more sophisticated microservice deployments), OR when "throughput matters" and extra copies are unacceptable, an in-process RPC subsystem is the right approach.

As for whether GRPC is the right in-process RPC system to incubate: I think that's a no-brainer. It has good momentum, the code is of a much higher quality and works in more languages than the alternatives, and Google's decision to adopt it internally will help to ensure that it works within scaled-out systems (both architecturally and in terms of raw performance). Apache Thrift moves quite slowly in my experience and has glaring problems in many languages; Finagle is mature but is limited to JVM (and perhaps bites off more than it can chew at times); other entrants that I'm aware of don't have a strong community behind them.

So yes, this is just an enthusiastic +1 from me. Hope the above makes sense and isn't blindingly obvious. :)

Comments / disagreements welcome –
Ben

(*): re linkerd specifically: I am a fan, and IMO this is a "both/and" situation, not "either/or"...

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc

_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc




Join cncf-toc@lists.cncf.io to automatically receive all group messages.