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).
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.
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!
Yeah, agreed, though if you’re using Redis as central pub/sub infra in an environment with tonnes of different services who produce and consume events, a migration can get tedious. Certainly not as bad as traditional DB migrations, but doing it under a short timespan could still be a pain.
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.
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.
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.
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.
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.
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.
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.
> 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.
>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.
So what does one need to do in order to go from "random person" to "accepted contributor"? Do I need to fix typos on the README for awhile? Do I need to fix random bugs for awhile? Or do I need to go to work for the company that sponsors the project? We shouldn't automatically assume that a more restrictive approach is more "healthy" here. It all comes with tradeoffs.
Yes, it was the point I was trying to make: it all comes with tradeoffs. Sidekiq choosed to not go forward with backwards compat, and I don't feel it make them "bad citizens" like you implied in your original comment.
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.
Do you think no software should ever upgrade dependencies? Do you think it's unreasonable to want to take advantage of new features in newer versions? Why should I lock Sidekiq to Redis 3 forever? When am I allowed to require Redis 4?
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.
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
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.
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.
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.
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?
This redis add-on was the original one, developed by Heroku and then spun out and handed over to a different team to operate. It’s been running successfully for something like 12 years. Has been acquired/changed owner 3 times. Has withstood the numerous challenges from competitors in what is arguably one of the most competitive parts of the add-on ecosystem.
It has been successful and had its time. To suggest this has anything to do with it having a free tier is to not understand the trajectory of the business at all.
I've been hit by this too. Can anyone advise how to migrate from Redis toGo to Heroku Redis? Perhaps its as simple as uninstalling redis-to-go and installing e.g. something like
heroku addons:destroy redistogo
heroku addons:create heroku-redis:hobby-dev -a your-app-name
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.
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!
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.
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).
Back in 2012-2013 my first real idea was to provide redis as a service , even got a domain and a basic MVP. Mailed heroku folks about listing this as an addon.
We never heard back from them and I moved on to other ideas.
I was glad to see redistogo back then execute successfully.
It's s different game now.
55 comments
[ 3.0 ms ] story [ 128 ms ] threadTwo months is a bit short for a database change, don't you think?
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
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.
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.
[1]: https://stackoverflow.com/a/58737548/6460122
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.
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.
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.
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.
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.
Even the notice mentions this, emphasizing that the alternatives they recommend don’t have a free tier.
[1] https://elements.heroku.com/addons/heroku-redis
It has been successful and had its time. To suggest this has anything to do with it having a free tier is to not understand the trajectory of the business at all.
heroku addons:destroy redistogo
heroku addons:create heroku-redis:hobby-dev -a your-app-name
See my SO question for this - https://stackoverflow.com/questions/72695052/migrating-from-...
https://upstash.com
I was glad to see redistogo back then execute successfully. It's s different game now.