This article is based on an interview originally published by DevOps Online with Howard Ting, then-CMO at Redis. The original post appeared on BestDevOps on 17 January 2020.
Background: Two Announcements from Redis
Towards the end of 2019, Redis made two announcements aimed squarely at its developer community. The first was the release of RedisInsight, a free GUI tool that lets developers manipulate, visualise, and analyse data stored in Redis without leaving a graphical interface. The second was the launch of a Redis Developer Certification Programme, designed to formally recognise proficiency in building applications with Redis.
Howard Ting, Redis’s CMO at the time, spoke to DevOps Online about the reasoning behind both initiatives and shared his broader views on database architecture trends and the DevOps mindset.
Why a Developer Certification?
The certification was conceived as a way to bring consistency and credibility to the Redis ecosystem. Ting explained the core motivation:
“It’s about bringing more consistency and credibility for Redis developers. When someone is looking to hire a developer, they will know that with this certification, they have at least a bare minimum level of credibility and expertise.”
Howard Ting, CMO, Redis
The exam covers the topics Redis considers foundational for effective development:
- Data structures – understanding Redis’s native types (strings, hashes, lists, sets, sorted sets, streams, and more)
- Data modelling – how to structure data appropriately for Redis rather than forcing relational patterns onto a key-value store
- Best practices – patterns for reliability, key naming, eviction policies, and client usage
- Database setup and optimisation – configuration tuning for a given use case
The exam is 90 minutes long, taken online, and is proctored to ensure the credential carries genuine weight. Redis indicated the programme would evolve based on community feedback over time.
Industry Trend: From One Database per Thousand Apps to One App with Many Databases
Ting offered a striking framing of how the database landscape has changed in the microservices era:
“20 years ago we had one database supporting 1,000 applications. Now we have one application that might have 1,000 databases.”
Howard Ting, CMO, Redis
This inversion reflects the polyglot persistence approach that has become common in cloud-native architecture. As microservices decompose monolithic applications into independent, loosely coupled services, each service can—and often should—choose the database type best suited to its specific data access patterns. A session store might use Redis, a product catalogue might use a document database, and financial ledger data might live in a relational database, all within a single application.
The explosion of Kubernetes as a deployment platform has accelerated this trend, making it operationally feasible to run many different stateful services side by side at scale.
Performance Engineering: Design for Elasticity First
On the question of performance and debugging, Ting’s advice centred on understanding the elasticity profile of an application before choosing where data should live:
- Highly elastic applications – workloads with large, unpredictable usage spikes need databases that can absorb sudden load. In-memory databases such as Redis are well-suited here because reads and writes happen at memory speed.
- Predictable, steady-state applications – workloads with consistent throughput have more flexibility in storage tier selection, and the cost advantages of disk-backed storage become more relevant.
Ting also pointed to an emerging two-tier data model that he expected to become standard:
- Hot tier – fast-moving, frequently accessed data stored in DRAM or fast SSDs. Persistent memory (technologies that behave close to DRAM speed at lower cost per GB) was highlighted as a growing option here.
- Cold/archival tier – slower-moving or historical data stored on traditional disk or flash-backed databases in the back end.
The practical takeaway for developers designing data-intensive, highly personalised, or real-time reactive applications is to start with an in-memory database as the primary data layer rather than retrofitting one later.
Optimising Data Management: Pick the Right Tool and Plan Long Term
Ting distilled data management advice into two principles:
- Pick the right tool for the job. No single database is optimal for every access pattern. Evaluate whether your data’s characteristics—size, access frequency, query complexity, latency requirements—align with the database you are considering.
- Plan for where the application is going, not just where it is today. Ting warned against choosing a solution that creates a dead end, forcing a complete application refactor once scale or data model requirements change. He encouraged thinking in multi-year horizons when evaluating platforms.
DevOps and Automation: The Core Infrastructure Must Be Stable
Asked how Redis itself was applying DevOps principles internally, Ting’s answer was grounded in the relationship between automation and developer velocity:
“It’s just not intuitive of the DevOps mindset to continue to deploy new features and capabilities quickly [without stable infrastructure]. You want to have the core infrastructure be as stable, solid, robust, and resilient as possible.”
Howard Ting, CMO, Redis
The argument is straightforward: if teams are manually handling routine operational tasks—sizing, deployment, upgrades, scaling, and recovery—those are human cycles that cannot be spent on higher-value work. Automating the mundane creates the headroom that allows continuous delivery to function sustainably.
This is a commonly cited principle in the DevOps community, and it aligns with the broader industry push towards infrastructure as code, self-healing systems, and operator patterns for managing stateful workloads in Kubernetes environments. Redis has invested in managed cloud offerings and Kubernetes operators to push operational complexity down the stack, away from application developers.
Key Takeaways for DevOps and Platform Engineers
- Polyglot persistence is not a trend to resist—it is a natural consequence of microservices decomposition. Plan your platform to support multiple database types.
- Design your data tier around your application’s elasticity profile. High-variability workloads benefit disproportionately from in-memory storage.
- A two-tier hot/cold data architecture is a pragmatic way to balance cost against latency requirements as persistent memory options mature.
- Automating infrastructure operations (scaling, recovery, upgrades) is a prerequisite for sustainable continuous delivery, not an optional enhancement.
- Developer certification programmes can raise hiring confidence in communities built around open-source tools—but verify what a specific certification actually tests before treating it as a proxy for seniority.