Where there were once a slew of vendors meticulously testing and porting applications to every operating system...
By submitting your email address, you agree to receive emails regarding relevant topic offers from TechTarget and its partners. You can withdraw your consent at any time. Contact TechTarget at 275 Grove Street, Newton, MA.
imaginable, Marshall one day sees a applications delivered in neatly packaged virtual appliances that run on top of a virtualization layer. The OS inside will be a stripped down version of Linux, and the applications will be hardware agnostic.
But is this version of the future for everyone? Where does it not work as Marshall and other vendors like VMware, Red Hat and others have promised it would?
Marshall recently sat down with SearchOpenSource.com to address these concerns and explain the growing trend of virtual appliances and the role of the OS in tomorrow's enterprise.
SearchOpenSource.com: What's driving interest in virtual appliances today?
Billy Marshall: Control of the applications should be in hands of application provider. They are the ones who intimately understand how to tune and deliver the application. The end user should be providing the infrastructure on which the application lands and operates. We don't believe in the current model, where what the customer has been doing is like gluing Lincoln Logs together. This takes lots of time and expertise and the reason it evolved that way is because historically customers needed to have some level of choice or expertise with the hardware. The application vendor would issue ports of the application for Solaris, but they would also have to do that with HP UX, AIX, and so on. The OS and hardware were tightly coupled.
Vendors have been trying to put everything they can imagine into the OS with the understanding that every application a customer might introduce would need to perform a specific function. This leads to conflicts among applications. It was [Dynamic Link Library] hell when a vendor tried to deliver something into the OS and needed to make sure it was fine-tuned to their needs. In the future however, with a virtual layer on the hardware, the IT staff takes care of all that.
Are there applications that don't work well as virtual appliances?
Marshall: This can't be case for high performance applications. A great example is agami Systems, an NAS systems provider based in Silicon Valley. They deliver a high performance network storage application, and that's not something you'd virtualize.
Do you have any other examples?
Marshall: Virtual appliances wouldn't be the case in environments where 2% performance changes really matter. It would also not apply to certain special network functions, and an IT manager may or may not virtualize something like a firewall. But for things like ERP and other business utilities, a virtual appliance makes terrific sense because you are able to decouple all that from the hardware platform.
What benefit do your customers get from virtual appliances?
Marshall: One of our customers, Zimbra, entered the VMware Virtual Appliance challenge by installing their application atop a minimal CENTOS server install. Because they use lots of unique open source components that are also used in CENTOS, there are a number of duplicate packages.
Also, because CENTOS is a general purpose operating system, essentially a re-build of Red Hat Enterprise Linux, it has lots of extra packages that the Zimbra application does not require. When Zimbra snapshotted the image to create their VMware VMDK file, it was about 1.8 Gigs. When they repeated the process using our application focused approach, the same functionality was delivered in a 200 meg VMDK file. With the rPath approach, there is roughly 1.6 gigs of software that Zimbra does not have to maintain as part of their virtual appliance.
Why does that matter to IT managers? Is it just a matter of saving 20 minutes of configuration time?
Marshall: The way rPath works is we provide a platform that enables the vendor to determine what components work best for them. Not as whole new virtual images, but as incremental packages. If you update Linux component, for example, you then ship the package to the ISVs and they would test it relative to their values. After testing they can then pass the package on to the customer. This way everything has already been tested in the exact same environment the customer has deployed it in. There's never going to be any blow up with maintenance.
Contrast that with today when Red Hat releases its OS code to the customer -- or any vendor for that matter. They have already attempted to test it with every software vendor's application in the world. One hundred percent is just not possible. After Red Hat tests and releases the software, a customer then has to set up the environment, have developers do QA, and then test it all in a production environment. And so the customer goes through the trouble of figuring out how their preferred OS works with their preferred applications stack.
Are virtual appliances the future of OS distribution?
Marshall: We believe future of OS is a split. On one side is the hypervisor OS and drivers and management. Each application will be delivered to the platform with a tailor made OS inside a virtual container. On the other will be the traditional OS model.
Why has Linux emerged as a favorite OS in virtual appliances?
Marshall: The biggest reason is because Linux is free, and therefore free to redistribute. When we are dealing with a customer using rBuilder and our appliance software and Linux is included, we can't place some court order preventing them from shipping their software. Their rights with Linux are equivalent to our rights.
What's the end game in all this? Where do you see the market in a year or more?
Marshall: I see a string of software companies trying to reach the midmarket. Users today just will not continue to tolerate the complexities they've had to deal with to this point. In the long term the enterprises will begin to separate computing infrastructure from their development infrastructure. A great early view of this is Amazon's EC2 [Elastic Compute Cloud] service. [Editor's Note: Users of the EC2 can create Linux-based virtual machines and then deploy them on a 1.7Ghz Xeon CPU with 1.75GB of RAM, 160GB of local disk, and 250Mb/s of network bandwidth.] You do not need to know anything about Amazon to run on [the EC2], you just submit a Xen image to Amazon and then they run it for me.