Here is a story from Slashdot.org:
Virtual Containerization
AlexGr alerts us to a piece by Jeff Gould up on Interop News. Quoting: “It’s becoming increasingly clear that the most important use of virtualization is not to consolidate hardware boxes but to protect applications from the vagaries of the operating environments they run on. It’s all about ‘containerization,’ to employ a really ugly but useful word. Until fairly recently this was anything but the consensus view. On the contrary, the idea that virtualization is mostly about consolidation has been conventional wisdom ever since IDC started touting VMware’s roaring success as one of the reasons behind last year’s slowdown in server hardware sales.”
Here is the full story from Interopt News
It’s becoming increasingly clear that the most important use of virtualization is not to consolidate hardware boxes but to protect applications from the vagaries of the operating environments they run on. It’s all about “containerization,” to employ a really ugly but useful word.
Until fairly recently this was anything but the consensus view. On the contrary, the idea that virtualization is mostly about consolidation has been conventional wisdom ever since IDC started touting VMware’s roaring success as one of the reasons behind last year’s slowdown in server hardware sales. After all, if a copy of VMware ESX lets you replace four or five boxes with just one, some hapless hardware vendor has got to be left holding the bag, right? Ever since this virtualization-kills-the-hardware-star meme got started, Wall Street has been in something of a funk about server hardware stocks.
But if the meme is really true, why did Intel just invest $218.5 million in VMware? Does Craig Barrett have a death wish? Or maybe he knows something IDC doesn’t? There has got to be a little head scratching going on over in Framingham just now.
The obvious explanation for Barrett’s investment (which will net Intel a measly 2.5% of VMware’s shares after the forthcoming IPO) is that Intel believes virtualization will cause people to buy more, not less, hardware. This thesis was forcefully articulated on the day of the Intel announcement by the CEO of software startup rPath, Billy Marshall, in a clever blog post that also – naturally – makes the case for his own product. I had a chat with Marshall a few days ago and found what he had to say quite interesting.
Simply put, Marshall’s thesis is that “sales of computers, especially server computers, are currently constrained by the complexity of software.” Anything that makes that complexity go down will make hardware sales (and, one presumes, operating systems sales) go up. Right now it’s so blinking hard to install applications, operating systems and their middleware stacks that once people get an installation up and running they don’t want to touch it again for love or money. But if you install your app stack on a virtual machine – VMware, Xen, or Microsoft – then you can save the result as simple image file. After that, you’re free to do whatever you want with it. You can archive the image on your SAN and deploy it as needed. You can let people download it from your web site. Or you can put it on a CD and mail it to your branch office in Timbuktu or Oshkosh. Anyone will be able to take this collection of bits and install it on the appropriate virtual machine in their own local environment without having to undergo the usual hell of installation and configuration.
This idea of using virtual machine images as a distribution mechanism for fully integrated application stacks is not new. VMware has a Virtual Appliance Marketplace with hundreds of apps available for download. You won’t find Oracle 10g or BEA WebLogic or MySAP here, at least not yet. But you will find plenty of stuff from open source projects and smaller commercial ISVs (independent software vendors). Microsoft also has a download page for pre-configured VDH images of most of its major pieces of server software, including SQL Server 2005 and Exchange Server 2007.
So what does rPath add to the mix? Although Marshall has cleverly hitched his pitch to the virtualization bandwagon, he is actually in a somewhat different business, namely that of providing a roll-your-own-Linux toolkit and update service for ISVs. Marshall likes to recount the following anecdote to explain his value-add. When open source e-mail vendor Zimbra wanted to package its software in VMware disk image format using RHEL clone Centos as the OS, the install snapshot produced a monstrous 2 gigabyte file. You could fit that on a DVD, but this is clearly not in CD territory anymore, and maybe not so convenient to download over a garden variety DSL connection either. The problem is that a fully populated OS drags along huge excess code baggage that a typical application just doesn’t need. In the case of Zimbra, the excess added up to many hundreds of megabytes.
rPath’s solution is to use its own stripped-down and customized Linux distribution. It provides its own collection of Linux kernel and user space components along with a tool called rBuilder for deciding exactly which pieces are necessary to run a particular application. This is not a totally automated process – ISVs will have to roll up their sleeves and make some choices. But when the process is complete, rBuilder will generate a finished image file containing a fully integrated OS-middleware-application stack. This is what rPath calls a software appliance. The appliance can be packaged for any of the major target virtual machines, or for an actual install on raw Intel-based hardware. When Zimbra applied rBuilder to its application stack, swapping out Centos for a custom build of rPath Linux, the resulting VMware image shrank to only 350 megabytes.
In addition to eliminating installation and configuration hell for end users, rPath gives ISVs a platform similar to Red Hat Network for managing the distribution of application updates and OS patches. If rPath releases an OS patch for its version of Linux that the ISV determines is not needed by the ISV’s customers, then the patch doesn’t get distributed to them. This two-stage model is a lot more sensible than the Red Hat system of distributing all patches to everyone and then letting users discover for themselves whether a particular OS patch breaks their application.
rPath was launched at LinuxWorld last year and has already gone through a couple of version updates. Marshall didn’t come up with the vision for his company out of thin air. It’s based in large part on the insight he gained during a multi-year stint in the belly of the beast at Red Hat. In fact, a lot of his team are ex-Red Hatters. Marshall himself put in a couple of years as VP of Sales, and before that he was the guiding light behind the launch of the Red Hat Network provisioning and management platform. His CTO Erik Troan developed the Red Hat Package Manager (RPM) tool at the heart of RHEL and Fedora. Another rPath engineer, Matthew Wilson, wrote Red Hat’s Anaconda installation tool.
These people obviously know a thing or two when it comes to building and maintaining a Linux distribution. Their product concept is ingenious. The question is whether it’s big enough to make a stand-alone company. Right now it’s too early to tell.
There are a couple of real drawbacks to rPath from the end user’s point of view. One is that only Linux stacks are supported. If you are running a Microsoft stack, you’re out of luck. To be fair, you can run your rPath stack on top of Microsoft Virtual Server, and no doubt on the future Viridian hypervisor too. But if you were using just the unadorned VMware image format as your container rather than rPath you could run pretty much any OS stack you pleased.
Another drawback is that even in a pure Linux context, an rPath software appliance can’t use a particular piece of commercial software unless the ISV is an rPath customer. rPath’s basic business model is to sell tools and platforms to ISVs. The rPath appliances available now are mostly pure open source stacks, some commercial and some community. But there is no Oracle database or BEA or IBM middleware, which is a pretty big limitation in the real world of corporate data centers. Marshall does say he is involved in “deep discussions” with BEA, so maybe there will be some movement on this front at some point in the future. But for now it’s wait and see.
What it all boils down to is how credible the rPath Linux distribution can be in the eyes of the ISVs who consider using it. rPath politely avoids using the word “port,” but that is really what an ISV has to do to get its application running on rPath. An ISV that can afford to drop the other platforms it supports and serve its products up only on rPath will reap the full benefits of the system. But big commercial ISVs with big legacy installed bases won’t be able to take such a radical step. Marshall’s spin on this delicate issue seems to be that enterprise ISVs should leverage the end user ease-of-installation benefits of its platform to expand into Small and Medium Business markets where tolerance for complexity is much lower. Of course one could take this argument a step further – which the company for the moment is not willing to do – and say that rPath’s natural home is in the embedded market, just like Debian founder Ian Murdock’s now defunct Progeny (don’t worry about Ian, he landed at Sun).
At the end of the day, I have to wonder whether rPath wouldn’t make itself a lot more credible in the eyes of its ISV target customers by becoming part of a larger software organization. Red Hat obviously comes to mind as a possible home, assuming Red Hat management could swallow its pride enough to buy back the innovation of its ex-employees. But another possibility would be… Oracle. After all, if Larry really wants to get RHEL out of his stack, what better way to do it than to add an entirely free and unencumbered RHEL-like distro to the bottom of every Oracle stack?
Be all that as it may, there is one thing about the rPath concept that really, really intrigues me. What is to prevent Microsoft from trying this? If ISVs had a convenient way to package up highly efficient custom builds of Windows Server 2008 together with key Microsoft or third party applications for the Viridian hypervisor, the idea would be wildly popular. Will it happen? Let’s wait and see what happens after WS 2008 comes out.
Copyright © 2007, Peerstone Research Inc. All rights reserved.
That is all for today and this Came out at 12:10 PM PST