Just a friendly reminder to the wider CNCF community, the Fluentd project proposal is almost ready for a vote: https://github.com/cncf/toc/pull/20 Please make any final comments, I plan on calling for

No argument here, improving the experience for HTTP+JSON is something Google is actively investing in. We see these as complimentary and often entirely overlapping (GRPC is based on HTTP(2) after all)

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

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

+adding back the grpc folks to comment

Overall it looks good. Just two things that jumped out at me that are missing: 1 - multi-tenancy. I don't think we need to say much, other than its an issue, and while it could appear on several

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

A global service catalogue is an interesting idea. If it is "like DNS but for cloud native apps" then it presupposes an "HTTP but for cloud native apps". Such as a service broker protocol for

Thanks. And, if you're building a new microservice-based application, you need to use something. What are the choices? an RPC system an open-source REST API framework and OpenAPI codegen for

Fascinating. Thank-you. I shall need at least a day to digest this and respond so please be patient with me :-)

Thanks Alexis. > Can you please list which ones are notable? The main one seems to be "streaming" replies. Streaming is certainly notable but multiplexing and flow-control are also very important

Jayant Many thanks. 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

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

+1, protocols FTW ;-)

Since you asked the peanut gallery: I would be delighted to see gRPC supersede Thrift and Finangle for a laundry list of reasons. The crux: being burned by Thrift and Finangle's cross-language and

Brandon, Thank-you. It may help if I mention why I raised the question about HTTP 1.x. Overall we are fans of gRPC at Weaveworks. But we stumbled into some issues when trying to use it in this

Given that security spans all the layers and is a complex topic, I'm not sure what we'd add at the current level of detail. Service naming, discovery, load balancing, and routing (service fabric/mesh

YES

Hi, Yaron. This layer diagram is extremely high-level, and the explanations of the levels are intended to be descriptive rather than exhaustive, so it doesn't preclude the service broker model.