4 ms·

Show HN: I made an alternative to hosted Redis – Serverless for Redis

25 points by thiicket 6y ago

thiicket 6y ago
I'd love to hear feedback about any aspect of Thiicket, including the website and pricing, good or bad
- masukomi 6y ago
  I'm with Junon. I don't get why I'd want _REDIS_ to be remote, then i loose all the speed benefits of redis. Also i don't get why i need my redis cluster to scale. The only case where that seems like a need is if I'm caching global variables which is widely frowned upon. Everything else, there are caching + eviction strategies to handle this. If i've got massive traffic such that my redis cache is constantly churning (and thus not providing value) then couldn't i just spin up more redises? redi? along with all the new machines i'm surely needing to spin up. If my engineers are being paged to spin up more redis instances (or aNYTHING) then they've failed in their autoscaling configurations, and it's good they got called, and hopefully they'll rethink their architecture and scripts so that they never get called again. I'm not a devops guy so maybe i'm missing something obvious. On the other hand, I'm not a devops guy and I'm not _seeing_ an "obvious" win here. Either it actually doesn't meet my needs or I'm ignorant about something and the marketing isn't meeting my needs. Side note: not a devops guy but my team has hundreds of AWS machines and lots of redis usage.
  - stephenr 6y ago
    The only thing I can imagine they might be offering is redis that scales without the drawbacks of the official redis cluster sharding. I don't know if that is what they're doing, but it's one possible thing they could be doing "better" (as in its an area that could be improved, not necessarily that it's fundamentally or technically possible/easy)
  - pier25 6y ago
    > I don't get why I'd want _REDIS_ to be remote, then i loose all the speed benefits of redis If your cloud function is running in say East Asia and your Redis instance is nearby, it will be much faster than querying your DB in Virginia.
pier25 6y ago
Very cool. Is this distributed or at least multi region?
- thiicket 6y ago
  Yep, each regional location is distributed across 3 AZs. And we're planning on adding more regions across the globe
  - pier25 6y ago
    This is great! You should really emphasize this in your marketing.
stephenr 6y ago
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.

25 points by thiicket 6y ago

thiicket 6y ago

I'd love to hear feedback about any aspect of Thiicket, including the website and pricing, good or bad

masukomi 6y ago
I'm with Junon. I don't get why I'd want _REDIS_ to be remote, then i loose all the speed benefits of redis. Also i don't get why i need my redis cluster to scale. The only case where that seems like a need is if I'm caching global variables which is widely frowned upon. Everything else, there are caching + eviction strategies to handle this. If i've got massive traffic such that my redis cache is constantly churning (and thus not providing value) then couldn't i just spin up more redises? redi? along with all the new machines i'm surely needing to spin up. If my engineers are being paged to spin up more redis instances (or aNYTHING) then they've failed in their autoscaling configurations, and it's good they got called, and hopefully they'll rethink their architecture and scripts so that they never get called again. I'm not a devops guy so maybe i'm missing something obvious. On the other hand, I'm not a devops guy and I'm not _seeing_ an "obvious" win here. Either it actually doesn't meet my needs or I'm ignorant about something and the marketing isn't meeting my needs. Side note: not a devops guy but my team has hundreds of AWS machines and lots of redis usage.
- stephenr 6y ago
  The only thing I can imagine they might be offering is redis that scales without the drawbacks of the official redis cluster sharding. I don't know if that is what they're doing, but it's one possible thing they could be doing "better" (as in its an area that could be improved, not necessarily that it's fundamentally or technically possible/easy)
- pier25 6y ago
  > I don't get why I'd want _REDIS_ to be remote, then i loose all the speed benefits of redis If your cloud function is running in say East Asia and your Redis instance is nearby, it will be much faster than querying your DB in Virginia.

pier25 6y ago

Very cool. Is this distributed or at least multi region?

thiicket 6y ago
Yep, each regional location is distributed across 3 AZs. And we're planning on adding more regions across the globe
- pier25 6y ago
  This is great! You should really emphasize this in your marketing.

stephenr 6y ago

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.