Sean Grove of ZenBox gave a talk at a recent Redis meetup about how they future-proofed their application using Redis. ZenBox is like Rapportive for businesses – simply install in your Gmail, and it will pull all of your customer information from different services (ZenDesk, Salesforce, Stripe, etc.) to give you the most relevant information you need when communicating with customers. You can also do cool things like refund customers while in Gmail, unsubscribe customers from mailing lists, and jump to urgent support tickets.

Due to how their app works, they require lots of concurrent connections for each application action: a single email lookup can easily result in up to 5 API requests to various apps like Mailchimp, Shopify, Salesforce, etc. In the below talk, Sean discusses some of the advantages of Redis, and how they’ve taken advantage of Redis’s unique capabilities in building their app.

Future Proof Your App with Redis from Justin Mares on Vimeo.

RedisToGo is now offering Redis Hosting in AWS EU-West-1, AWS Europe or Dublin to be more specific.

How to create AWS-EU-WEST RedisToGo Server.

Creating a AWS-EU-WEST-1 is as easy as our service on AWS-US-EAST-1. A drop-down list on the https://redistogo.com/instances/new page, lets you select your availability zone. We currently offer the same plans as in AWS-US-EAST-1.

How to create AWS-EU-WEST RedisToGo Server with Heroku.

You can setup a AWS/EU-WEST-1 on Heroku by selecting provider_and_region from the CLI.

heroku addons:add redistogo --region eu -a fat-unicorn-1337

We currently offer one Redis server per Heroku account but will be rolling out High availability with “heroku-followers” soon.

In the meantime, we can manually set this up for you. Please contact support@redistogo.com.

Tomorrow we’ll be celebrating Redis with an impromptu SF drink up. Come down for some bitter beers and Redis Chat.

Following the recent RedisToGo acquisition, we would like to invite RedisToGo users and the SF Redis community to the Southern Pacific Brewery for a beer or two.

When? ~ 6pm to late.

Where? ~ The Southern Pacific Brewery.

Who? ~ RedisToGo Crew, Rackers, RedisToGo Customers and the Redis SF Crew.

Sign up. So we know how many tables to get.

View Larger Map

This post was originally published on the Rackspace DevOps blog.

Adding Redis to your application stack is a fantastic way to gain speed with existing applications. Many of our customers aren’t running the latest and greatest new hotness NoSQL-using cloud thing. A lot of them port over a full stack of an existing applications that once only existed on bare metal servers, or use a hybrid environment with a big MySQL configuration on bare metal with web/app servers in the cloud.

In any case, we advise that customers use caching… EVERYWHERE. Adding Redis to your application stack can greatly improve site speeds when used as a cache.

Why Redis?

There is a ton of debate out there on whether to use Redis or Memcached as a cache. Both are great, but Redis provides a few features over Memcached:

• Persistence: if you restart the memcached service, you have to warm up your cache again.
• Key/Value vs. Objects: Redis is more advanced in what it can store
• Selective deletion of cached items

How do I set this up?

You can install Redis on a Cloud Server if you like, but the easiest way to start is by setting up a Redis instance at RedisToGo. The instances are configured with Redis already, and RedisToGo makes Redis easy to scale. Other features of RedisToGo:

• Graphs of connections and memory use
• Monitoring notifications on memory use and connection limits
• 1-click upgrades to scale
• 1-click multi-zone redundancy.
• Hourly backups
• Paid plans persist data to disk on a RAM flush

Once Redis is installed and online, you need to configure your application to use it. The example below uses Predis, a PHP client library. There are plenty of clients to use with Redis, so you can pick and choose based on your preferred language.

The example below is from on a fantastic tutorial by Jim Westgren and is specific to WordPress-based sites, but WordPress specific code can be stripped out for use with just about any website. Enjoy!

This week, we had a question from one of our customers, Arjun from HeadOn Labs, I thought would be worth covering on the blog:

“We have decided to use Redis as our primary data store. There will be a custom full-text search inverted index on Redis. And Socket.IO will need Redis for managing channels and rooms and clients. My question is, should I have these 3 parts on 3 different Redis databases or the same Redis database? Which one is better and why?”

This is a great question that has come up a few times. Should you use a single Redis database or multiple for running different operations?

Like most things in life, there are pros and cons for each. The main benefit from using 3 different Redis instances comes from what happens during a failure scenario. If you were using 3 instances, each one would fail independently. Handling each action on a separate instance would also provide more connections, which could be useful for ensuring strong performance.

The disadvantage of this approach is that it is more expensive than running one instance, and gives you more to manage (unless you’re using a hosted Redis provider like RedisToGo. We’ve heard good things about them).

On the other hand, running 3 databases on the same Redis instance would save money and result in less management if you were doing the self-hosted option. This can work if you’re not using Redis to store critical data. You could also use a follower to create redundancy in case things go bad.

