Red Hat's OpenShift Update Strategy: If You Want Alpha/Beta Kubernetes Features, You Can Have Them

Red Hat has been making a lot of news over the past two weeks, with product and services announcements fairly gushing from the Red Hat Summit online event last week, as well as IBM's online Think event, which is wrapping up today.

Red Hat kept its identity as an open source powerhouse more or less intact after IBM closed the deal to acquire it last year, but Big Blue is definitely leveraging the fruits of that acquisition. Red Hat's OpenShift hybrid cloud application Platform-as-a-Service (PaaS), in particular, was in the spotlight at the both events.

A week earlier, I had an opportunity to talk with Brian Gracely, senior director of product strategy in IBM's Red Hat OpenShift group. Gracely lives "at the intersection of new technologies and new business models" (cool image). More from his LinkedIn profile: "Take complex new technologies, figure out the future business opportunities, connect the dots across the industry, simplify it and explain it to people in suits or t-shirts. That's what I do."

Clearly, this was the right guy to help me understand Red Hat's quirky OpenShift feature release strategy. OpenShift is built on the open source Kubernetes project, which has a new release approximately every three months, give or take a day. Within those Kubernetes releases, however, are features and capabilities classified as alpha, beta and GA (generally available).

Red Hat's OpenShift is upgraded on a four-to-six-month release cadence, which puts them about three months behind the open source project releases. "Three months later, we've done the integration testing, scale testing, fixed some bugs and updated our documentation for better training," Gracely told me. "It's a cadence that works for us and our customers."

However, in any given Kubernetes release, there might be -- let's say for the sake of this explanation -- half-a-dozen GA features, maybe 10 or 12 beta features, and 15 or 20 alpha features. Gracely explained, "What we find with customers is that the majority of them want GA stuff only, because those features are going into production and stability is a top concern. But there's also a subset of customers -- sometimes they're in a unique industry; sometimes they have a unique use case -- who want access to those alpha and beta features immediately."

To accommodate the needs of those customers, Red Hat created "channels" through which its customers could have easy access to those features classified as not ready for prime time. "It lets our technology partners have early access to the software," Gracely said. "It lets systems integrators who have to do some follow-on work have access to the software. And it gives customers, who say, 'I need to start testing this new stuff as early you can get it to me' the access they need. It's kind of new a way of distributing Infrastructure Center of software."

Red Hat has refined its understanding of Kubernetes over the years, Gracely said, and compensated for the early limitations of the platform when it came to extensibility and modularity. "Back in 2015, Kubernetes was just kind of a giant hunk of software," he said. "So, as stuff was added to it, it just became a bigger hunk of software, kind of a ball of mud."

Two years into the project, Red Hat made the platform extensible to accommodate new and useful features that needed the platform, but were not part of the Kubernetes core. Originally called third-party resources, they're now known as custom resource definitions (CRDs). "The CRD provides a standard way to extend Kubernetes without breaking the core stuff," Gracely said. "If you have new things to add, here's how you add them in a structured way."

The CRD was developed a year-and-a-half ago. As current examples, Gracely pointed to the service mesh project and serverless -- tech that lives on top of Kubernetes, but remains apart for the core project. But the CRD didn't remain static; it evolved, Gracely said, into "operator patterns."

"Operators are software extensions to Kubernetes that make use of custom resources to manage applications and their components," the org's Web site states. "The Operator pattern aims to capture the key goal of a human operator who is managing a service or set of services. Human operators who look after specific applications and services have deep knowledge of how the system ought to behave, how to deploy it, and how to react if there are problems."

"And so, while we have main versions of Kubernetes that come out, we now have the ability to say, 'Oh, I have an operator extension for something new that doesn't have to be bound to a specific release,'" Gracely said. "And what that means is, 'I don't have to wait for multiple releases in order to get access to something new.' It's another way of adding flexibility to Kubernetes, while staying true to the projects, making sure your APIs are compatible, and not slowing down your ability to ship new software or a new feature.

OpenShift 4.4 was scheduled for general availability this week.

Posted by John K. Waters on May 7, 2020