[HN Gopher] Redis To Go is shutting down
___________________________________________________________________
Redis To Go is shutting down
Author : captn3m0
Score : 63 points
Date : 2022-06-13 07:48 UTC (15 hours ago)
(HTM) web link (redistogo.com)
(TXT) w3m dump (redistogo.com)
| chronark wrote:
| Try out upstash, it offers serverless redis where pricing scales
| to zero.
| ChrisArchitect wrote:
| Used this a lot before the Heroku official Redis provider went
| online. Kinda wonder why Heroku didn't just buy them?
| julianbuse wrote:
| > We wanted to communicate this as early as possible
|
| Two months is a bit short for a database change, don't you think?
| zeckalpha wrote:
| Redis is not a database. Please, do not use it for persistence.
| I have been bitten too many times by services that tried.
| avinassh wrote:
| I am curious, what all kinds of issues you ran into?
| [deleted]
| zeckalpha wrote:
| Data loss, particularly under high write volume.
| Partitioning can help. There are a few ways to enable
| persistence, but you should still treat it like a cache,
| like you would Memcache or Elasticsearch.
| calgoo wrote:
| Especially in summer! I can imagine that there are quite a few
| people who will have to change their vacation plans.
| heretogetout wrote:
| Moving to a new instance of ought to be trivial -- send
| writes to both for a while, once the latest ttl is hit move
| reads. This does assume you're doing something same like
| setting short ttls (no more than a day, maybe a week).
| yashap wrote:
| Redis isn't used exclusively as a cache. It's used a lot as
| a job queue, as an event bus, for session storage, etc.
| Some even use it as a core source of truth database, though
| this is rarely a good idea IMO.
| RulerOf wrote:
| The first thing that comes to my mind when I see a Redis
| instance is "how do I flush it?"
| heretogetout wrote:
| I think each of those is nearly as easy to update, except
| the source of truth. Probably shouldn't ever go on
| vacation if redis is your source of truth!
| iamricks wrote:
| I kind of predicted this in my SO post in 2019 [1]. They were
| falling behind for a while.
|
| [1]: https://stackoverflow.com/a/58737548/6460122
| phendrenad2 wrote:
| Wow, RTG was killed by Sidekiq requiring Redis 4. Not the first
| company killed by the upgrade treadmill I'm sure. People should
| be on the lookout for projects like Sidekiq that force
| upgrades, and push back on them and/or volunteer to help make
| it backward-compatible and/or hard-fork it if the devs won't
| agree to it.
|
| Here's how that works:
|
| 1. You see an announcement. "Foobar 2.0 requires Bazz 4.x"
|
| 2. You make a friendly suggestion that they not break backward
| compatibility with Bazz 3.x
|
| 3. If that fails, you volunteer to maintain backward compat
| yourself.
|
| 4. If they reject your patches, you hard fork Foobar and try to
| kill the original project, as they are clearly not good open-
| source citizens and must be replaced.
| wut42 wrote:
| Are they really not "good open-source citizens" ? Keeping
| backwards compatibility doesn't mean a project is healthy,
| far from it.
|
| Volunteering to maintain backward compat. It can be very
| damaging in an open-source project. So let's admit you become
| the "redis 3.x" guy for Sidekiq. Now, every time the sidekiq
| project moves or tries to moves forward, they have to see
| with you to maintain compatibility ? Do they know you ? Are
| you already a contributor ?
|
| Also, who really needs to stay on Redis 3 there ? Are we
| blaming Sidekiq for killing RedisToGo, A RackSpace company,
| because they didn't "have the time" to upgrade to redis 4 ?
| Sounds like business needs. Business needs are rarely good
| open-source citizens.
| phendrenad2 wrote:
| > Keeping backwards compatibility doesn't mean a project is
| healthy, far from it
|
| How does backward compatibility mean a project is
| unhealthy?
|
| > Do they know you ? Are you already a contributor ?
|
| How is someone who shows up and volunteers to help not a
| contributor by default?
|
| > because they didn't "have the time" to upgrade to redis 4
|
| Time is money, and when you reach a certain amount of
| money, your business stops being profitable. So yes,
| presumably they literally didn't have "time" to do so.
| wut42 wrote:
| >How does backward compatibility mean a project is
| unhealthy?
|
| It doesn't mean it is, yes. Compat or not isn't a
| "healthy metric" at all.
|
| >How is someone who shows up and volunteers to help not a
| contributor by default?
|
| As a maintainer of a serious project, would you accept a
| PR adding back backward compatibility, with the premises
| of "i'll maintain it", from a random person ? It's not an
| healthy decision at all for the project to accept that,
| actually, depending on the project and the implications.
| mperham wrote:
| I'm the author of Sidekiq.
|
| Sidekiq didn't kill RTG, they chose to die.
|
| RTG decided not to offer future versions of Redis past 3.x.
| Once the owners stop investing time and effort into a
| company, they're choosing to let it die while pocketing any
| remaining profit.
| [deleted]
| hgazx wrote:
| I don't want to sound like "that guy" but what are the advantages
| of using this service instead of running Redis locally? Redis
| seems easy to run and maintain (unlike most rdbms which are quite
| complex and can fail or get corrupted in unexpected ways) and the
| latency difference of running locally instead of in a SaaS seems
| a no-brainer.
| ceejayoz wrote:
| Quite a few people used it as a Heroku add-on, where self-
| hosting isn't an option due to dyno restarts and lack of
| persistent storage.
| https://elements.heroku.com/addons/redistogo
| hgazx wrote:
| Ah, I understand that it had a free tier. Now I get it. You
| can't beat free :P
| glenngillen wrote:
| No, the OP is correct. If you're all in on Heroku then
| there is no "run redis yourself locally option". It can't
| run in a dyno, you couldn't use it to reliably persist
| state across your dynos. It's nothing to do with it having
| a free plan.
| mbreese wrote:
| The "free" part answers the obvious follow up question of
| why the shutdown of _this_ Redis SaaS provider is
| noteworthy. It's highly used with Heroku because of the
| free tier.
|
| Even the notice mentions this, emphasizing that the
| alternatives they recommend don't have a free tier.
| BigglesZX wrote:
| Heroku's own redis addon[1] has a comparable free tier
| and while I can't be certain, I'm _pretty sure_ it 's
| been beefed up recently, as I just had to migrate away
| from RedisToGo and I would have chosen Heroku's own addon
| over RedisToGo originally unless there was a compelling
| reason not to.
|
| [1] https://elements.heroku.com/addons/heroku-redis
| mbreese wrote:
| Then maybe that's why this service is shutting down? It
| was supposed to be a loss-leader, hooking people with a
| free tier. But now instead of getting more people to sign
| up and convert to paying customers, it's just a drain?
| kawsper wrote:
| We use Redislabs to run a redis-cluster for us, it helps our
| team not to focus on how redis works in clustermode, failover,
| failure-modes and routing etc.
| captn3m0 wrote:
| Owned by Rackspace since 2013[1], heavily used by Heroku apps[2],
| which calls it "#1 Redis Provider with over 50,000 Redis
| instances."[2]
|
| Surprising that while Heroku sent a mail,it hasn't updated the
| Devcenter[2], or Elements[3] listing to note down the EOL.
|
| [1]:
| https://www.theregister.com/2013/03/28/rackspace_grabs_redis...
|
| [2]: https://devcenter.heroku.com/articles/redistogo
|
| [3]: https://elements.heroku.com/addons/redistogo
| glenngillen wrote:
| The pages you linked to are (meant to be) maintained by the
| vendor, in this case RedisToGo.
| dubcanada wrote:
| I have a funny feel Heroku is in maintenance mode. It seems to
| be getting pushed aside at Salesforce.
| michaelbuckbee wrote:
| Worth noting that one of the reasons that RedisToGo is likely
| shutting down is that Heroku rolled out their own competing
| Redis product.
| jmuguy wrote:
| I'm definitely getting worried about that. Our CTO has always
| said we'd move off Heroku when we got big enough, which makes
| sense, but now I'm afraid we're going to be doing it in a
| hurry when Heroku stops caring about some aspect of their
| service we depend on.
|
| We're already sort of seeing that in a niche case - it used
| to be that credentials to access Heroku's PG databases were
| created with readonly permissions by default. That has been
| broken for some time, forcing you to connect to the PG
| instance and run the necessary SQL commands to provide
| access. Not a big deal but just another indication to me that
| the lights are on but no one is home.
| brianwawok wrote:
| How much Heroku specific stuff are you using? Wouldn't be a
| bad idea to maybe spend one cycle every few projects to
| remove a piece of that and switch to "standard" stuff.
|
| The actual dev-ops stuff isn't hard, k8s does it out of the
| box and has multiple providers. Should save you 75% of your
| hosting bill, which may or may not matter dependign on your
| scale.
| [deleted]
| enesakar wrote:
| There is Upstash! Per request pricing. Built-in REST API. Global
| replication.
| sleepyhead wrote:
| They could not find anyone to buy it and migrate customers away
| from the platform? Surely someone would be interested to
| purchase?
| wut42 wrote:
| They (Rackspace) OWNS another Redis hosting platform:
| https://www.objectrocket.com/managed-redis/. It's ridiculous
| that they didn't migrate customers instead of closing up with a
| two months notice in the summer.
| nik736 wrote:
| Weird, maybe they want to get rid of the free tier?
| captn3m0 wrote:
| They could have migrated paying customers, but didn't.
| wut42 wrote:
| They could have migrated customers while saying EOL to the
| free tier. I'm more inclined to think that they had two
| Redis SaaS offerings and the one who was less used/less
| maintained lost the internal battle.
| nicoburns wrote:
| I feel like a hosted Redis instance doesn't offer much unless
| you're using Redis for persistent data, which I suspect is a
| small proportion of the total number of Redis installs. Running
| Redis on a regular compute instance is easy!
| jaywalk wrote:
| For smaller operations that don't have "cattle" VMs, hosted
| Redis gives you the same upside as every other hosted service,
| which is that you're not adding additional VMs to maintain.
| nicoburns wrote:
| If you host on a service like Heroku, fly.io, or any service
| that supports container based hosting then you just point it
| at the Redis docker image and you're done. At most
| "maintenance" would consist of a cronjob to make it redeploy
| on a regular schedule (which would automatically deploy the
| latest version if you pick your docker base image correctly).
| melony wrote:
| Upstash developer evangelists where art thou? Come quickly,
| everyone's waiting for you!
|
| https://upstash.com
| syastrov wrote:
| For context: Heroku also has their own Redis add on.
| dev_ilter wrote:
| Well, there is Upstash you can try
___________________________________________________________________
(page generated 2022-06-13 23:02 UTC)