Common Pitfalls When Developing Virtual Appliances

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.

This entry was posted in Software Development, Virtualization and tagged , . Bookmark the permalink. Post a comment or leave a trackback: Trackback URL.

Post a Comment

Your email is never published nor shared. Required fields are marked *

*
*

You may use these HTML tags and attributes <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

  • NEED HELP?


    My consulting helps clients with virtualization and cloud computing, including VMware infrastructure automation and orchestration, vSphere management APIs, and deep product integration with hypervisors. Current training offerings include vSphere APIs training, vCenter Orchestrator training, and etc. Should you, or someone you know, need these consulting services or training, please feel free to contact me: steve __AT__ doublecloud.org.

    Me: Steve Jin, VMware vExpert who authored the VMware VI and vSphere SDK by Prentice Hall, and created the de factor open source vSphere Java API while working at VMware engineering. Companies like Cisco, EMC, NetApp, HP, Dell, VMware, are among the users of the API and other tools I developed for their products, internal IT orchestration, and test automation.