Red Hat oVirt(ly) targets VMware and Citrix

Red Hat announced last week that they are developing technology that will one day become a product to challenge the offerings from VMware and Citrix. The technology is showcased at a website sponsored and maintained by Red Hat as part of an “emerging technology” initiative. Aside from the fact that Red Hat is announcing technology projects and not products, the most noteworthy detail of this approach is the emergence of KVM (kernel-based virtual machine) as the hypervisor approach that Red Hat intends to back. Taking a page from the Microsoft HyperV playbook, Red Hat is claiming virtualization as a “feature” of the OS they already control in order to maintain their investment in the server distribution channel they have established with OEMs such as Dell, HP, IBM, Fujitsu, and others. Bare metal hypervisors and their associated infrastructure management frameworks are threatening the entrenched status quo of the operating system vendors, and Red Hat does not intend to “go gentle into that good night.”

Historically, a general purpose operating system performed two key functions: 1) provide drivers so that applications can access the hardware, and 2) provide system services (file system, libraries, etc.) to the applications. The trouble with this approach is that applications become artificially coupled to the hardware. Have you ever experienced pain upgrading hardware when the application that ran just fine on the old hardware no longer runs on the new hardware because of changes in the operating system? Do you find that you are continuously porting and testing applications just to upgrade hardware? Why? Because a one-size-fits-all general purpose operating system (OSFAGPOS) couples hardware support with application support due to the architecture of the product. Aside from the application portability issues, the OSFAGPOS approach also leads to the enormous management cost associated with bloating. Most applications run atop an operating system in the datacenter that is 10X the size actually required by the application, which leads to a patching nightmare.

To be fair to Red Hat, KVM could certainly be implemented and maintained by them as a skinny bare-metal hypervisor that only concerns itself with managing the hardware infrastructure. The Linux kernel is a fine provider of hardware support, and Red Hat has more Linux kernel expertise than any other vendor in the world. Their technical credibility in this space is terrific. The trick will be the marketing challenge of offering a product that has a very different value proposition than the OSFAGPOS. The goal of a bare-metal hypervisor is to support as many application OS variants as possible in order to enable application providers to choose the system software that works best for their application. This flexibility for the application flies in the face of the OSFAGPOS argument to “standardize” the OS to gain economies of scale in management and support. With OSFAGPOS, at least you know what systems need to be patched – all of them . . . all the time. Embracing a bare-metal product approach would mean that Red Hat also needs to face up to OSFAGPOS management challenges and embrace virtual appliance value for applications that run with Just enough OS (JeOS or "juice") optimized for their workload.

I believe that the separation of the duties of the historic OSFAGPOS architecture into two separate product domains - hypervisors for drivers and JeOS for application support - is inevitable. Separating hardware support from application support simply provides too many benefits. The popularity of both VMware and Amazon's emerging EC2 service are great examples. Watching both Red Hat and Microsoft navigate this change will be interesting. The marketing gurus at both companies will be strained to the breaking point as they “rage, rage, against the dying of the light.”