Why Redis Needs Enterprise Developers

It sounds strange now, but it was at least a couple of years from the moment I released the first open source version of Redis, to the moment I started to hear “enterprise” in the context of Redis.

I first realized how important Redis had become in the context of big companies when I was in Cologne at the NoSQL Matters conference in 2012. Within hours I was approached by a number of important companies, including ones operating in the financial market, that told me stories about how they were using Redis, sometimes without full approval from their superiors since it was lacking commercial support and the boss was afraid to provide the green light. At some point one engineer said, “Even though it hadn’t been approved, Redis was the only way we had to deal with the increasing traffic in this service, so we continued to use it.”

It’s fair to say that Redis found its way inside the enterprise without any need from my side to push its adoption. Redis’ odd tradeoffs and use cases make it a solution that is hard to match using other technologies, when applied to the right problem set. Developers saw the fit and applied it, at some point. One thing that helped a lot is that Redis has always been an extremely stable piece of software. There are bugs like in every software product, but it is very uncommon to see Redis crashing or misbehaving. From my perspective it was easy to see why enterprise developers needed Redis, what surprised me was how much Redis needed enterprise developers.

Enterprise developers started to have a serious effect on how Redis was developed. This was through feedback in the open source ecosystem. The more users you had doing critical work, the more the conversations started to change in tone. Instead of stressing a new feature, the conversation turned to replication or making persistence more robust, improving high availability and making clustering available. I think that as a leader of an OSS (open source software) product it is important to know when to say “no.” But is also important to understand when something is really needed in certain environments. The effect of enterprise developers on Redis was to drive me towards a development roadmap more focused towards scalability and reliability, when compared to my initial plans.

As a side effect, the development of new features slowed down a bit, and more fundamental work to Redis was performed instead. Certain people saw this as a problem, and many others were very happy. Things like Redis Sentinel that provided an easy to use high availability solution for Redis, in the end aided “non-enterprise” companies too. This was not an imposition on me or the community. I had begun Redis with the idea of providing reliable software and stable APIs. The Redis API has almost always changed in a backward compatible way. While this is very desirable in an enterprise environment, another school of thought believes that it is a good idea, infrequently, to break the API, refactor and clean it. For me, however, the value of upgrading with little effort was too important to give away to aesthetics.

Certain enterprise requirements are important to resist for some time or forever, if possible. Common requests I receive from corporate environments are about strong ACLs, SSL support, Named Lua scripts, rollbacks on transactions, and so forth. I can see how many of those features are useful, however, some of these may not fit with the original Redis design. I’ll end up implementing some of these, but it is important to balance the input you receive from enterprise companies as well as feedback you receive from the innovators and startup environments.

In the fast world of software development, you need both people that can innovate with very fast iterations, like open source and startup developers, to push forward functionality. At the same time open source communities need enterprise adoption to push reliability and stability boundaries.

About the author: Salvatore Sanfilippo is the creator of Redis and leads open source development at Redis Labs. Salvatore started his career in 1997 as a security researcher, writing the hping security tool and inventing the Idle Scan. Later he worked on embedded systems, focusing on programming languages research and creating a small footprint Tcl interpreter, which is still in active development. With a colleague, Salvatore created the first two Italian social applications in partnership with Telecom Italia. After this experience, he decided to explore new ways to improve Web app development, and ended up writing the first alpha version of Redis and open sourcing it. Since 2009, he has dedicated most of his time to developing Redis open source code. He lives in Sicily, Italy.

Related Items:

Redis Labs Emerges to Push Hosted NoSQL Business

Five Ways Open Source Databases Are Best for Business

Five Ways Open Source Databases Are Limited