Everything changes rapidly. If you poke around Github, you will always find something new to tinker with thanks to open source. My team reflects that attitude too and if only we had more hours in a day to play with the latest hip libraries like React.

I’ll admit the number of possibilities gets overwhelming. Today’s cool thing might not be shiny a few months later. I’m always searching for new technologies to absorb into our tech stack and here’s a few things I think about before I allow something to enter production.

Here’s a few real cases I dealt with.

In 2011, I used Ferret to create a soft real-time (5-10 min. delay) indexing system for text searches. I remember the library had a few memory leaks we had to patch in C. I began looking at other open source options like Sphinx and Solr. Along came Elasticsearch. I played around with it, and.. it crashed given the amount of data I had to feed it. In 2012, I revisited the project with an intern and the project was far more stable.

I ended up with Elasticsearch because the documentation was the best and I remember getting a ton of help in the IRC channels.

Memcache’s Key Limit on Length

There might be a way around it. But I couldn’t figure it out. I remember investigating LevelDB and TokyoTyrant as a possible key-value store.

I finally found Redis, and never looked back. That was also the only project I could think of that was stable right out the box as early as 2.2.0.

I don’t think I’ve hit a quirk or edge case with Redis ever.

Adding to your stack

My team is always on the lookout for up and coming open source projects. That could be from trending projects at Github or reading Hacker News. Sometimes we get a glowing recommendation from a friend.

When we find something promising, we begin trying out non-critical projects with the new open source project. Recently we’ve adopted Gulp for the frontend.

I don’t allow anything to enter production if it crashes during a trial run. I can’t take that risk. For example, one of the engineers setup a Kafka cluster and fed test data through it. The entire cluster just broke in a few minutes. Just like Elasticsearch, I will probably need to wait awhile.

Upgrading

Never immediately upgrade to the latest major number release. For example, if Rails 4.x is out, don’t immediately use it. Wait a little for the experts and hobbyists to comb through it. If you have engineers insisting on trying the edge versions, I would allow upgrades to non-critical systems like a web interface for internal tools. I wouldn’t immediately jump on the next version for a production environment with paying customers.

Roll out the new version in stages. Direct a percentage of traffic to a separate cluster.

And I’d still wait for the community to find issues with the new version. There are always issues. How much? I can’t quantify this yet. This is a good opportunity to look up numbers and back my experience with data.