Date   

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





Re: peanut-gallery thoughts about GRPC

Jayant Kolhe
 


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. 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. It would add significant complexity across multiple language implementations and would have higher bar and complexity for implementing and testing interoperability across these implementations. 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. 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.


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




Re: peanut-gallery thoughts about GRPC

alexis richardson
 

+1, protocols FTW ;-)


On Tue, Oct 25, 2016 at 11:36 AM, Matt T. Proud ⚔ <matt.proud@...> wrote:
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 -runtime interoperability problems.  gRPC was motivated by this interoperability on day one; whereas it felt like an afterthought in Thrift.  Further: Finangle's operational metrics — last I looked at them in 2013 — were pretty incomprehensible (frankly felt a deep sense of pity for anyone oncall for a system built on top of it).

gRPC is self-standingly a natural addition to a reference implementation's portfolio.  My only regret was its not arriving "on the block" a year or two sooner — lest another generation's mind be wasted to a substandard technology.  ;)

On Tue, Oct 25, 2016 at 12:16 PM Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
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 case:


alexis


On Mon, Oct 24, 2016 at 9:35 PM, Brandon Philips <brandon.philips@...> wrote:
On gRPC and HTTP 1.x I think the best way to bring gRPC to the HTTP 1.x world is via OpenAPI (formerly swagger) and JSON, see the blog post here: http://www.grpc.io/blog/coreos

We do this in etcd v3: provide endpoints for HTTP 2.x + gRPC and HTTP 1.x + JSON.

On Fri, Oct 21, 2016 at 11:42 AM Brian Grant via cncf-toc <cncf-toc@...> 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


_______________________________________________
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


Re: peanut-gallery thoughts about GRPC

Matt T. Proud
 

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 -runtime interoperability problems.  gRPC was motivated by this interoperability on day one; whereas it felt like an afterthought in Thrift.  Further: Finangle's operational metrics — last I looked at them in 2013 — were pretty incomprehensible (frankly felt a deep sense of pity for anyone oncall for a system built on top of it).

gRPC is self-standingly a natural addition to a reference implementation's portfolio.  My only regret was its not arriving "on the block" a year or two sooner — lest another generation's mind be wasted to a substandard technology.  ;)

On Tue, Oct 25, 2016 at 12:16 PM Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
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 case:


alexis


On Mon, Oct 24, 2016 at 9:35 PM, Brandon Philips <brandon.philips@...> wrote:
On gRPC and HTTP 1.x I think the best way to bring gRPC to the HTTP 1.x world is via OpenAPI (formerly swagger) and JSON, see the blog post here: http://www.grpc.io/blog/coreos

We do this in etcd v3: provide endpoints for HTTP 2.x + gRPC and HTTP 1.x + JSON.

On Fri, Oct 21, 2016 at 11:42 AM Brian Grant via cncf-toc <cncf-toc@...> 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


_______________________________________________
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


Re: peanut-gallery thoughts about GRPC

alexis richardson
 

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 case:


alexis


On Mon, Oct 24, 2016 at 9:35 PM, Brandon Philips <brandon.philips@...> wrote:
On gRPC and HTTP 1.x I think the best way to bring gRPC to the HTTP 1.x world is via OpenAPI (formerly swagger) and JSON, see the blog post here: http://www.grpc.io/blog/coreos

We do this in etcd v3: provide endpoints for HTTP 2.x + gRPC and HTTP 1.x + JSON.

On Fri, Oct 21, 2016 at 11:42 AM Brian Grant via cncf-toc <cncf-toc@...> 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


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


Re: [VOTE] End User Reference Architecture v1.0

Brian Grant
 

On Mon, Oct 24, 2016 at 5:28 AM, Ram, J via cncf-toc <cncf-toc@...> wrote:

 

Sorry, I missed that last call. So apologies if this was discussed.

Two thoughts/Questions that come to mind when looking thru the slides:

 

a)      Emphasis on security seem to be missing. It might be implicit, but being explicit might be useful.  So calling out some aspects of it in application definition, orchestration and runtime would change that. I suspect that orchestration and runtime would get more interesting if complex security policies are modelled in the application definition.

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. 

 

b)      Not sure if this is group to address: I feel, that no consistent implementation or standard for Service Directory exist. The most consistent yellow pages we seem to have DNS. For the new generation of applications, is that enough?  Should we call out Service directory under service management?

Service naming, discovery, load balancing, and routing (service fabric/mesh approaches) are intended to be covered by slide 6. Is there a specific terminology clarification that you'd like to see? Or would you like us to merge the "Coordination" and "Service Management" sub-bullets into a single list?

