Enterprises today face a fast-changing market where the time-to-market keeps shrinking. This hyper-competitive market requires organizations to implement changes to applications and infrastructure much faster than they did in the past.
These organizations are additionally challenged by critical legacy systems with operational procedures built to maintain maximum availability and sustainability as a vital business advantage. These operational procedures are designed to regulate the implementation of changes to prevent outage and data loss. In practice, they set a structured path for upgrades, restricting frequent changes so, in case of a problem, it’s easier to identify the change that caused the problem and revert the system to the pre-changed state.
Organizations must balance stability and innovation. They have to stay competitive while maintaining maximum uptime. A recommended way to do so is to follow the “divide and conquer” strategy: By identifying and prioritizing the different system components, you can gain more control over the process.
A system comprises several layers and modules, not necessarily coupled or sharing the same requirements and limitations. Dependencies could exist between different components of the system, but usually a different upgrade strategy can be applied per each. An operating system can be upgraded due to reaching end-of-life, for example, separately from upgrading the software and applications it runs.
During the course of the system life cycle, there could be many reasons to upgrade: compliance, security exposures, infrastructure end-of-life, new functionality, better performance, and more. Ideally, we would have it all, but outside forces usually dictate a specific order. Which infrastructure or application should be updated first and which one can be delayed are decisions you need to make. For example, a major driver for update are external non-negotiable requirements such as security regulation compliance. Regulations often set a deadline which cannot be changed.
In order to gain control over changes introduced to your systems, you should:
In enterprise grade software it’s critical to have flexible adoption paths. Flexible adoption paths enable you to upgrade and modify your system in smaller units of work, based on the organization’s goals and requirements. Each component should be upgraded to the level that serves the business needs best.
Starting with Redis Enterprise v6.2.4 you can choose the Redis server version you want to upgrade to according to your upgrade cadence tolerance. Choose the latest Redis if you can tolerate frequent upgrades and want to leverage the newest enhancements, or stick with major releases if you want to minimize the number of times you upgrade. This flexibility is designed to support the release of more than one open source Redis version a year, while maintaining a longer product life cycle for Redis Enterprise Software. Specifically, organizations that want to utilize the 18-month long product life cycle can take advantage of the seamless upgrade path by adhering to major Redis releases.
Redis recognizes that many organization’s environments consist of both rigid, legacy-based systems and flexible, cloud-based systems. Redis has designed an upgrade process that can easily conform to whatever your operational procedures require. Redis Enterprise upgrade process is a non-disruptive upgrade (NDU), meaning you can upgrade your systems with no impact on availability. Redis maintains support for three levels back of open source Redis so that you can determine the upgrade process that’s optimal for your organization. This NDU upgrade process and backward compatibility are designed to ensure availability and performance while giving you the latest in Redis Enterprise innovation. Get the latest Redis Enterprise data platform functionality when you need it while adhering to all your operational procedures by identifying what needs to be upgraded and prioritizing based on your needs.
Redis Enterprise Software is a real-time data platform based on open source Redis, delivering enterprise capabilities for a high-performance cache and primary database. Redis Enterprise is often used in a multi-tenant cluster configuration.
By continuing to use this site, you consent to our updated privacy agreement. You can change your cookie settings at any time but parts of our site will not function correctly without them.