Red Hat SummitRed Hat Blog
The launch of Red Hat Enterprise Linux 8 (RHEL 8) at Red Hat Summit 2019 was a jubilant event. Not only for the many team members around the world who worked to make the next-generation of the world’s leading enterprise Linux platform a reality, but also for customers who are excited to utilize its new capabilities in driving business innovation.
This is a great time to reflect on what is so special about RHEL 8 by taking a walk through time on the evolution of RHEL. The RHELvolution, if you will. I'll be your guide on this journey, having been at the helm for RHEL engineering since the beginning (2001), starting with Red Hat Enterprise Linux 2.1. And yes, we'll explain why it started with 2.1.
It has been thrilling to be part of the RHEL team all these years. Having worked on proprietary UNIX operating systems before being at Red Hat, constructing RHEL offered a first hand view of the power of open source. Through collaboration with customers, community and a highly motivated team, we have had a global impact on the IT landscape. Evolving from “lighting up the box” to dynamic infrastructure that helps to advance the state of the art while liberating customers from vendor lock-in (originally at the hardware level, later expanded to hybrid cloud).
Let’s look at the themes of the RHEL releases to see what made each release so special and the mark it makes on RHELvolution. Of course it’s not possible in a few paragraphs to give a comprehensive overview of each release. Instead, I’ll distill the overall theme for each.
Red Hat Linux
The early days of Linux, running the platform as an enterprise operating system was like an egg hunt. You had to search vendor sites to find drivers and other components.
Since these pieces were built separately, the parts often didn’t work together. This could (and frequently did) result in a lot of “forking” of drivers, where each OEM tried to optimize pieces for their respective platform. Deploying Linux was inherently a hand-crafted and difficult endeavor, while open source was unproven in enterprise environments and viewed with some suspicion.
Despite that, Red Hat Linux found its way into a number of organizations, and we learned a lot about what customers were looking for and came up with a plan to meet their needs with RHEL.
RHEL 2.1: Lighting up the hardware
The first Red Hat Enterprise Release was based on Red Hat Linux 7.2, and GA'ed on March 23, 2002.
Our initial focus was coordinating with hardware vendors on getting all the kernel, compiler, installer and driver support in place to more reliably run Linux on a wide diversity of hardware.
By building all the parts in one place and co-testing with the hardware vendors, the dependability of Linux in enterprise roles greatly increased. This stable platform allowed software application vendors a consistent development environment. We also adopted a lengthy lifecycle (initially four years, which later expanded), which provided customers with curated bugfixes.
It looks so simple in retrospect, but it was a real challenge to resist vendors' requests for tailored versions of RHEL for their hardware. This proved beneficial to customers as the beginning of a standardized RHEL ecosystem helped to liberate enterprises from vendor lock in.
The rumor is true
And yes, I can confirm the speculation that we started with the release number 2.1 because it sounds a lot more mature than 1.0. A "one dot oh" release was viewed with great suspicion, so we chose a version number that reflected our opinion about its readiness and stability.
You might note that there was not a RHEL 2.2, 2.3, and so forth. From RHEL 2.1 through RHEL 4, we kept the same version and issued updates such as "RHEL 2.1 Update 1." The current numbering scheme started with RHEL 5.
RHEL 3: Performance and enterprise workloads (2003)
The initial inroads of Linux were often in small specialized tasks like file and print servers, as well as desktop workstations. At this time, Intel CPUs were becoming serious competition to the custom chips powering proprietary UNIX offerings. Yes, there was a time when Intel chips were just making inroads into enterprise environments.
It wasn’t sufficient just to boot the box, Linux was entering a performance and scalability battle, and the “killer app” was the Oracle database. We worked closely with the community, Oracle, Intel, HP and IBM on high performance workloads running on large memory and CPU systems. We also expanded RHEL beyond x86 into additional architectures like IBM's zSeries mainframes and AMD's new x86-64 Opteron line.
The result of this work was that RHEL began setting new world records in TPC database performance, helping to propel RHEL’s role in the datacenter from “small boxes in the corner” to “enterprise workloads.” This really started to shake up the entrenched position of proprietary Unix on proprietary hardware. The beginning of the end of the “Unix wars” later supplanted by the collaborative power of the open source community on increasingly more powerful Intel commodity CPUs.
RHEL 4: Focus on security (2005)
By the dawn of RHEL 4, the early adopters had proven the viability of commodity hardware running enterprise workloads on open source software. Other customers took notice of these economies of scale and the growing innovation in Linux, and this wave of customers brought in a new set of requirements to operate in the broadening internet namescape—principally security. To address security needs, Red Hat engineers worked closely with the community, government agencies and financial corporations in creating SELinux security containment and access controls.
Implementing SELinux was a huge integration challenge, as it required code changes in literally hundreds of components, and its success can be directly attributed to the Red Hat developers who were major contributors in all of these components. It was a bumpy journey over several releases to bring SELinux to more widespread adoption.
For many years customers joked that the first thing they did was to disable SELinux security. Today our conversations and collaborations with our most security conscious customers indicates that they leave SELinux protections enabled. Four years later in RHEL 8, the vision of built in defense in depth in security across the entire stack to build and run applications has been realized.
It was a major challenge to integrate all of the security features into the mainstream RHEL release. Previously, it was common practice among Unix vendors to develop a separate secure version. The problem with that approach is it fractures the ecosystem—requiring application developers to build two versions. Additionally, the secure versions would constantly lag behind and be feature deficient. In the end, our security work on RHEL has allowed us to meet stringent government and commercial security standards (such as Common Criteria and FIPS 140-2).
RHEL 5: Virtualization (2007)
In 2007, computers were becoming increasingly larger and workload consolidation, primarily via virtualization, was frequently required for efficient utilization. Previously, virtualization was only available through proprietary vendors at high price points. The initial implementation of virtualization in Red Hat Enterprise Linux was called Xen, which was later replaced by Linux's Kernel-based Virtual Machine (KVM).
Driven by Red Hat (and many others), KVM evolved to implement virtual machines as processes. This simple and elegant design allowed for the reuse of many pre-existing Linux components, sparking greater evolution in the virtualization space. This pushed Linux and open source once again into world record performance and scale benchmarks, demonstrating the power of open source and RHEL in driving leading innovation.
What was unique to RHEL (in addition to benchmark leadership), was building on the SELinux security capabilities resulting in strong VM guest isolation as is required for workload certification. This combination of features (security + virtualization) in a single product demonstrates the building block power of Linux.
For example, the ongoing scalability enhancements in utilizing large CPU and memory systems was immediately leveraged in the virtualization implementation. This enabled customers to more easily achieve better utilization of their equipment by running their existing workloads in virtualized guests.
While on the topic of virtualization, we not only supported RHEL guests, we later supported Microsoft Windows guests. Who would have thought that former bitter rivals would be working together? Windows guest support was the beginning of an increasingly close relationship between Red Hat and Microsoft that continues in RHEL 8 in the form of Azure optimizations (among other things).
I hope you have enjoyed this walk through the early days of RHEL. It was an exciting time where we felt like an underdog, competing against the proprietary world of the established Unix giants.
The combination of the power of open source collaboration and the commoditization of hardware was beginning to foster larger scale customer adoption. The world of RHEL powering conventional on premise hardware and virtualization was becoming well established. Little did we know at the time that the computing world was about to be disrupted by the cloud vendors. Please join us in the second half of this RHELvolution series where we see how RHEL evolved in the cloud landscape.
