In a breakout session titled “Moving Red Hat Enterprise Linux into a New World” at the 2016 Red Hat Summit, Gunnar Hellekson, product director for the company, talked about how Red Hat Enterprise Linux (RHEL) needs to evolve in an ever-changing world with new and diverse demands. He outlined the current challenges that RHEL faces and proposed solutions.

“The world is significantly different now than in 2002 (when RHEL was first released),” said Hellekson. “RHEL is getting in the way more often than it’s helping now, so we are all here to participate and talk about ways RHEL can make life easier.”

Current challenges with RHEL

The release cadence is a challenge for hardware vendors. It’s slow and customers want to enable hardware before the next minor release. Customers don’t always know what’s certified or when–certified hardware is a DOD requirement. The hardware market is changing and moving faster, but not all companies are necessarily going through the full cycle. “And the joke’s on us. Cloud customers don’t want to care about any of this,” Hellekson said.

For software vendors, it’s not obvious which dependencies will change and when. There is a huge demand for ever-more packages to satisfy application dependencies. Independent software vendors (ISVs) will hug minor releases, like when apps will only run on one version, which slows updates. Red Hat seeks to make it easier for ISVs to stabilize across versions. Customers will also hug minor releases from fear something will break if they upgrade.

Subscription management is difficult as well, and operating systems and apps have to be updated together, which creates more work and risk. Large installs make security and maintenance a nightmare, and it’s often difficult to understand what works with what. Lots of people do full RHEL installs just in case there’s something they need, then take out unneeded items piece by piece, which can be like playing Jenga with enterprise IT.

Solutions for the next 15 years, and beyond

Hellekson said the following three items are “must haves” for RHEL in the future:

More available software, less software installed

RHEL is now a source of trusted installations, dependencies, and libraries, among other things. Customers want Red Hat to take care of this via a curated software library so they don’t have to. This makes the Red Hat subscription model more valuable. The goal is to preserve the hardware/software ecosystem and expand the platform to attract new developers and support new infrastructure.

Paradoxically, many system administrators want less software on the install disc–just the kernel and glibc, for instance. This will reduce dependencies and make minimization choices easy and obvious.

Less disruptive updates

“We have to be specific about how the operating system and APIs interact so apps don’t get disrupted,” said Hellekson. He also said the company needs to simplify cadence, software licensing agreements, and lifecycle rules.

“For instance,” he said, “if you didn’t know anything about the Red Hat subscription model and I said you needed to get extended update support, you wouldn’t know anything about that.” Other solutions included stabilizing the platform to ease the introduction of new environments and versions, and decoupling the hardware enablement so it’s not disruptive.

More automation

“Hand-crafting kickstarts is outdated,” Hellekson said. “Once you get past 20 machines you bring in other solutions like Red Hat Satellite. There’s not much opportunity now for RHEL to be managed by robots such as Chef, Puppet, Ansible, etc. We want to automate RHEL focusing on robot users, not just humans.”

One focus would be on efficiency. This would be operator deployed, using technologies such as Java, C++ and .NET. This focus is based on supporting applications and hardware (aligned with hardware vendors) for their entire lifecycle and depends on a secure, stable API and toolchain.

Another focus could be on agility. This focus would be developer-deployed and “inspired by the teetering tower of abstractions such as containers and cloud.” This represents the renegotiation of responsibility for the OS and the OS software. This utilizes technologies such as Java, Node Javascript, Ruby, and Python. It’s based upon a fast cycle time with easy-to-use tools and the latest secure content in a constant build, integration, and deployment environment.

The challenge for RHEL is to serve both sets of needs–efficiency and agility, across standardized, virtualized infrastructure-as-a-service (IAAS) and cloud solutions.

Q&A from the session

These are some of the questions audience members asked Hellekson about the changes:

How do people and organizations need to change for this shift?

“We need to start the conversation with customers and partners on the software and hardware side. It has to do with culture and how people are using RHEL today. We are doing early interviews with customers and partners so we can plan accordingly.”

Will this change impact the software lifecycle process or how often updates are provided to customers?

“We will continue to provide minor releases to get necessary updates into people’s hands.”

If I file an update for a (software) feature today, it takes 18-24 months to appear in the OS. What is Red Hat doing to address this for the core OS? How can you reduce the time to market?

“Part of this involves hardware optimized for a two year cycle. One of the measurements I put in place to measure progress is to measure cycle time–e.g. ‘how does a bill become a law’–so we will be holding people accountable to get these releases out faster. It’s not sufficient for it to take this long as it may have been 14 years ago.”

The company is also conducting a survey for RHEL users, which anyone can take by clicking here.

Also See
Red Hat goes all in on OpenShift and containers at Red Hat Summit 2016
Red Hat’s open source success story built on killing complexity in IT
Red Hat becomes first $2b open-source company
Google teams with Red Hat to bring containers to the cloud