Plan ahead for Cloud Pak for Data lifecycle events
TL;DR
After CPD 4.5, there will not be any more 4.0.x monthly releases. Instead, monthly releases will proceed in 4.5.x form.
While CPD claims compatibility with specific versions of OCP based on our internal testing, we cannot provide support for specific versions of OCP beyond what RedHat provides.
Overview
As we chartered this year’s release planning, we found that it is crucial to drive clarity on how we deliver value to our customers. This became amplified by the fact that our customers range from small/medium businesses to multi-billion leaders in a space. With such a diverse set of customers, there is a wide range of preferences regarding software lifecycles. While some customers expect traditional release processes with fewer updates but more stability, others prefer an agile approach where they are on the cutting edge and may be open to slight unknowns. As an enterprise-grade business-critical product, IBM Cloud Pak for Data must look through all such requirements and carefully model a delivery/lifecycle model that fulfills such a range of customer profiles. In this blog, we will point out some of the key principles of CPD’s lifecycle with a few examples from recent release plans.
Introduction
Through user research, it has become clear that there are two conflicting profiles of CPD customers. Some customers are used to the “release” cadence of SaaS solutions and expect CPD to rapidly iterate and deliver innovations the moment they are ready for use.
Others, typically larger enterprises with robust corporate requirements and highly sensitive data, just want a platform that works. Once they have a configuration running in production, the last thing they want is an update that could break what they’ve spent so long setting up.
In addition to these opposing customer needs, there is the internal reality of limited resources which lurks in the background. Given limited development resources, each code stream that needs to be maintained separately compounds the amount of work necessary to maintain CPD’s strong security and performance postures.
What is Continuous Delivery?
Our solution to these three demands is to implement a version of what is called “Continuous Delivery” in the industry, starting in CPD 4.0. The premise of Continuous Delivery is to find a middle ground between SaaS’s rapid delivery of innovations and traditional on-premises software lifecycles in which customers might have to wait up to a year for a bug fix.
The major paradigm shift in Continuous Delivery is that Cloud Pak for Data transitioned from only having major releases to having major releases, minor releases, and monthly updates. The definitions of these are described below.
By embracing this implementation of Continuous Delivery, CPD has found a middle ground to fulfill the requirements of the three groups of stakeholders described above. Customers who always want the latest and greatest can choose to update to every new monthly update and/or to minor version. Customers who prefer stability to currency can choose to only upgrade to major releases every two years. And, by taking advantage of minor releases, we can release features without creating new code streams, reducing the burden on our development teams.
After CPD 4.5, there will not be any more 4.0.x monthly releases. Instead, monthly releases will proceed in 4.5.x form. This is due to the fact that 4.5 is in the same code stream as 4.0. Please refer to the diagram below for clarification.
Openshift Lifecycle overlap
Besides these three groups of stakeholders, there is one more, non-human stakeholder in CPD’s lifecycle: Openshift Container Platform (OCP). By corporate mandate, CPD must provide support for new versions of OCP within 30 days of each GA release of OCP. Given this mandate and the fact that CPD is built on OCP, CPD’s lifecycle is inextricably tied to OCP’s lifecycle. The diagram below attempts to clarify the timelines involved.
It is important to point out that sometimes a version of OCP will go out of support before the version of CPD which it runs on it goes out of support.
Cloud Pak for Data 3.5 is a prime example of this. CPD 3.5 is currently certified on OCP 3.11, 4.5, and 4.6. OCP 4.6’s support from RedHat, however, ends in October 2022. Meanwhile, CPD 3.5’s support is planned to end in April 2023, leaving a 6-month gap in which there would be no version of OCP that is both certified to run on CPD 3.5 and which is supported by RedHat. To continue to support CPD 3.5 customers until CPD 3.5’s end of support, we plan to recertify CPD 3.5’s July refresh (3.5.r16) on OCP 4.8. Thus, customers who want to remain on CPD 3.5 should plan to upgrade to OCP 4.8 between July and October 2022.
While CPD claims compatibility with specific versions of OCP based on our internal testing, we cannot provide support for specific versions of OCP beyond what RedHat provides. This means that if the version of OCP which a Cloud Pak for Data cluster is running on goes out of RedHat support, problems that may arise that involve the out-of-support version of OCP will not be covered by IBM or RedHat support teams.
A good way to avoid having to upgrade your version of OCP is to take advantage of RedHat’s Extended Update Support (EUS) option. Users of even-numbered versions of OCP (i.e., 4.6, 4.8, etc.) with RedHat Openshift Premium subscriptions are eligible for RedHat’s EUS, which provides a longer time span of support. In order to take advantage of OCP’s EUS, customers must ensure they are on the EUS channel of OCP (more details here).
By utilizing minor and monthly releases in a Continuous Delivery framework, we hope to capture the best of both worlds when it comes to the spectrum of on-prem software lifecycle approaches. Additionally, in coordinating our release schedule to RedHat’s, we continue to demonstrate the immense benefits of the synergy between IBM and RedHat. In doing so, Cloud Pak for Data can serve a wide range of customer profiles while retaining the development resources to keep shipping market-leading solutions that help enterprises make their data useful.
References
(1) Redhat Openshift lifecycle page: https://access.redhat.com/support/policy/updates/openshift
(2) IBM Continuous Delivery Policy: https://www.ibm.com/support/pages/ibm-continuous-delivery-support-lifecycle-policy
(3) Openshift EUS details: https://access.redhat.com/documentation/en-us/openshift_container_platform/4.6/html-single/updating_clusters/index#eus-4y-channel_understanding-upgrade-channels-releases
