Sep 21 2007 9:35AM GMT
Posted by: admin
Virtualization,
VMware,
Ubuntu Linux
Are you planning on juicing anytime soon? How about JeOSing?
Confused yet? Here’s a hint: Both those sentences sound exactly the same when you say them aloud. What’s different about them is a case of apples and oranges however, and I’m not talking about Tropicana. I’m not even talking about pro sports figures and questionable performance enhancing tactics that may or or may not lead to asterisks being placed next to stats and failed Hall of Fame bids.
What I’m not going to talk about today is the Cream or the Clear; what I am going to talk about is virtualization, virtual appliances, and a little Linux distro called Ubuntu. As of this month they’re all being blended into a concoction the folks at Canonical Ltd. and VMware are affectionately calling JeOS.
Each of those topics are pretty well known now (virtual appliances still being a bit “new car smell,” but whatever), so how does JeOS bring something new to the table? Is it a product to be sold, or is it an architecture with which to build new exiting things that my colleagues and I will be writing about for years to come? One executive I’ve read recently who’s been at this a while has a rough idea.
By taking a short Internet boat ride over to rPath CEO Billy Marshall’s blog today, we find him addressing that very question.
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.
[...]
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.
And off we go. By Marshall’s reasoning, and I’m inclined to believe him, the JeOS cannot be squeezed into an operating system product role because it must become a packaging or testing architecture. In lieu of any other approach, JeOS must be assembled by ISVs around an application with the smallest possible footprint. This is because, you’ll remember, VMware is promoting JeOS (and Virtual Appliances in general) as an opertaing system sans system interfaces, functions, and libraries; and without the unnecessary services that the application does not require. “By tailoring it to the needs of the application,” Krishnamurti said on his blog, “you are now down to a lithe, high performing, secure operating system - Just Enough of the Operating System, that is, or JeOS.”
But Marshall then argues that the appliance must also confirm that this “closed loop set” is reasonable based upon the testing scenario for the application. “It must subsequently enable the integration of the various maintenance streams for the components with the server set to provide an elegant life cycle 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,” he said.
Before you go scurrying behind a UPS unit in fear, just wait a second. Seems that you might have been living with this approach for some time already. Marshall, a former Red Hat employee, explains that “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.”
Add to that equation JeOS — as a packaging architecture (instead of a “one size fits all” product, Marshall says) — the component set that must be maintained is much smaller and much more intimately related to the application than even what VMware described at VMWorld for tHe launch of JeOS (due out October 12).
“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, Marshall said. “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.”
In conclusion (I sound like an 8th grade research paper here, but oh well), JeOS is, always has been, and will be a packaging architecture. Marshall states JeOS should be billed as a system software reference platform with 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,” he said.
What really fascinates me in all this is the role Linux will play in driving the adoption of VA’s by ISVs, who will then provide them to customers to run virtually in the tens of dozens on multi-core, super powerful servers that, in a hat tip to my colleagues at SearchDataCenter.com, are spaced correctly with adequate cooling. It’s a low cost, secure operating system and that seems to be working perfectly for vendors like rPath, VMware, Canonical and many more. We’re only on the cusp of this vast virtualization precipice, and as a writer I like that. But now I’m thirsty.
1 Comment
RSS Feed
Email a friend
