By Peter Varhol
Virtual appliances provide a way to deliver complex software to prospects and customers. They simplify the proof of concept process for software vendors, and make it straightforward for enterprises to give a product a try without being distracted by complicated configuration steps. They also make it easy for software vendors to deploy their products as hosted SaaS offerings on public clouds. Virtual appliances can save time and technical effort, and prevent problems later in the lifecycle.
A virtual appliance consists of the software performing the required work, such as an enterprise application, along with just enough operating system (JeOS) and any required prerequisites for the application to function. It often includes supporting software such as an application server, some level of database availability, and scripting language. In the open source world, this is the LAMP stack – Linux, Apache, MySQL, and PHP, Perl, or Python.
While at first glance there doesn’t appear to be any downside to enabling customers to use software as virtual appliances, there are risks for the provider. Any self-contained software delivery is expected to work properly almost immediately, and there are some circumstances under which providers may face unexpected difficulties. Here are three common pitfalls to avoid with virtual appliances:
- Not installing and configuring the entire software stack on the virtual machine (VM). Deciding the appropriate supporting software stack for your application isn’t as easy as it may sound. You may have questions such as do you include the web server, application server, database, and configuration language? It is good practice to make a virtual appliance as self-contained as possible, as long as it can fit into any customer’s computing infrastructure. But you still may have to make compromises depending on licensing and customer preference. If you do, understand those compromises and make sure you have the ability to mitigate risks.
- Not providing a full set of configuration options on the VM. Usually a virtual appliance has to be configured as a part of the setup in the customer computing environment. It likely has to take into account the customer’s network configuration, databases, and storage architecture. Virtual appliances typically provide a configuration page for setting this up. If a customer has an unusual network or database configuration, you may find that the setup options you provide aren’t sufficient. That can delay a proof of concept installation or even kill a deal.
- Not updating the virtual appliance stack as new versions of supporting software become available. This is probably the biggest concern with using virtual appliances. Just because a virtual appliance is a self-contained unit doesn’t mean that it can be installed and forgotten about. For the enterprise software, you are probably applying patches, and maybe also doing customization once the customer better identifies its requirements. But you are likely engineering the application with updated versions of the supporting stack. You have to provide for that in the resulting virtual appliance. That may require going back to reprovision virtual appliances already in the field, and also defining new configurations for new versions being released.
None of these concerns should prevent you from creating virtual appliances. But you can’t just deploy and forget. Instead, you have to manage your appliance and its lifecycle just as closely as you would a traditional physical installation, though in a different way. The virtual appliance will help ease your software into a customer’s computing infrastructure, but only if you manage it for the long term.
To learn more about the latest features in InstallAnywhere, watch the What’s New in InstallAnywhere 2012 Webinar.