JeOS - Product or Architecture?

JeOS (pronounced “juice”) is a concept first described in writing by Srinivas Krishnamurti of VMware in this blog entry. With the pronouncement this week by Canonical that the Ubuntu distribution of Linux is now a JeOS product, I thought I would make the argument that JeOS is a packaging architecture, not an operating system product. I also believe that the hypervisor is the replacement for the product formerly labeled as the general purpose operating system.

Historically, and general purpose operating system served 2 important roles:

1) provide drivers that abstract the hardware and make the hardware resources and network available to the software applications, and

2) provide system services (file system, program libraries) to the applications such that they can execute their code in a predictable and efficient manner.

The 1st role above is now being relinquished to the hypervisor. Srinivas argues that the second role should be accomplished using JeOS. However, the actual configuration and components of JeOS, by definition, should vary considerably from application to application as each application needs different resources to operate efficiently. So, can JeOS be a product category sold in the same manner that general purpose operating systems were historically sold? As a “one size fits all” collection of general purpose utilities and libraries? Well, let's examine how the general purpose operating system is sold and determine if the same approach can be applied to the new JeOS category.

As background, I ran product marketing at Red Hat from early 1999 until midyear 2000, and I was the first enterprise sales leader for Red Hat. I was Vice President of North America sales for Red Hat from April 2001 until January 2005. During that time, we were very successful in growing sales of Red Hat Enterprise Linux by mimicking the Microsoft server OS product approach. Red Hat provided a stable release of operating system technology with a very broad set of utilities and libraries included. This release was accompanied by a commitment to five years (now seven, I think) of maintenance and regular updates for new hardware drivers, bug fixes, and security fixes.

It was also accompanied by a restriction that released Red Hat from its support obligation if the customer made any changes to the components that defined the operating system. Without this restriction, Red Hat could not possibly afford the engineering and customer service expense associated with supporting every customer's preference for utilities, program libraries, and system services. Further, the operating system itself required so many components to support so many components to support so many more components that changing any one of them often left the operating system in an unstable and unmaintainable state. This problem is often referred to by system administrators as “dependency hell.” But, since the operating system was often distributed by the hardware server providers as the mechanism to attach an application to the hardware, it was unavoidable that this restrictive model be strictly enforced to enable the industry to get on with shipping hardware that could be used by applications.

The restriction did not prevent customers from making changes to the operating system and subsequently seeking support from Red Hat. They simply absorbed the risk and much of the costs associated with the changes. If Red Hat turned them away because their changes did not conform to Red Hat's definition of the operating system, they soldiered on and did their best to make the operating system work for their applications. It never really occurred to them or to Red Hat that it might be a good idea to change the underlying packaging technology of the operating system to make it easy for the customer to change the things that did not work for them. Such a solution was unthinkable because it would leave the server hardware vendors with an undefined bill of materials. The server business is a high volume business that requires some level of standardization among the components to achieve price competitiveness through economies of scale. Changing the operating system for every server depending on the application workload it is intended to serve does not make any economic sense.

Now that the hypervisor is going to become the new operating system that supports the hardware, should the JeOS that supports any given application be a product with the same architecture as the legacy general purpose operating system? i.e. a collection of components defined by the operating system vendor as supportable and maintainable? so long as you don't change the assumptions the operating system vendor made when the collection was assembled and tested and released? so long as you don't change any of the components because that makes the collection unsupportable? How is that possible, when by definition, the collection of components that the application vendor is going to use is going to change depending on the needs of the application? Think about it.

JeOS cannot be an operating system product. JeOS must be a packaging architecture (and perhaps a testing architecture as well). JeOS must answer the question “What does the application need?” based upon the application it is presented. JeOS must then assemble around the application the components that represent the smallest possible closed loop set of components to host the application. It must then confirm that this “set” is reasonable based upon the testing scenario for the application (hence my comment above about a testing architecture). It must subsequently enable the integration of the various maintenance streams for the components with the server set to provide an elegant lifecycle experience for the application vendor and its customers. In this scenario, the application provider takes on a much broader responsibility for the support of the operating system, and at the surface level this can seem very scary.

On further inspection, however, the application vendor or their customer was already assuming this burden in the legacy model where the general purpose OS was modified on premise to support the application. With a fight through dependency hell followed by an ongoing war with the maintenance stream from the OS vendor (which was often ignored because it could not be reconciled with the needs of the application). With JeOS as a packaging architecture (instead of a “one size fits all” product), the component set that must be maintained is much smaller and much more intimately related to the application. By definition, the application vendor will be in a good position to determine and resolve problems given this tight definition and technical affinity with the application. No doubt they will still want the technical expertise of a vendor with deep operating system skills as a backstop, but the product they acquire from that vendor will look very different than the product historically labeled as a general purpose operating system. It will be a packaging architecture with a system software reference platform and a build/test methodology. Anything else defies logic in a world where every server has a hypervisor and every application arrives as a virtual appliance with JeOS.