It's worth noting that these are the same guys that donated the redis.io site to the project and the maintainers of the redis-rb ruby bindings, developers of Ohm object mapper, and so forth. It's very cool to see them creating this new project.
From what I read they are partially doing it actually, I mentioned that the services were too overpriced, and this is cheap, and that backups, high availability with replication and automatic failover, redis cluster management, should be the interesting parts of this kind of offering.
It seems like they have plans to do part of this stuff for the small price they as: "without the hassle of setting up backups, monitoring and replication", but I think ip failover is an important option that should be added eventually.
That is, as a user of a managed instance I want a master <-> slave setup that is totally transparent to me, I just know I payed for this optional service, and that if something goes wrong with my master I'll receive an email message with a warning and automatically the IP address (or all my requests at an higher level) is routed to a different instance (a slave elected to master).
Awesome, thanks for the response -- the info on their site was a bit minimal. IP failover would be a big win, as would slave-based flushing and the "live" upgrade of available memory like you had mentioned int he podcast. Anyway, redis kicks ass, keep up the good work!
Hopefully we will add more info in the next few days, truth is we had way more signups than we expected (a good thing!) and we have to take care of a lot of things. Future is bright and reliability is the are where we want to put more effort.
I can see this being incredibly useful for some use cases of redis (pub-sub maybe). There are of course others, such as using redis as a memcache replacement, where latency is going to be a much bigger issue...
That's a good idea if I understand it correctly. That is, taking a Redis instance, modifying it in some way so that Pub/Sub supports authentication (probably this means creating an HTTP wrapper?) and then you have a inter-cloud messaging system that is similar to "twitter for computers".
Actually, I was just suggesting that using commands like PSUBSCRIBE, PUBLISH are probably "high-latency" safe, because the general use cases (job queues, delayed writes, real-time web) for that are "soft realtime."
High latency won't mesh well in a situation where you need to do 100s or 1000s of writes at per request, or 100s of reads at a time, and so a hosted service seems less ideal to me for those situations.
Maybe my outlook on this is wrong, or I'm misinformed.
EDIT: catching up on other threads, it seems as though latency will be less an issue since they'll host on EC2, or Rackspace Cloud, or wherever demand is needed. That's smart, and not something I initially thought of.
Boring. The best heroku-addon remains the memcached-addon. It makes me laugh out loud every time I hear about it.
50GB instance for... $3500 USD/month.
But hey, it's on a "fully managed server". Racked on a persian rug. Gold-plated with laser-gravure of your choice. Polished daily by a dedicated english butler.
Seriously, what? Why can't I get a 512 MB vhost for $20/mo? Is the convenience of not having to type apt-get install redis-server worth the extra $90/mo?
Site looks nice. You might want to spruce up your copy a bit. "Finally a hosting service with minimal premium fees applied" sounds a bit stilted. "openredis. Premium hosting. Minimal fees."...
Or better yet, focus on the problem you are solving (time & money spent managing a redis server). "openredis. Redis hosting made easy." or "openredis. redis hosting without the headaches".
Awesome idea... I was just thinking about how great something like this would be. Moving our infrastructure over to EC2 soon, and was going to implement Redis for session storage but was a little worried about having to manage it all myself, including master-slave replication. This sounds perfect!
I've found different use cases for Redis tend to require different configurations (persistence mode, key eviction policy when at maxmemory setting, VM vs no VM, etc). How much per-instance configuration do you plan to support?
Hey Sam, currently we can support a great deal of customization, but we need to figure out how to best expose that. I think we will post updates to the Redis mailing list.
They are going to buy lots of RAM. I'm excited about redis nodes running on low power, small ARM A15-based linux servers with lots of RAM and an SSD. Diskless, fanless and 3-5 watts per node in the data center.
