4 ms·
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
by 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 agoYep, 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.