The idea here is that Redis server nodes could proxy incoming requests to the desired node instead of relying on heavy client side logic to know the cluster topology. Simplifies some of the work for workloads that don’t want to maintain a heavy client. This would be an optional configuration.
Comment From: yossigo
@madolson I'm not a big fan of this approach. Getting it right will be hard, considering both performance and the need to deal with all different client and server states. Getting more clients to support Reids Cluster properly is a better long-term investment, IMHO.
Comment From: zuiderkwast
I think a proxy middleware like https://github.com/RedisLabs/redis-cluster-proxy could be a good way to support non-cluster aware clients, without putting this inside Redis itself.
Comment From: madolson
I'm not a big fan of this approach. Getting it right will be hard, considering both performance and the need to deal with all different client and server states. Getting more clients to support Reids Cluster properly is a better long-term investment, IMHO.
I don't really consider something being "hard" as a serious deterrent. The main motivation for building such routing is that it's easier for clients to not have to learn the topology before sending commands. Think about workloads that don't want to establish persistent connections or has native support for connection pooling. Also, as @zuiderkwast mentioned, this basically is what is already provided by many cluster proxies. I think the project should consider creating a first class cluster proxy as well. If that exists, then it becomes pretty trivial to hook that up into the cluster, and then just run one type of server. It effectively can just be a module.
@zuiderkwast I think we should rebuild something like that. It's not a license that many people feel comfortable running as a service. (At least AWS isn't, perhaps others as well, AGPL feels safer as part of the tool chain.) I also think the quality has never really been tested, nor has the design really been vetted.
Comment From: zuiderkwast
this basically what is already provided by many cluster proxies
"many"? Any other examples?
It effectively can just be a module.
First class module, sounds good to me. If it's in Rust, I might find it too hard to contribute though. :-)
I suspect it can make use of the commands JSON for the special logic per command, like aggregation, e.g. DBSIZE should collect a sum of all shards.
AGPL
Well, I though the point of using AGPL is precisely to prevent service provides like AWS to take advantage without contributing back their improvements. (IIUC, it's fine to provide it as a service as long as the source code is provided to the users. This implies it'd have to be a separate service, i.e. it can't be extended with, combined with or be part of a proprietary source service.) Either way, I don't see this license as a strong motivation for others (companies that don't provide databases as services) to rewrite it with a different license.
I also think the quality has never really been tested, nor has the design really been vetted.
I don't think so either and it is described as "alpha".
Comment From: madolson
"many"? Any other examples?
I'm not aware of any other "free" ones. I know Alibaba and Redis Ltd. provide proxies as part of their proprietary offerings, some that run on top of cluster mode and others that do not.
Well, I though the point of using AGPL is precisely to prevent service provides like AWS to take advantage without contributing back their improvements. (IIUC, it's fine to provide it as a service as long as the source code is provided to the users. This implies it'd have to be a separate service, i.e. it can't be extended with, combined with or be part of a proprietary source service.) Either way, I don't see this license as a strong motivation for others (companies that don't provide databases as services) to rewrite it with a different license.
Maybe others can correct me, but many companies do view it as a blocker. We had a chain in the developer slack where others also wanted to change the license. Companies view it as a risk and will often pay to get a different license so that they are able to maintain internal changes or are afraid of integration being considered "derivative" work.
I'll also point out, as of right now most of the contributors do work on Redis managed offerings in some capacity at large companies. A risk of AGPL is that instead of modifying and contributing it back, companies will just build something proprietary and keep it that way. I think that is the correct choice systems that have such a high complexity that nobody would really try to make a custom change, but I don't think that exists here.
Comment From: zuiderkwast
maintain internal changes or are afraid of integration being considered "derivative" work
Of course I can see that AGPL (and GPL) complicates things.
A risk of AGPL is that instead of modifying and contributing it back, companies will just build something proprietary and keep it that way.
Sure, but with permissive licenses, it happens that companies base proprietary software on free software it and keep it that way. (Example: MacOS kernel.) With Redis it seems to work well so far though.