JeOS - its marketing not a new concept

The concept of JeOS is nothing new. The neat and effective buzz word JeOS (pronounced "juice") was coined by VMware product manager Srinivas Krishnamurti on his blog back on July 9th. The concept though is not new (sorry Billy), and we all know how badly things can go when marketing folks start promising features they've misunderstood.

Practically anyone who has created their own chroot environment, thats quite a few administrators over the years. Has already used the premise behind JeOS. Many enterprise grade devices such as layer 2-7 switches, content routers and hardware appliances have been using JeOS for years. JeOS is nothing new, and its not something that needs a hypervisor. JeOS is simple, its "Just Enough" operating system for what you are trying to do. OpenWRT is another example of a JeOS solution.

What JeOS is not is a packaging architecture. Package management does NOT belong on appliances, end of story. Don't believe me? Well lets think. What is mission critical and powers the Internet? Ah.. routers. Is there a yum update on Cisco IOS? Eh no. When you need to upgrade Cisco IOS, you download a new firmware image, and reload. Seems other vendors have taken this approach, and even the wireless lan products do this! Seeing a pattern? The self-contained image is guaranteed to work. Its tested for that specific hardware (or architecture) and it just works. When something is mission critical you can't afford to wait 5 minutes while it calculates dependencies, and then might have to roll back everything that it took 5 minutes to update in the first place because of an error. I'm not talking a flash / disk error either, what happens if you update a package and it corrupted at the source? Its got to roll everything back. This is why package management has no place on an enterprise grade appliance, its why trying to label JeOS as a packaging architecture is really silly.

So what is my take on next-generation server operating systems? Well the operating system should be an appliance delivery and management platform. It needs to provide the interface to the hardware (through drivers), access the management network (whether thats a separate physical network or just an SSL/IPSec VPN doesn't matter), exchange data with the centralized management system and then load the software appliances. Whether those are partitioned under a single kernel, or run as virtual software appliances is completely up to the user. In other words, virtualization should be a choice, not something force fed by some product marketing people.

The hypervisor is a feature, not a requirement. This is something very important to remember, because there really are applications out there where you need the full resources of the system available to you. There are bottlenecks which may not be acceptable, such as software switches and added latency of virtual interfaces. As well as the potential for packet leakage between virtual appliances. There are all potential problems.

Should JeOS be sold as a "one size fits all" of shared libraries and utilities? Quick answer to that is.. eh no. The JeOS solution needs to be minimal, very minimal. In fact it should be just enough to load the software (or virtual software) appliance. The libraries that the appliance uses such as libc, libxml2 and so on, should be part and parcel of the appliance itself. Could be part of a JeOS stack or as in AppOS -- Release Build Environment which provides basic libraries.

What happens if you are sharing libc and libxml2 between an Apache/PHP application and an Apache/Python application on the same server? Lets say the PHP application is compromised due to some unpatched PHP bug, this allows the malicious user to now manipulate libc, and thus effect the perfectly secure Apache/Python application! This is why sharing libraries between production applications is a very bad idea. It is why package management on an appliance is a very bad idea.

A better approach is to have each run its own dedicated copy of shared libraries. Sure this might waste a bit of disk space, but disk space is cheap, even more so with JeOS. This type of complete application partitioning is an important part of AppOS. The AppStacks for example, contain exactly what the application needs.

What I'm getting at here is that JeOS really comes in two pieces, there is the operating system side which provides the "just enough" part to load the appliance image, and manage it. Then you have the "just enough" libraries and utilities that are part and parcel of the software appliance itself. There is no kitchen sink situation for the libraries and utilities part. This is something the developer of the appliance needs to figure out, and provide as part of their solution.

The problem is there are companies out there who are trying to make a business out of dumbing down this development process. The development process should never be dumbed down, if someone who is providing a customer with an appliance cannot figure out that they need libxml2, libjpeg and openssl, and can't compile those from source. Do you really want to trust them with your business critical application? Remember any monkey can type [insert your favourite package manager] install openssl, but then you are relying on them to know that what that package provided is good and compiled properly. If they could do that, wouldn't they have just compiled it from source?

So JeOS is just that, Just Enough OS. Its a new marketing buzz word, not a new concept. If someone would like to dispute that, I'd like to point out that the very concept of JeOS (coined in July 2007) was part of my talk at Ohio LinuxFest 2006 (almost a year prior) on Open Source Zero Day Attack Protection. I just used the term minimal instead of just enough. Maybe I should have called it "Mince" ?

Tags: JeOS, virtual appliances, software appliances, ceos that code