What exactly do you mean by "service directory"?

 

 

 

 

 

 

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@lists.cncf.io] On Behalf Of Chris Aniszczyk via cncf-toc
Sent: Monday, October 24, 2016 7:15 AM
To: cncf-toc@...
Subject: [cncf-toc] [VOTE] End User Reference Architecture v1.0

 

Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):

 

 

This is a call to formalize the reference architecture, so TOC members please vote!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


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



Re: [VOTE] End User Reference Architecture v1.0

Brian Grant
 

YES

On Mon, Oct 24, 2016 at 4:16 AM, Alexis Richardson via cncf-toc <cncf-toc@...> wrote:
YES

On Mon, Oct 24, 2016 at 12:15 PM Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):


This is a call to formalize the reference architecture, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
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



Re: השב: [VOTE] End User Reference Architecture v1.0

Brian Grant
 

On Mon, Oct 24, 2016 at 6:04 AM, Yaron Haviv via cncf-toc <cncf-toc@...> wrote:
Chris, 

Probably too late to comment,  but looking at the charts seems like we are missing a notion of resources binding / dependency,  similar to cloud foundry 

E. G.  A web Micro-Service binds to (or depends on)  a database Micro-Service with a certain url,  this helps orchestration to determine the provisioning steps,  and helps the app find the resources it builds on

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. 


Yaron 



נשלח ממכשיר הSamsung שלי


-------- הודעה מקורית --------
מאת: Chris Aniszczyk via cncf-toc <cncf-toc@...>
תאריך: 24/10/2016 14:15 (GMT+02:00)
אל: cncf-toc@...
נושא: [cncf-toc] [VOTE] End User Reference Architecture v1.0

Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):


This is a call to formalize the reference architecture, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

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



Re: peanut-gallery thoughts about GRPC

Brandon Philips <brandon.philips@...>
 

On gRPC and HTTP 1.x I think the best way to bring gRPC to the HTTP 1.x world is via OpenAPI (formerly swagger) and JSON, see the blog post here: http://www.grpc.io/blog/coreos

We do this in etcd v3: provide endpoints for HTTP 2.x + gRPC and HTTP 1.x + JSON.

On Fri, Oct 21, 2016 at 11:42 AM Brian Grant via cncf-toc <cncf-toc@...> 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


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


[devroom-managers] "Cloud and Monitoring" and "Containers and Microservices" devrooms Joint Call for Proposals

Chris Aniszczyk
 

FYI for awareness, CNCF is also sponsoring FOSDEM this year

Begin forwarded message:

From: Josh Berkus <jberkus@...>
Date: October 24, 2016 at 8:29:38 PM GMT+2
To: Luna Duclos <luna@...>, fosdem@...
Subject: [devroom-managers] "Cloud and Monitoring" and "Containers and Microservices" devrooms Joint Call for Proposals

Folks:

We'll all about the new container cloud this FOSDEM.  The "Linux
Containers and Microservices" devroom will cover Linux containers,
orchestration, management, CI/CD and container security.  "Monitoring
and Cloud" will cover monitorning microservices and containers, cloud
networking, metrics and more.

https://cncf.io/news/events/2017-02-04/fosdem-2017

As the two devrooms are being organized by different teams in the Cloud
Native community, we have decided to issue a joint CfP.  Please express
your preference for the devroom you want; the organizers will will pick
talks which are appropriate for each devroom and offer you a swap if
required.

Topics we are interested in include:

   Monitoring containerized services
   Automating cloud deployments
   Developing and administering microservices
   Container orchestration
   Continuous Integration & Deployment
   Prometheus, Kubernetes, OpenTracing, Docker, CRIO, etc.
   New projects and technology
   Other container and cloud native talks

...but if your talk or project involves new cloud technologies and/or
containerized microservices, give us a pitch!

We are also looking for Lunchtime Lightning Talks.

Submit by November 26th:
https://cncf.io/news/events/2017-02-04/fosdem-2017

--
--
Josh Berkus
Project Atomic
Red Hat OSAS
_______________________________________________
devroom-managers mailing list
devroom-managers@...
https://lists.fosdem.org/listinfo/devroom-managers


השב: [VOTE] End User Reference Architecture v1.0

Yaron Haviv
 

Chris, 

Probably too late to comment,  but looking at the charts seems like we are missing a notion of resources binding / dependency,  similar to cloud foundry 

