Thanks, Louis,

Disappointingly, it seems like we don't actually disagree on much. I'm guessing that the set of applications where you would choose to use GRPC is much larger than mine, and the set of applications where I would choose to use HTTP+JSON is much larger than yours, but we would both acknowledge that both sets are important. 

OpenAPI is just another RPC IDL in my eyes, but since its most common use is just documentation, it doesn't bother me as much. JSON-LD has a different set of goals and seems to me part of a different discussion.

My other point is that you need the same qualities-of-service—service discovery, client-side load balancing, well-factored monitoring, context propagation—for HTTP+JSON that you need for RCP/Messaging. Maybe we could work together on a "G+HTTP+JSON" to provide that :) It would have to be IDL-free.

Martin

On Thu, Oct 27, 2016 at 10:30 AM, Louis Ryan <lryan@...> wrote:

Martin,

Perhaps your understanding of GRPC is based on the name (I do bemoan this choice from time to time) rather than the feature set and intent. I would encourage you to read 

http://www.grpc.io/blog/principles

Specifically the parts about being message oriented not object or function oriented. GRPC is nothing like the solutions you mention for a wide variety of reasons, I see the comparison with CORBA a lot because we use an IDL with protobuf but that's missing the point.

If by loose-coupling you mean the ability to dynamically compose systems based on metadata and linking across a diverse ecosystem of APIs AND you need to do this in a browser then I would agree GRPC is not for you (he K8S config API comes to mind). I would note however that there are relatively few APIs that fall into that category and none that are infrastructural, most APIs are use-case specific and their composition is done by application code with fore-knowledge of the use-case. Mobile application development overwhelmingly falls into this category.

OpenAPI does a better job than JSON-LD and AtomPub in supporting this dynamic composition model but this is in no small part because it standardizes and IDL that can be processed by toolchains as opposed to AtomPub which expected runtimes to make magic happen. The OpenAPI approach is no different than GRPC+Protobuf other than the physical representation.

I wouldn't advocate using GRPC when HTTP+JSON is a better fit for the use-case, far from it, but for many use-cases I do think it is a better tool.

- Louis

P.S Happy to get in the weeds over a beer the next time I see you 

On Thu, Oct 27, 2016 at 9:55 AM, Brian Grant <briangrant@...> wrote:

+adding back the grpc folks to comment

On Wed, Oct 26, 2016 at 5:57 PM, Martin Nally via cncf-toc <cncf-toc@...> wrote:

I'm not personally a fan of RPC, at least for the sort of applications I write. I have lived through several generations of RPC—DCE, Corba, Java RMI, and so on. I'm sure GRPC is the best of the RCPs, but it is still RPC. The problem with RPC for me has always been that it results in wide interfaces that couple clients and servers tightly together. It might be the right choice for some applications, but if you value loose coupling over implementation efficiency, I think there are better options. I like all the non-functional properties—service discovery, client-side load balancing, well-factored monitoring, context propagation—can I have all that without the RPC interface model, please?

Martin

On Fri, Oct 21, 2016 at 10:44 AM, 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

--

Martin Nally, Apigee Engineering

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

--

Martin Nally, Apigee Engineering