3 ms·

It’s quite disturbing that your default suggested use is to connect unencrypted... over the internet. It’s almost like people don’t take security seriously.

junon 6y ago
This. Also, serverless and redis don't really make sense together - these things I'm supposed to "not care" about are things that directly affect the design of the system. Redundancy, eviction strategy, etc. - things I need to plan for. Redis shouldn't grow infinitely. It should be memory bounded. Your code should expect evictions - in fact, almost every key in your redis cache should have an expiry. Redis shouldn't be used over the internet like this anyway - you want colocated (in-datacenter) instances for sub-millisecond latency, otherwise what's the point? RedisLabs IIRC also only offers encryption as an enterprise feature, which is something that has always left a bad taste in my mouth.
- stephenr 6y ago
  > RedisLabs IIRC also only offers encryption as an enterprise feature, which is something that has always left a bad taste in my mouth. Yeah I didn't like this either, given how other "sexy" features that inherently mean you're not using a single instance listening on loopback were prioritised over TLS support. AFAIK their solution was essentially to run a TLS proxy in front of redis, and I'm not sure what they did if anything about any replicated traffic. However, as of v6 (released recently) TLS is builtin. As I explained in the discussion thread for the 6.0 announcement, putting a proxy in front of Redis, for clients that support TLS is like 10% of the problem, when you're using more than one instance. You end up creating a rats nest of tunnels and local port numbers, so that redis internal replication traffic, and internal sentinel traffic, and sentinel to redis traffic is all encrypted too.
  - junon 6y ago
    Yep, exactly. One other point I forgot to mention - this is not an "alternative to hosted redis". It's still hosted redis, just with fancier jargon and more obscure guarantees. I can't imagine this being robust.

junon 6y ago

This. Also, serverless and redis don't really make sense together - these things I'm supposed to "not care" about are things that directly affect the design of the system. Redundancy, eviction strategy, etc. - things I need to plan for. Redis shouldn't grow infinitely. It should be memory bounded. Your code should expect evictions - in fact, almost every key in your redis cache should have an expiry. Redis shouldn't be used over the internet like this anyway - you want colocated (in-datacenter) instances for sub-millisecond latency, otherwise what's the point? RedisLabs IIRC also only offers encryption as an enterprise feature, which is something that has always left a bad taste in my mouth.

stephenr 6y ago
> RedisLabs IIRC also only offers encryption as an enterprise feature, which is something that has always left a bad taste in my mouth. Yeah I didn't like this either, given how other "sexy" features that inherently mean you're not using a single instance listening on loopback were prioritised over TLS support. AFAIK their solution was essentially to run a TLS proxy in front of redis, and I'm not sure what they did if anything about any replicated traffic. However, as of v6 (released recently) TLS is builtin. As I explained in the discussion thread for the 6.0 announcement, putting a proxy in front of Redis, for clients that support TLS is like 10% of the problem, when you're using more than one instance. You end up creating a rats nest of tunnels and local port numbers, so that redis internal replication traffic, and internal sentinel traffic, and sentinel to redis traffic is all encrypted too.
- junon 6y ago
  Yep, exactly. One other point I forgot to mention - this is not an "alternative to hosted redis". It's still hosted redis, just with fancier jargon and more obscure guarantees. I can't imagine this being robust.