A virtual appliance is a virtual machine preinstalled with operating system, middleware, and applications. It’s ready to run after a few configurations after powering up.
The benefit of delivering a virtual appliance is obvious – it offers better out of box experience due to simplified installation/configuration and complete isolation from other applications. The disadvantage is also obvious in that it potentially uses much more system resources than sharing a virtual machine with other applications. Like any solution, it’s all about when and how you use it with what for best results. This can be a long discussion by itself.
While virtual appliance simplifies for the users, the complexity is not totally gone – it just shifts from users to the vendors. For companies that have been doing applications plus installer, the virtual appliance development could be a bit challenging. The following are some pitfalls based on my observations and practices.
#1 Virtual appliance becomes the only deliverable
As far as I can tell, virtual appliance is nice to have, not a must to have, for most applications. You got to give your customers choices. I believe installer and virtual appliance will co-exist for a long time if not forever.
To fix this mistake, you want to continue the installer, and automate the virtual appliance creation with the installer. Once everything is automated, there isn’t too much extra cost.
#2 Manually install and configure the virtual appliance
It’s true that you can manually make it work perfectly. But lack consistence is a big problem which may causes many troubles later on in support and upgrade. To fix it, you want to automate the installation and configuration with installer or scripts. This includes not only the application, but also the operating system from CD image, and any other supporting software. To speed up the build process, you can store a virtual machine template with OS preinstalled and tested.
Also, make sure the scripts are checked in code repository, just like your source code.
#3 Tight coupling to the underlying operating system
Once you decide on an operating system, it’s easy, and very natural, to use OS specific features like special commands or APIs. There is nothing wrong to do that. But note that by doing so, you make it hard to switch underlying operating systems in future releases, which may or may not be important for you.
If possible, you want to use common features so that you still have freedom to switch operating systems in the future. This freedom may give you better position to negotiate contracts and so on.
Also, some companies have strict security policies that they only use certain versions of certain operating systems. Without this freedom, you cannot sell the product to these companies. You know what it means to your company.