Sydney to Stuttgart

So, here I am still on the road, starting to write this in Stuttgart airport, after spending a couple of days with the VirtualBox team. We've been introducing them to Sun, and doing a first pass on the roadmap ahead. The usual balance of lots of things we'd like to do, with software physics nipping at our heels - there's always more to do than we have people or time for!

Talking about VirtualBox in Australia was great fun; I introduced it to the audience of my keynote, which as I remarked in my earlier post was one of the largest audiences I've presented to. The full talk should eventually make it to the techdays site, but there are a couple of slides I wanted to review here now for people that can't get them and don't have time to navigate the site to find them. Basically, my talk was about Open Source Virtualization and Project Indiana, and how the two are connected. At first sight, one might imagine that they're not particularly connected at all. VirtualBox is an open source desktop hypervisor, a key component in our virtualization technology portfolio, but otherwise only related to OpenSolaris as a possible host and guest OS. VirtualBox is part of a more general application lifecycle picture involving xVM server and xVM Ops Center, as is nicely captured in this marketing graphic.


On the other hand, Project Indiana is, among other things, about bringing the technology of distribution to the OpenSolaris technology code base. This graphic from Ian Murdock's presentation at the Hyderbad techdays conference captures this notion of the OpenSolaris core surrounded by additional, up-to-date, packages from various open source communities nicely.


And this one summarizes the Indiana project goals:


So what is the connection between them? The connection is in the technology called the distro builder. This is the part the takes the recipe for a distribution that performs a particular set of functions and capabilities, and translates it into the right set of interdependent packages that can perform that function. At first sight, this seems a bit of a niche interest too. After all, relatively few people want to build OS distros .. surely? Well, it's more than you might think. In fact, if you take a look at many IT organizations, they tend to build something very similar for their internal use as a way of reducing costs. They rarely if ever take a vanilla OS install from a vendor. There's always some customization; packages added, removed, administrative pre-configuration of various kinds. So one important target for our distro builder technology are those IT organizations. Another important target are the developers creating virtual appliances to demonstrate their technologies. You can find these virtual appliances on lots of companies web sites these days - usually a file-based image that you can download and quickly instantiate on top of a hypervisor. The advantage being that you -don't- have to install and configure the software you're interested in exploring directly on your desktop operating system - you run it inside a preconfigured OS as a virtual machine. Then when you tire of the demo, you can discard it quickly, and completely, by discarding the virtual machine. So here's the graphic I kludged up to represent how the Indiana project and VirtualBox fit into that picture.


On the left side is the distro builder, on the right side is the developer to deployer flow using VirtualBox on the desktop, and xVM Server and xVM OpsCenter in the data center. If you want to find out more about the IPS packaging system that underpins this picture, then I'd recommend starting on Stephen Hahn's blog.

An open question we've pondered for a while is when virtual appliances will move beyond internal-use and demo-ware to be a mainstream style of SW distribution. There are several vendors who would like this to be true sooner than later. But the question is open for several reasons, performance is a universal concern, licensing of well-known proprietary operating systems in this context is another issue. Another important barrier is how to resolve the support issues for all the software involved that the creator of the application, or facility being demonstrated, didn't write. Let's think about a more concrete example. Assume I'm a developer at a small company, and I create a compelling application that uses various application infrastructure components e.g. an application server, a database, and, e.g. a chunk of ruby-on-rails to do it's work. Then I install and configure it all on an OS image of my choosing, make it into a virtual appliance, then deliver it to my customers that way. That packaging and configuration work I did is a clear advantage to my customer in terms of getting started with the application and exploring the value of the offering - which is one of the reasons vendors are using it more and more for demoware. But having delivered a complete package that way, it seems like as well as being responsible for the defects in my application, I'm now -also- responsible for all the defects in the customized stack I created too. Do I now have to start worrying about all the security patches I might need to include in my virtual appliance? Eeek! That seem really hard. We probably need a better answer to that support question that involves the vendors of the components I used before delivering fully-customized yet fully supported software stacks as virtual appliances really takes off.

Technorati Tag: OpenSolaris
Technorati Tag: VirtualBox


Post a Comment:
Comments are closed for this entry.



« July 2016