No really, It's not a toaster... or a coffee maker
So what is a virtual appliance? A virtual appliance is a virtual machine that can be distributed (like any file) and deployed onto some hypervisor (a server that runs virtual machines). Because a virtual appliance is an entire virtual machine, the appliance developer has control of the entire aspect of the machine, from operating system to window themes to startup procedures. ***Not only could one use some custom operating system, one could perform more interesting OS integration without worrying about "cross-platform compatability". Imagine buying a server that could initally be running a VM with your DNS and Email, and then repurpose it to dedicated indexing/search web interface.
A few other interesting things to note about virtual appliances involve web hosting and choice of operating systems. It is now feasible for a web host to simply provide some hypervisor (virtual server) and give you a virtual machine on this server. You can then customize the machine however you want (under the resource restrictions the hosting service provides). The host can control how much CPU/RAM/Network they allocate to your machine and enforce it in the hypervisor. You can control almost every other aspect of your machine. I know a lot of web hosting services have already started adopting this model.
Another intersting thing you do on a virtual appliance is install any kind of (or no) operating system. Many Linux distributions are starting to offer "virtualization optimized" packages (e.g. Ubuntu's JeOS, rPath's JeOS and Red Hat's (not released) Appliance Operating System [AOS]). [JeOS => Just Enough Operating System, a term coined (AFAIK) by VMWare). These JeOS products could greatly improve performance of your virtual appliance. I predict that in the future we'll see more custom distributions, kernels or entire operating system stacks.
The Early Brew
In the 90's MIT was doing research into something they called the "Exokernel". The idea behind an exokernel was one step beyond micro-kernels: The kernel should only multiplex resources on a machine. The idea was neat, and they experimented with a webserver they called "Cheetah". Cheetah implemented its own memory management to reduce the os-abstraction-overhead of server static content. Cheetah was able to gain an order-of-magnitude in performance by marking and passing memory loaded with file contents directly to the NIC without having to be copied to and from user-space. The exo kernel failed in other areas, mainly in that it tried to multiplex host resources *separately* for all "processes". I remember watching the ExOS library (a POSIX-as-a-shared-library implementation) fly together, but the file system really started caused some trouble. It was hard to share a disk across operating systems without imposing some kind of filesystem on them all.
Virtualization is very similar to the ExOS idea. It multiplexes physical resources across many virtual machines. The big difference here is in the fundamental unit of execution: For ExOS it was still a Process, however for the Hypervisor it's a "Machine". This difference in fundamental unit is what has made virtualization so popular, however it doesn't mean we have to give up some of the things we've learned from the exokernel. We can still implement an OS that is highly tuned for some specific purpose (almost like an embedded device). However, instead of compiling for a particular architecture, we compile to the x86-virtualized-architecture. We can back our order-of-magnitude performance gain for hosting static content. The question remains, what is the cost of the extra-layer of abstraction that virtualization brings? With no hard data, I can't answer this question.
The Burnt Edges
Because using virtual machines give so much new flexibility to how applications are developed, a whole new host of issues also creep in. The biggest of these is how to generate these virtual appliances in the first place. What I've seen most often in "How To" documents (Amazon EC2's for example) is that you should start with a base OS install and begin to customize your appliance until it suits you. Being a virtual machine, you can then clone this machine to distribute to clients (or yourself). This works great, but is tougher to automate, and upgrade.
One thing that can help in this process is the "snapshot" feature provided by some vm vendors. This means you can set up a virtual machine how you like it, but without most of your software installed. Then when doing a distribution, you install your software, clone your machine, and revert the "template" back to a pre-install state.
Although this gives you a way of creating nearly infinite numbers of virtual appliances, it still leaves something to be desired (automation). I've noticed that as virtual appliances become more prevalent a few companies have begun offering tools to help manage this. rPath rBuilder is one such product. It uses a completely new packaging system (Conary) and its own JeOS Linux Distro.
If you're more into completely free (well, pay for service), Ubuntu also recently posted some documentation for their open-source JeOS"JeOSVMBuilder".
Anyway, The virtualization market is pretty exciting times. Migrating to virtualization can provide a *lot* of flexibility to your infrastructure. Use completely open-source software, I've been able to set up a "development server" complete with source control, project website, issue tracking, etc. AND nightly backups are as simple as copying a file to a USB disk. If you're interested in doing the same, I'd recommend looking into VirtualBox. If I can find the proper place to host (and time to clean it up), I may host my Ubuntu JeOS development server (Apache2 + Tomcat + Archiva + Hudson + Trac + SVN).
As a side note, the more I've seen of GIT the more I like it. Given some time (once again, hard to come by), I'm thinking of making the dev server be flexible enough to create new projects with svn, Hg or git.
References
[1] MIT Exokernel Operating System
[2] Red Hat Appliance Operating System
[3] rBuilder
[4] JeOSVMBuilder
0 comments:
Post a Comment