... {section}
{include:Left Column}
{column:width=82%}
"Appliances", "virtual appliances", "software appliances", "virtual machine images", "VMs", etc. These are just a few of the terms that have garnered a lot of exposure in the past several years as the next wave of virtualization technologies breaks across the IT landscape. Everyone wants to create an "appliance" of some sort, but given the diversity of virtualization platforms and uses cases, two people referring to an appliance based on the same application may be talking about very different situations that entail separate solutions. As an aid to helping you quickly understand the range of solutions in order to quickly home in on the problems you want to solve, this document explains the contexts in which these technologies are employed.
{toc:outline=true|style=none|maxLevel=3}
h1. Fundamentals
Before diving into specific virtualization platforms and use cases, let's take a look at some fundamental terms that are used when discussing appliances:
* Virtual Machine Images, Virtual Appliances and Software Appliances
* Hardware Appliances
* Software as a Service (SaaS)
h3. Virtual Machine (VM) Images, Virtual Appliances and Software Appliances
System virtualization platforms support deployment and management of coarse grained compute units called virtual machine (VM) images. Each VM consists of an OS instance and some extent of application code.
Although the terms virtual machine image and virtual appliance are often used interchangeably, depending on the specific context, they can mean very different things. People often refer to pre-installed and pre-configured VM images as "virtual appliances" or simply "appliances". Since the term "appliance" typically implies that a device has been designed and packaged for a specific use and that ease of use is a central tenant of the user experience. Simply pre-installing and pre-configuring a stack of application software on an underlying OS instance often doesn't result in an appliance in the conventional sense of the term. When basic VM images are deployed, many, if not all, of the layers of the software stack are still exposed to deployers and administrators. There's little, if any, encapsulation of the underlying technologies contained in the VM image.
Even basic VM images can be useful in a variety of use cases. For example, when a developer wants to try out a new OS such as [OpenSolaris|http://opensolaris.com], it's relatively easy to obtain a pre-installed VM image, start it as a guest OS within a desktop-based virtualization platform and use it without disrupting your existing host OS. Once you are satisfied with the experience, you may choose to install the OS natively. In this case it's perfectly acceptable that the VM image is not engineered to be a black box. After all, you're expecting to work with a OS. Later in this document we'll highlight other use cases in which basic VM images are useful.
Since there's a substantial investment in converting a basic VM image into a true virtual appliance, examples of virtual appliances are much less prevalent. Several companies provide infrastructure and tools to enable application vendors to construct, deliver and maintain virtual appliances. These tools also help deliver high-level lifecycle management tools to significantly ease the job of maintaining the virtual appliances once they are deployed. rBuilder and rPath Appliance Platform from [rPath|http://rpath.com] are examples of such infrastructure and tools.
h3. Hardware Appliances
On the opposite end of the spectrum from basic VM images are true black box solutions delivered as hardware appliances that expose only the service and management interfaces that are required to access and manage the published service. i.e. the underlying software and hardware components are hidden from the view of the deployer. As you can imagine, hiding all of the underlying complexity from view and providing only those interfaces that matter to delivering and operating the service of interest and the associated hardware device often entails a significant engineering investment.
The wireless access point and router and Network Attached Storage (NAS) devices that you might have in your home network are good examples of appliances at this end of the spectrum. In the enterprise space, there are many examples of hardware appliances ranging from NAS servers to search appliances. The value in deploying true hardware appliances is clear: the ability for an organization to immediately realize an important service and to not be concerned with the management of the underlying details can greatly reduce operating costs and complexity.
h3. Software as a Service (SaaS)
Although the broad notion of Software as a Service (SaaS) deserves discussion that is beyond the scope of this article, it's important to note that delivery and use of hardware appliances is a form of Software as a Service (SaaS). Why? in that the user of the appliance is concerned with the use of the service provided by the appliance. From a user's and deployer's perspective the hardware appliance is a black box and the services provided by the black box could conceivably be hosted off premises and delivered over the network.
h1. Virtualization Platforms and Use Cases
Let's look at the major virtualization platforms and the most popular use cases associated with them. After that, we'll map several forms of virtual applicance and virtual machine image deliverables into these platforms.
The following types of virtualization platforms have emerged to enable developers and administrators to more easily deploy, execute and manage operating system instances along with application software than using the traditional approach of either using one OS per computer or multi-booting.
* Desktop-based Virtualization
* Enterprise Server Virtualization
* Platform as a Service (PaaS)
h2. Desktop-based Virtualization Platforms
It is quite common for technical users to operate multiple OS instances simultaneously on the same desktop or laptop using popular platfoms such as [Sun xVM VirtualBox|http://www.sun.com/software/products/virtualbox/index.jsp], [VMware Workstation|http://vmware.com] and [Parallels|http://www.parallels.com]. Although resource constraints are still a factor, ever increasing disk, memory and processor capabilities have made running multiple complete OS instances much more feasible than in the past.
Note: I've chosen to not delve into the notion of "desktop virtualization" in the sense of using enterprise servers to deliver virtual desktops to remote desktops. This is a context that is different from the standalone developer and administrator use cases in which virtualization is used on the user's local desktop or laptop. Refer to Sun's [Virtual Desktop Infrastructure (VDI)|http://www.sun.com/software/vdi/index.jsp] for more information on this other form of desktop virtualization.
h3. Desktop-based Virtualization Use Cases
Desktop-based virtualization platforms are quite useful when developers and administrators:
|Require applications or tools on an OS that is different from their preferred OS|Users can easily obtain a VM image containing the required plus applications or tools and deploy it on their desktop system without impacting their current desktop installation
|Develop applications primarily on one OS, but test and deploy on multiple OS'|Developers can easily deploy VM images of the deployment OS' and test their applications on those target OS' without requiring separate physical systems for initial testing phases
|Evaluate new operating systems and/or applications|During a temporary trial period, users can quickly deploy a VM containing the OS and potentially pre-installed applications of interest and easily remove it from their desktop system once they are done with the trial
|Build desktop-based VM images or virtual appliances|Users assemble their own VM images to either use on their own or to share with others
Whether the VM images supporting these include a desktop environment such as Gnome or KDE or are assembled without desktop software (sometimes referred to as "headless" images because there's no requirement for graphics support) depends on the user's objectives. In the case where the user is trying out a new OS as a potential replacement for his current desktop OS or the user needs a desktop environment to support an alternate toolset, the VM images need to include desktop support. However, in cases where a user is evaluating a deployment-oriented image of an application or is testing his application in a deployment-like headless OS environment, inclusion of a desktop in the VM image may just add a lot of unnecessary bulk and complexity to the VM image. |