However, especially if you’re considering using Redis as your primary data store (like the guys at Moot did here), this could be a dangerous approach if something was to happen. If there was a failure of some kind, you’d have everything go down and lose your critical data. When all your eggs are in one basket, any kind of error can have series repercussions. If you’re planning on doing this, be sure to take advantage of replication features. Basically, replication gives you another basket in the case of a failure. If anything were to happen to the master, you’d have your data and be able to switch to your backup instance immediately. You can learn more about replication here.

How are you using Redis? What did you consider when deciding on your setup? Answer in the comments – best answer will receive a RedisToGo hoodie and a free month of our Startup plan!

At Wednesday’s 2nd Redis meetup, we had a presentation by Manju Rajashekhar, the creator of twemproxy. Thanks Manju for the great presentation!

To stay in the loop about future meetups, join the SF Redis meetup group! If you have any talks you’d like to see in the future, tweet us!

After an amazing turnout for the last Redis meetup (80+ people!), we’re having another one!

This event will be on Wednesday, April 17, at the Rackspace offices on 620 Folsom Street. Doors open at 5:30, and we’ll start presentations at 6:00. We can accommodate up to 150 Redis programmers.

The event will include a 30 minute presentation followed by an open floor Redis discussion. We were lucky enough to get Manju Rajashekhar, the creator of Twemproxy, to drop by and give a presentation.

If you’re interested in coming, please RSVP on the Redis SF Meetup Group. RedisToGo will providing a selection of local beer and snacks.

Again, the event is at the Rackspace offices at 620 Folsom Street.

View Larger Map

We currently have four other speakers lined up for other dates. If you’re interested in talking at future events please e-mail ben@redistogo.com

As part of today’s Exceptional acquisitions, we’re proud to announce that RedisToGo, will be joining the Rackspace family along with Exceptional.

The Redis Community Rocks

We’ve seen the Redis community flourish in its x years of operation. Developers have continued to find uses for the database beyond our imagination. Meanwhile, Salvatore has continued to amaze us all with his developers in 2.6, and the soon to be released Redis Cluster.  Sponsoring the first international Redis Conference last year was a major highlight. And we’re constantly impressed by the friendliness of the Redis Community. It’s been our pleasure  serving all our customers.

KISR

We’ve always had the vision to Keeping It Simple Redis hosting. Within five seconds, we provide a complete Redis server fine-tuned for a production application. As we built out our services, we’ve continued to architect Redis solutions for scalable applications; from fast scaling iPhone apps to apps for multinational corporations.

Faster, More Robust Redis Servers

Reliable apps, require a reliable cloud, and we’ll get that by joining Rackspace. We’ll continue to support our customers in AWS.

What’s next?

As we join Rackspace, we can’t wait to work even closer to the metal and network. Building and scaling Redis to the next level, with a simple UI that lets developers worry about building apps, and not scaling their Redis server.

With Thanks

We would like to thank Salvatore Sanfilippo for creating Redis, VMWare for sponsoring the project, Jon and James Bracy for getting RedisToGo off the ground and Blake Misrancy for planting the first seeds of RedisToGo.

Lastly, a big thanks to you, our loyal customers.

For customers in San Francisco, we’ll host the next Redis SF meetup in Rackspace office on the April 17th.

Got more questions? Check out our FAQ?

Here’s a cool talk to check out. Ryan Briones spoke at the 2012 Scottish Ruby Conference about using Redis as your primary data store. He makes a case for doing random stuff with Redis just because, to see what will happen. Crazy talk! Why waste all that time building a whole database with Redis when you know it’s not going to scale to the 800 million daily unique users you will definitely have one day?

Because Redis’ unique structure forces you to think about things and work around things in a way that you wouldn’t have to if you were throwing together a quick database in SQL, which you already know how to do in your sleep. Just hear him out. He makes a good point.

D2_ML_03-Ruby1280_b.mp4 from Neo (UK) on Vimeo.

But let’s not leave it there. The lessons we’re learning, the foresight we’re gaining, by taking some time to fool around with Redis can be applied to more than just our database structure. Because isn’t your startup also a prototype for something bigger? When you have those 800 million unique users daily, you’re definitely going to need more people on your team than yourself and Bob. But working with Bob has taught you a lot about how to create systems that work and can continue to work as you gain more and more traffic.

Your startup isn’t just a company, and Redis isn’t just a tool for creating databases. Both are prototypes, incubators, test-driven terrariums for the Amazon. Or maybe the next Amazon.

RedisToGo is proud to introduce Followers to provide a ‘one click’ setup for a local or remote slave.

We’re happy to announce that we’ve made making a slave server super easy with RedisToGo. With one click a second slave server in US-East or US-West.

A slave is a replicated exact copy of master servers. A slave is useful for both scaling out reads, and for creating a simple high availability Redis solution. Failover can be completed in a client, or having a second server increases redundancy in your application.

Once setup, The master links to the slaves on the instance dashboard. You can add more followers, and promote slaves to master from the RedisToGo UI. Slaves are charged at standard RedisToGo rates.

Once you’ve setup your slaves we recommend you add them to your client. These few projects will have get you started

1. https://github.com/oggy/redis_master_slave
2. https://github.com/sreeix/redis-proxy