|
After our success with a crowdsourced effort to translate the Cloud Native Definition, we wanted to kick off a similar effort on a Chinese style guide for cloud native terms. We want to thank KubeCon + CloudNativeCon Shanghai co-chair Janet Kuo, who began this work by correcting some of the translations we received from a service.
You can see all of the sessions for Shanghai (which will be Nov. 13-15) in English and Chinese. Please make suggestions for improved translations in the style guide, and we will then correct the schedule and share this guide will the interpreters (note that all keynotes and sessions in Shanghai will feature simultaneous interpretation).
|
|
|
Re: Graduation review for Fluentd
Hi ToC and Contributors,
Fluentd project is really interested into get your feedback about our graduation request:
any feedback is appreciated.
regards,
The application specifically addressed the graduation criteria, which was helpful.
I posted some links to some stats relating to project health and contributor diversity. The incubation criteria also apply at graduation:
I think there's an opportunity for help from TOC contributors with these types of reviews, to pre-review the information provided, ask questions about project health and adoption, whether the projects are getting what they need from CNCF, and whatever else we feel is important.
|
|
|
Re: RSocket Followup (post TOC meeting)
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: 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).
|
|
|
Re: RSocket Followup (post TOC meeting)
Timothy Bozarth <tim@...>
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:
+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.
|
|
|
Re: Question on sandbox projects
|
|
|
Re: Question on sandbox projects
Brandon Philips <bphilips@...>
Maybe prefix things intead of postfix things to get the ordering right? Some tools sort () and [] after letters and numbers. Give it a shot?
FWIW, the over promotion of sandbox projects was raised at the GB meeting as well and I share the concern about the current format.
Brandon
On Thu, Aug 9, 2018 at 2:06 PM Chris Aniszczyk < caniszczyk@...> wrote: FYI this is the best we can do, based on the day the data is pulled within the CFP program (it's why Helm is at the bottom instead of alphabetized currently)
If we reorder them, then, for example, anything that has been submitted as Container Networking thus far will essentially lose its data:
We will see if we can improve things in 2019 with the CFP system, thanks for the feedback.
|
|
|
Re: RSocket Followup (post TOC meeting)
In addition, Pivotal's interest in RSocket extends beyond the Java implementation and we're specifically interested in JavaScript and Go. For us to be comfortable, we'd ensure reliable interoperability before we took anything to market with those implementations. Contributing to the TCK and extensive cross implementation testing would be efforts we'd contribute to.
-Ben
toggle quoted message
Show quoted text
On Aug 10, 2018, at 12:54, Robert Roeser <robert@...> wrote:
Hi Alexis,
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.
Cheers,
Robert
From: Alexis Richardson <alexis@...>
Date: Wednesday, August 8, 2018 at 2:41 PM
To: Robert Roeser <robert@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
On Wed, 8 Aug 2018, 22:08 Robert Roeser, <robert@...> wrote:
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic to other services that have capacity.
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error conditions because it will be prevent extra/wasteful processing.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required. An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From: Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
- what's the Go story?
On Tue, 7 Aug 2018, 17:04 Chris Aniszczyk, <caniszczyk@...> wrote:
https://github.com/rsocket
I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket vs nats vs grpc)
Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.
Feel free to continue the discussion here.
--
Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: RSocket Followup (post TOC meeting)
Robert Roeser <robert@...>
Hi Alexis,
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts
like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.
Cheers,
Robert
From:
Alexis Richardson <alexis@...>
Date: Wednesday, August 8, 2018 at 2:41 PM
To: Robert Roeser <robert@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
How much interoperability testing have you done? Especially in the multi hop multi implementation cases
toggle quoted message
Show quoted text
On Wed, 8 Aug 2018, 22:08 Robert Roeser, < robert@...> wrote:
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate
a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates,
log data, etc.
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and
RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're
working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N
frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds.
Load balancers can use this information to direct traffic to other services that have capacity.
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel
work before it has started - this is beneficial in error conditions because it will be prevent extra/wasteful processing.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application
back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an
application concern. For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when
a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers
and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer
to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include
in your application. You would use RSocket to build something like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads
have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications
are built upon it, but since it does not _require_ an intermediate broker, there's no product required. An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket
teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From:
Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket
vs nats vs grpc)
Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.
Feel free to continue the discussion here.
--
Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: RSocket Followup (post TOC meeting)
Go, java, js and c++ would be a convincing portfolio, if interop worked.
On Fri, 10 Aug 2018, 20:56 Ben Hale, < bhale@...> wrote: In addition, Pivotal's interest in RSocket extends beyond the Java implementation and we're specifically interested in JavaScript and Go. For us to be comfortable, we'd ensure reliable interoperability before we took anything to market with those implementations. Contributing to the TCK and extensive cross implementation testing would be efforts we'd contribute to.
-Ben
> On Aug 10, 2018, at 12:54, Robert Roeser <robert@...> wrote:
>
> Hi Alexis,
>
> How much interoperability testing have you done? Especially in the multi hop multi implementation cases
> There are internal tests using RSocket with the different implementations and they interoperate – have done tests where C++ calls Java which calls a service in a browser tab (browser acts like microservice), etc. The spec has been fleshed as people worked on the different versions. The TCK is on the road map to be worked on again, we just need to figure out where to host these tests in public.
>
> Cheers,
> Robert
>
>
> From: Alexis Richardson <alexis@...>
> Date: Wednesday, August 8, 2018 at 2:41 PM
> To: Robert Roeser <robert@...>
> Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Chris Aniszczyk <caniszczyk@...>, "stevegury@..." <stevegury@...>
> Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
>
> How much interoperability testing have you done? Especially in the multi hop multi implementation cases
>
> On Wed, 8 Aug 2018, 22:08 Robert Roeser, <robert@...> wrote:
> +stevegury@...
>
> Hi,
>
> Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
>
> Thanks,
> Robert Roeser
>
> Rsocket team, key questions for me are:
>
> - what are main differences/USPs Vs prior art (nats, grpc, 0mq)
> - RSocket is essentially distributed RxJava or ReactiveStreams
>
> - RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
>
> - RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
> - RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
> - The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
> - Support for ReactiveStreams request n style flow control across a binary boundary
> - Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
> - This application level back-pressure is composeable across services
> - Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic to other services that have capacity.
> - Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
>
> - RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error conditions because it will be prevent extra/wasteful processing.
>
> - Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
> - All interactions are modeled as asynchronous streams with optimizations for the different interaction models
> - Request/reply - bi-directional stream of one to one
> - Fire/Forget - unidirectional stream of one
> - Request/Stream - bidirectional stream of one to many
> - Request/Channel - bidirectional stream of many to many
>
> - RSocket supports metadata push which you can use to push metadata associated with a connection.
>
> - RSocket can support many thousands of concurrent streams on a single host
>
> - Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
>
> - gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple layers, rather than being tied to HTTP/2
>
> - NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something like NATs
>
> - 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
>
> - is rsocket more of a lib or a "product'
> RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required. An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
>
> - what's the Go story?
> We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
>
> From: Alexis Richardson <alexis@...>
> Date: Tuesday, August 7, 2018 at 9:14 AM
> To: Chris Aniszczyk <caniszczyk@...>
> Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
> Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
>
> Colin, your feedback is essential, please do share
>
> Rsocket team, key questions for me are:
>
> - what are main differences/USPs Vs prior art (nats, grpc, 0mq)
> - is rsocket more of a lib or a "product'
> - what's the Go story?
>
>
> On Tue, 7 Aug 2018, 17:04 Chris Aniszczyk, <caniszczyk@...> wrote:
> https://github.com/rsocket
>
> I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket vs nats vs grpc)
>
> Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.
>
> Feel free to continue the discussion here.
>
>
> --
> Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: RSocket Followup (post TOC meeting)
Is mobile the primary use case today? RSocket’s primary use-case is distributed systems communication. I mentioned the above example as it’s difficult to do that today and you usually need additional components like Socket.io, long-polling, etc, where as with RSocket it is natural. Resumabilty was added for the mobile use-case and today's implementation is warm resumablity where theserver side hasn’t timed out the subscriptions and flushed them. There has been talk to do cold resumabilty where you could have streams that are able to resume when there isn’t a active subscription on the producing side. Rsocket uses client-slide load balancing to achieve this?
https://github.com/rsocket/rsocket-java/tree/1.0.x/rsocket-load-balancer You could do it with client-client load balancer, or a middle-ware load-balancer that understands RSocket. Steve Gury can provide more context about load-balancing on a large scale. OOC, how much work does cancellation save in practice? Presumably it mostly applies to requests that haven't yet been picked up by their consumers. Depending on what you are doing, it could be lots of work. RSocket provides Reactive Stream semantics across a process boundary. In Reactive Streams there are three ways to terminate a stream: it completes, it errors, or you cancel it. All streams (including request/response) support cancellation to allow efficient cleanup of responder resources. This is essential with interaction models such as streams and subscriptions - you need it to cleanly signal to stop streaming data where the stream doesn’t complete or error. An example how how this works could be a stream of data that has 1,000,000 items, and you want to take a 100 items from it. With ReactiveStreams you can ask for 100 items, and then cancel when you receive them. Before RSocket you could only do this in the same process. With RSocket you can do this between services, even across multiple services it you want (A->B->C……->N). If you use a ReactiveStreams library like RXJava, Reactor-core, Akka-streams, Yarl, etc. all this happens automatically. You basically need to write something like this: ``` Payload p = null; requestStream(p) .limitRequest(100) .subscribe(doSomethingInteresting()); ``` The developer doesn’t need to concern them with back pressure or cancellation but the implementation will use this to create the behavior the developer wants. -Ben
|
|
|
Re: RSocket Followup (post TOC meeting)
I'd like to add to Ben's comments that this pattern is implemented in many message brokers which de facto support relays a->b->c.
The appeal (to me) of rsocket is to make the pattern part of the protocol and remove the requirement for a broker.
However, to then be useful it is critical that multiple implementations exist and interoperate.
On Fri, 10 Aug 2018, 19:36 Ben Hale, < bhale@...> wrote: > A pretty common way that application flow control is achieved in TCP-based distributed systems is for a message consumer to simply stop reading messages off a TCP connection if it wants the message producer to stop sending messages from the other end. TCP does all the rest automatically, compliments of sliding windows, receive buffers etc. If senders and receivers use fairly basic thread pools, back pressure through the system “just works”, in my experience. It sounds like a fairly significant part of Rsocket is an additional protocol to achieve much the same back-pressure-based application flow control? Other than to support non-TCP transports (like UDP), which I would assume are fairly uncommon, why did you feel it necessary to add an additional layer of application flow control on top of what TCP already provides?
TCP flow control is at the byte level and RSocket is flow control at the message level. It's often easier to reason at the message level when you build applications because you don't have to guess how many bytes a single message is. RSocket arbitrages between transport level flow control, and Reactive Streams semantic.
When you have asynchronous applications that don't have thread pools, the back pressure provided by TCP is often broken because the number of bytes in a message doesn't necessarily correspond to how expensive it is to process. You can have a one megabyte message processed swiftly and a one kilobyte message that is expensive. Most people already deal with this application-level flow control problem already using circuit breakers, rate limiters, request throttling and bounded thread pools as you mention. These are all examples of application back pressure but the common limitation is that all cause an error on the client side when capacity is exceeded. Essentially, you can only find out if you need to back off by attempting first and then failing. RSocket eliminates this failing attempt because a client will only request a volume _it_ knows it can handle, and then the server will only send that. This prevents things like retry storms and extra processing while resulting in better tail latency, etc.
To illustrate this, imagine you have three services A streaming to B, B streaming to C. Lets also say that they are streaming data at 25% of the capacity of the TCP buffer. C slows down with garbage collection, or expensive to process items. With TCP each buffer has to fill up before A (the root generator) slows down and this only happens after messages have been sent. This leads to cascading failures in services: C is going to get messages it can't handle regardless of the TCP back pressure. The typical way to deal with is add circuit breakers, and rate limiting that create errors when they reach a certain capacity. With RSocket you don't need circuit breakers; instead C stops sending requestN requests to B, and B stops sending requestN's A. Everything slows down to the rate that C can handle, and this happens uniquely and individually for each end-client's performance.
Besides application safety, Reactive Stream requestN semantics make it easier for the developer to create applications that scroll over data, page over data, or take a finite amount of data from a stream. It's difficult to reason about how many bytes 8 'user profiles' are, but it's very easy to ask for 8.
-Ben
|
|
|
Re: RSocket Followup (post TOC meeting)
A pretty common way that application flow control is achieved in TCP-based distributed systems is for a message consumer to simply stop reading messages off a TCP connection if it wants the message producer to stop sending messages from the other end. TCP does all the rest automatically, compliments of sliding windows, receive buffers etc. If senders and receivers use fairly basic thread pools, back pressure through the system “just works”, in my experience. It sounds like a fairly significant part of Rsocket is an additional protocol to achieve much the same back-pressure-based application flow control? Other than to support non-TCP transports (like UDP), which I would assume are fairly uncommon, why did you feel it necessary to add an additional layer of application flow control on top of what TCP already provides? TCP flow control is at the byte level and RSocket is flow control at the message level. It's often easier to reason at the message level when you build applications because you don't have to guess how many bytes a single message is. RSocket arbitrages between transport level flow control, and Reactive Streams semantic. When you have asynchronous applications that don't have thread pools, the back pressure provided by TCP is often broken because the number of bytes in a message doesn't necessarily correspond to how expensive it is to process. You can have a one megabyte message processed swiftly and a one kilobyte message that is expensive. Most people already deal with this application-level flow control problem already using circuit breakers, rate limiters, request throttling and bounded thread pools as you mention. These are all examples of application back pressure but the common limitation is that all cause an error on the client side when capacity is exceeded. Essentially, you can only find out if you need to back off by attempting first and then failing. RSocket eliminates this failing attempt because a client will only request a volume _it_ knows it can handle, and then the server will only send that. This prevents things like retry storms and extra processing while resulting in better tail latency, etc. To illustrate this, imagine you have three services A streaming to B, B streaming to C. Lets also say that they are streaming data at 25% of the capacity of the TCP buffer. C slows down with garbage collection, or expensive to process items. With TCP each buffer has to fill up before A (the root generator) slows down and this only happens after messages have been sent. This leads to cascading failures in services: C is going to get messages it can't handle regardless of the TCP back pressure. The typical way to deal with is add circuit breakers, and rate limiting that create errors when they reach a certain capacity. With RSocket you don't need circuit breakers; instead C stops sending requestN requests to B, and B stops sending requestN's A. Everything slows down to the rate that C can handle, and this happens uniquely and individually for each end-client's performance. Besides application safety, Reactive Stream requestN semantics make it easier for the developer to create applications that scroll over data, page over data, or take a finite amount of data from a stream. It's difficult to reason about how many bytes 8 'user profiles' are, but it's very easy to ask for 8. -Ben
|
|
|
Re: RSocket Followup (post TOC meeting)
On Wed, Aug 8, 2018 at 2:10 PM Robert Roeser < robert@...> wrote:
+stevegury@...
Hi,
Here’s answers to your questions below. Please reach out to Ben Hale, Steve Gury, or myself if you have additional questions
Thanks,
Robert Roeser
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- RSocket is essentially distributed RxJava or ReactiveStreams
- RSocket client and server both have a requester and responder. This means that either side of an RSocket connection can initiate a stream. This lets you do interesting things like have
a mobile device connect to a microservice, and then allow the server to make calls directly to the mobile device - as if the mobile device was a server. The mobile device could serve a stream of GPS coordinates, log data, etc.
Is mobile the primary use case today?
- RSocket complements ReactiveStreams - ReactiveStreams abstracts asynchrony within a binary boundary (threads, etc) and RSocket abstracts this across a binary boundary (network calls)
- RSocket abstracts the transport from the developer - an application written with RSocket supports whatever transports are implemented.
- The transport abstraction lets you pick a transport appropriate to your environmental constraints. For instance, if you're working with a web browser you can use WebSocket and if you're
in a data center you can use something with higher throughput like Aeron UDP protocol. The developer would not need to change their application logic, just replace the transport RSocket is using.
- Support for ReactiveStreams request n style flow control across a binary boundary
- Request n works by a stream consumer sending the producer the number of items it wants to consume. In RSocket it receives REQUEST_N frame with a number indicating how many items to produce.
- This application level back-pressure is composeable across services
- Optional Leasing support - applications send other applications leases in the form of X requests can be sent of the next Y seconds. Load balancers can use this information to direct traffic
to other services that have capacity.
Rsocket uses client-slide load balancing to achieve this?
- Leasing and Back-pressure can obviate the need for additional circuit breakers and rate limiters
- RSocket cancellations are propagated up and down across chains of services - and because ReactiveStreams is lazy this can cancel work before it has started - this is beneficial in error
conditions because it will be prevent extra/wasteful processing.
OOC, how much work does cancellation save in practice? Presumably it mostly applies to requests that haven't yet been picked up by their consumers.
- Each RSocket connection is a bidirectional stream that arbitrages flow control between transport back-pressure and application back-pressure
- All interactions are modeled as asynchronous streams with optimizations for the different interaction models
- Request/reply - bi-directional stream of one to one
- Fire/Forget - unidirectional stream of one
- Request/Stream - bidirectional stream of one to many
- Request/Channel - bidirectional stream of many to many
- RSocket supports metadata push which you can use to push metadata associated with a connection.
- RSocket can support many thousands of concurrent streams on a single host
- Resumability is handled at the protocol/implementation level, so while this is possible today, the protocol removes it as an application concern. For instance, this lets a developer
work with a flappy network connection as if it's a reliable one. This is particularly useful for mobile developers. This lets you keep your subscriptions active and then RSocket sends missing data when a connection is reestablished.
- gRPC is a RPC on HTTP/2 and I believe was created to leverage existing infrastructure. gRPC's spec is a collection of headers and URLs- in its current implementation it requires something
like HTTP/2 vs RSocket which is a binary framed protocol and can send it over any bi-directional connection. RSocket works in a browser whereas gRPC needs a bridge. You could use RSocket as a layer to building something like gRPC that could run over multiple
layers, rather than being tied to HTTP/2
- NATs is a message broker and a product. NATs requires an external broker, is text based. RSocket is library you would include in your application. You would use RSocket to build something
like NATs
- 0mq is similar in some requests, but IMO the RSocket protocol is simpler than 0mq. Messages in 0mq are blobs, and RSocket payloads have the concept of data and metadata each with their
own mime-type. 0mq is intended to model a message broker vs RSocket which is "distributed RxJava". 0mq doesn't work in a web browser whereas RSocket does.
- is rsocket more of a lib or a "product'
RSocket is a library for network communication like `javax.net` or gRPC. Applications are built upon it, but since it does not _require_ an intermediate broker, there's no product required.
An intermediate broker _can_ be useful and be a product, but this is a transparent addition that is not required by RSocket.
- what's the Go story?
We need to implement a version in Go. We have talked with various parties and there is interest in it. It is not the various RSocket teams core competency, but there is nothing stopping
an implementation from being made as either wrapping the C++ library, or writing a pure golang implementation. We would be happy to help with its implementation.
From:
Alexis Richardson <alexis@...>
Date: Tuesday, August 7, 2018 at 9:14 AM
To: Chris Aniszczyk <caniszczyk@...>
Cc: Ben Hale <bhale@...>, CNCF TOC <cncf-toc@...>, Robert Roeser <robert@...>
Subject: Re: [cncf-toc] RSocket Followup (post TOC meeting)
Colin, your feedback is essential, please do share
Rsocket team, key questions for me are:
- what are main differences/USPs Vs prior art (nats, grpc, 0mq)
- is rsocket more of a lib or a "product'
I just wanted to move this discussion to the mailing list as there was some questions that weren't answered and I know that Colin had some feedback on the project comparisons (rsocket vs nats vs grpc)
Also Alexis Richardson from the TOC is OK to sponsor this effort into the Sandbox, so if anyone else is interested in sponsoring, please let me know.
Feel free to continue the discussion here.
--
Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: Question on sandbox projects
Chris Aniszczyk
FYI this is the best we can do, based on the day the data is pulled within the CFP program (it's why Helm is at the bottom instead of alphabetized currently)
If we reorder them, then, for example, anything that has been submitted as Container Networking thus far will essentially lose its data:
We will see if we can improve things in 2019 with the CFP system, thanks for the feedback.
On Thu, Aug 9, 2018 at 3:58 PM, Chris Aniszczyk <caniszczyk@...> wrote: and of course I posted the wrong screenshot sigh:
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: Question on sandbox projects
Chris Aniszczyk
and of course I posted the wrong screenshot sigh:
On Thu, Aug 9, 2018 at 3:57 PM, Chris Aniszczyk <caniszczyk@...> wrote: At the moment, we are limited to what the CFP tool is capable of doing, so we only have a list.
We have updated the list of projects to label their relative maturity level in the CFP system.
For future CFPs, we will see if we can do what you have suggested.
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: Question on sandbox projects
Chris Aniszczyk
At the moment, we are limited to what the CFP tool is capable of doing, so we only have a list.
We have updated the list of projects to label their relative maturity level in the CFP system.
For future CFPs, we will see if we can do what you have suggested.
On Thu, Aug 9, 2018 at 3:53 PM, Quinton Hoole <quinton.hoole@...> wrote:
OK, I’m suggesting the opposite – three clearly separate lists –
graduated, incubating, sandbox
If I’m the only one who feel strongly on this I’m happy to step down off my soapbox. But I remember other TOC members having similarly strong feelings on the matter. Brian Cantril, Camille and Alexis come to mind?
Q
We can annotate each listing with the project maturity level, that's my proposed solution moving forward.
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: Question on sandbox projects
Yes I agree with Quinton
toggle quoted message
Show quoted text
OK, I’m suggesting the opposite – three clearly separate lists –
graduated, incubating, sandbox
If I’m the only one who feel strongly on this I’m happy to step down off my soapbox. But I remember other TOC members having similarly strong feelings on the matter. Brian Cantril, Camille and Alexis come to mind?
Q
Subject: Re: [cncf-toc] Question on sandbox projects
We can annotate each listing with the project maturity level, that's my proposed solution moving forward.
|
|
|
Re: Question on sandbox projects
OK, I’m suggesting the opposite – three clearly separate lists –
graduated, incubating, sandbox
If I’m the only one who feel strongly on this I’m happy to step down off my soapbox. But I remember other TOC members having similarly strong feelings on the matter. Brian Cantril, Camille and Alexis come to mind?
Q
toggle quoted message
Show quoted text
We can annotate each listing with the project maturity level, that's my proposed solution moving forward.
|
|
|
Re: Question on sandbox projects
Chris Aniszczyk
We can annotate each listing with the project maturity level, that's my proposed solution moving forward.
On Thu, Aug 9, 2018 at 3:26 PM, Quinton Hoole <quinton.hoole@...> wrote:
This topic has already come up several times in the ToC. We explicitly decided that a very clear distinction should always be drawn between sandbox, incubation and graduated projects in external-facing communication. It doesn’t
sound like an alphabetical list mixing all of the projects together meets that goal.
Extract from sandbox.md, which I think needs to be strengthened to meet the above goals.
Some key points:
- Sandbox projects will be listed separately from other CNCF projects (cncf.io/sandbox)
- They will not be prominently listed at our events or issued a press release
Quinton
I don't see an issue with listing the projects in alphabetic order outside that it should be a series of checkboxes instead of radio buttons (we will fix that soon).
The TOC list is meant for technical discussions so if you have something you'd like to change about the CFP form, please email events@... for suggestions and we can have a discussion there.
Thanks.
-- Chris Aniszczyk (@cra) | +1-512-961-6719
|
|
|
Re: Question on sandbox projects
This topic has already come up several times in the ToC. We explicitly decided that a very clear distinction should always be drawn between sandbox, incubation and graduated projects in external-facing communication. It doesn’t
sound like an alphabetical list mixing all of the projects together meets that goal.
Extract from sandbox.md, which I think needs to be strengthened to meet the above goals.
Some key points:
- Sandbox projects will be listed separately from other CNCF projects (cncf.io/sandbox)
- They will not be prominently listed at our events or issued a press release
Quinton
toggle quoted message
Show quoted text
I don't see an issue with listing the projects in alphabetic order outside that it should be a series of checkboxes instead of radio buttons (we will fix that soon).
The TOC list is meant for technical discussions so if you have something you'd like to change about the CFP form, please email events@... for suggestions and we can have a discussion there.
Thanks.
|
|
|
