Redis To Go is shutting down | Hacker News Reader

Redis To Go is shutting down

redistogo.com

66 pointscaptn3m052 comments

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

I have a funny feel Heroku is in maintenance mode. It seems to be getting pushed aside at Salesforce.

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.

Worth noting that one of the reasons that RedisToGo is likely shutting down is that Heroku rolled out their own competing Redis product.

The pages you linked to are (meant to be) maintained by the vendor, in this case RedisToGo.

> We wanted to communicate this as early as possible

Two months is a bit short for a database change, don't you think?

Especially in summer! I can imagine that there are quite a few people who will have to change their vacation plans.

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.

The first thing that comes to my mind when I see a Redis instance is "how do I flush it?"

Redis is not a database. Please, do not use it for persistence. I have been bitten too many times by services that tried.

I am curious, what all kinds of issues you ran into?

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 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

Ah, I understand that it had a free tier. Now I get it. You can’t beat free :P

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.

[1] https://elements.heroku.com/addons/heroku-redis

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

See my SO question for this - https://stackoverflow.com/questions/72695052/migrating-from-...

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 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

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.

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.

If Sidekiq supported Redis 3, maybe they wouldn't need to spend an untenable amount of time and effort on the company, and users wouldn't be impacted.

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'm not saying you should be disallowed from anything, its your project. I'm just calling for people inconvenienced by this to do more.

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).

They could not find anyone to buy it and migrate customers away from the platform? Surely someone would be interested to purchase?

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.

Weird, maybe they want to get rid of the free tier?

They could have migrated paying customers, but didn’t.

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.

For context: Heroku also has their own Redis add on.

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.

Upstash developer evangelists where art thou? Come quickly, everyone’s waiting for you!

https://upstash.com

Used this a lot before the Heroku official Redis provider went online. Kinda wonder why Heroku didn't just buy them?

Try out upstash, it offers serverless redis where pricing scales to zero.

Well, there is Upstash you can try

There is Upstash! Per request pricing. Built-in REST API. Global replication.

Reply on news.ycombinator.com