E. G.  A web Micro-Service binds to (or depends on)  a database Micro-Service with a certain url,  this helps orchestration to determine the provisioning steps,  and helps the app find the resources it builds on

Yaron 



נשלח ממכשיר הSamsung שלי


-------- הודעה מקורית --------
מאת: Chris Aniszczyk via cncf-toc <cncf-toc@...>
תאריך: 24/10/2016 14:15 (GMT+02:00)
אל: cncf-toc@...
נושא: [cncf-toc] [VOTE] End User Reference Architecture v1.0

Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):


This is a call to formalize the reference architecture, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] End User Reference Architecture v1.0

Ram, J <j.ram@...>
 

 

Sorry, I missed that last call. So apologies if this was discussed.

Two thoughts/Questions that come to mind when looking thru the slides:

 

a)      Emphasis on security seem to be missing. It might be implicit, but being explicit might be useful.  So calling out some aspects of it in application definition, orchestration and runtime would change that. I suspect that orchestration and runtime would get more interesting if complex security policies are modelled in the application definition.

 

b)      Not sure if this is group to address: I feel, that no consistent implementation or standard for Service Directory exist. The most consistent yellow pages we seem to have DNS. For the new generation of applications, is that enough?  Should we call out Service directory under service management?

 

 

 

 

 

 

 

 

From: cncf-toc-bounces@... [mailto:cncf-toc-bounces@...] On Behalf Of Chris Aniszczyk via cncf-toc
Sent: Monday, October 24, 2016 7:15 AM
To: cncf-toc@...
Subject: [cncf-toc] [VOTE] End User Reference Architecture v1.0

 

Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):

 

 

This is a call to formalize the reference architecture, so TOC members please vote!

 

--

Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] End User Reference Architecture v1.0

alexis richardson
 

YES


On Mon, Oct 24, 2016 at 12:15 PM Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):


This is a call to formalize the reference architecture, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719
_______________________________________________
cncf-toc mailing list
cncf-toc@...
https://lists.cncf.io/mailman/listinfo/cncf-toc


[VOTE] End User Reference Architecture v1.0

Chris Aniszczyk
 

Last week at the CNCF TOC meeting, we discussed issues with the CNCF Reference Architecture and felt it was ready to finalize (and much better than what we had before):


This is a call to formalize the reference architecture, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: peanut-gallery thoughts about GRPC

Brian Grant
 

+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



Re: peanut-gallery thoughts about GRPC

alexis richardson
 

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


peanut-gallery thoughts about GRPC

Ben Sigelman
 

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"...


RFC: Project Proposal for Fluentd

Chris Aniszczyk
 

At yesterday's TOC meeting, we discussed formalizing a Fluentd project proposal after having a great experience collaborating with the Fluentd community:

For the TOC and wider CNCF community, please take a look at the proposal (https://github.com/cncf/toc/pull/20/files) and make any comments/suggestions on the PR.

If there aren't any major issues, we will call for a formal vote towards the end of next week.

Thanks!

--
Chris Aniszczyk (@cra) | +1-512-961-6719


Re: [VOTE] CNCF Code of Conduct

Jonathan Boulle <jonathan.boulle@...>
 

Yes

On 20 October 2016 at 17:12, Benjamin Hindman via cncf-toc <cncf-toc@...> wrote:
Yes.

On Thu, Oct 20, 2016 at 7:59 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
From yesterday's TOC meeting, we had discussion around adopting a code of conduct for the CNCF community. We decided to go with what the k8s community has already established:

The raw text of the CNCF code of conduct is here:

This is a call to formalize the Code of Conduct, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

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




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

Watch the Video .See how DC/OS elastically runs
containerized apps and data services
 

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



Re: [VOTE] CNCF Code of Conduct

Benjamin Hindman
 

Yes.

On Thu, Oct 20, 2016 at 7:59 AM, Chris Aniszczyk via cncf-toc <cncf-toc@...> wrote:
From yesterday's TOC meeting, we had discussion around adopting a code of conduct for the CNCF community. We decided to go with what the k8s community has already established:

The raw text of the CNCF code of conduct is here:

This is a call to formalize the Code of Conduct, so TOC members please vote!

--
Chris Aniszczyk (@cra) | +1-512-961-6719

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




--
Benjamin Hindman
Founder of Mesosphere and Co-Creator of Apache Mesos

Follow us on Twitter: @mesosphere

Watch the Video .See how DC/OS elastically runs
containerized apps and data services
 

7121 - 7140 of 7549