Reactive Foundation created to nurture RSocket and Reactive OSS alternatives for cloud-native comms
October 7 2019
by William Fellows, Eric Hanselman
The Linux Foundation recently announced the Reactive Foundation to accelerate the use of technologies for next-generation networked applications. RSocket, the open source HTTP alternative for cloud-native communications (e.g., service mesh/microservices) is the first asset – Reactive Streams will follow plus a Reactive database driver. Alibaba, Facebook, Netifi and Pivotal are among the key members. The Reactive Foundation offers a formal open governance model and ecosystem to support open source reactive programming projects.
The 451 Take
Practically, the challenge is for RSocket to be considered alongside other microservices approaches at large companies, which are now evaluating their cloud-native re-platforming strategies. If it can be proven to do better, faster and cheaper in commercial deployments, that will help. Moreover, unification of the asynchronous landscape (like Kubernetes has done for container orchestration) would help move the Reactive Streams approach toward the mainstream.
Although service meshes are predominantly performing synchronous operations, it's very early still. The primary implementations are focused on synchronous models; however, change is afoot. Istio 1.2 brings idempotency to most of the critical functions. A key question is how much functionality is offloaded from the developer. RSocket still requires that policy and authentication, authorization, and audit be handled by the application somewhere. But we don't think this is an either/or debate. RSocket and Reactive is certainly where the cool kids are headed; however, there are a number of different patterns to consider, and not all of them fit well. A high-level definition may work better than a more specific one, which could become stale faster. It is the non-blocking nature of the protocol, and the implications for scalability and traffic volume, that are specifically interesting here.
RSocket, Reactive Streams
RSocket is an open source, OSI Layer 5/6, or TCP/IP 'application layer' protocol initially developed by Netflix that supports Reactive Streams. Pivotal and Typesafe (now Lightbend) were also involved in creating RSocket in 2013. The protocol was introduced in 2015. The RSocket community believes that successful implementation of large, modular cloud-native distributed systems requires that all the different teams, technologies and programming languages delivering it must have a more effective, scalable and performant communication than that available in traditional request/response mechanisms.
Hence, RSocket, which embraces 'reactive' principles of asynchronous communication: Reactive Streams. RSocket replaces HTTP hypertext transfer protocol (which is said to be inefficient for many tasks such as cloud-native microservices communication) with a protocol that has less overhead. It can be used on byte stream transports such as TCP, WebSocket and Aeron.
Pub and sub
RSocket allows the use of a single connection, through which messages are passed as streams of data. Crucially, and the reason there is so much interest in it, RSocket uses a publish-and-subscribe model, where subscribers use non-blocking backpressure to manage the volumes of data being sent, rather than the traditional synchronous handshake for every element transfer. The expectation is that this will not only cut down on signalling overhead, but also yield more efficient execution, since any processing thread could run to completion without blocking.
RSocket enables long-lived streams across different transport connections, which is particularly useful for mobile-to-server communication where network connections drop, switch and reconnect frequently. RSocket provides application flow control over the network to prevent outages and increase resiliency, according to the Foundation. And unlike HTTP, RSocket does not wait for a response or request from the client.
In this model, the sender can send data asynchronously, rather than the receiver controlling the flow of information. Its supporters believe it offers enhanced performance and reliability compared to traditional synchronous remote procedure call mechanisms. It supports session resumption, to allow the resuming of long-lived streams across different transport connections, which is said to be useful for mobile-server communication when network connections drop, switch and reconnect frequently.
Hasn't the service mesh bus already left the station though? Proponents say RSocket could work with the Envoy data plane in the future – Envoy could understand RSocket like it does HTTP, and could be used in a side-car proxy approach and with Istio.
A commonly used definition of service meshes is that they provide a distributed interconnection abstraction that provides data path services for connected instances. The primary purpose is to relieve developers of having to implement a range of interconnection services, and provide policy-based controls for interconnection management. Acting as a proxy, service meshes offer availability, performance, security and authentication services under policy control; as well as observability through monitoring, logging, tracing and tap functions.
Availability services include load balancing and circuit breakers for API protection. Security capabilities include authentication, authorization and accounting. Service meshes can enforce the use of encryption in communications paths, and automate the creation of secure connections. Service meshes are typically implemented as a set of microservices.
Traditional messaging from TIBCO or Kafka isn't designed for microservices or cloud environments, while service meshes are complex, expensive and don't work across multiple environments. Envoy, the data plane developed at
has achieved impressive take-up since it was open-sourced at the end of 2016 – it is the default data plane for Istio, AWS's App Mesh and the Google Traffic Director managed control plane, to name just a few.
Other data planes include Linkerd, NGINX, HAProxy and Traefik. Other Istio implementations include VMware NXS Service Mesh and F5 Aspen Mesh's managed Istio. Tetrate offers management of scale microservices deployments. Solo.io is providing an abstraction layer enabling customers to use any combination of service mesh types.
In May, Microsoft announced Service Mesh Interface (SMI), defining a set of APIs that provide developers with interoperability across different service mesh technologies including Istio, Linkerd and Consul Connect. SMI is supported by Microsoft, Linkerd, HashiCorp, Solo.io, Kinvolk and Weaveworks; with support from Aspen Mesh, Canonical, Docker, Pivotal, Rancher, Red Hat and VMware.