Hardware appliances are a great way to introduce technology into an enterprise because they offer many advantages, including quicker deployment, easier management and simplification of complex technology. And since appliances have become plug-and-play simple, they provide a path for solution providers to introduce complicated solutions in an expedited fashion.
Hardware appliances also introduce some negatives, such as limited scalability, proprietary hardware and closed environments, which can make upgrades or customization difficult if not impossible. This means reduced revenue for solution providers. Appliances tend to have low margins and reduce integration opportunities, while eliminating customization or upgrade revenue.
But it doesn’t have to be that way. VARs can combine open-source products with virtual server technology to build their own appliances, bringing simplicity to the enterprise but retaining high margins and the ability to upgrade. Virtualization technology makes this all possible by eliminating the proprietary hardware needed to build a hardware appliance.
Adding the open-source element allows VARs to build a customized virtual appliance that can be very profitable. Those building virtual appliances also have the option of selling generic server hardware to run one or more virtual appliances. As far as scalability is concerned, it all comes down to the power of the hardware. VARs can upgrade processors, memory and so on to increase performance if needed.
There are several methods to get involved with virtual appliances, but all of them start at a single point—selecting the virtualization product. One of the obvious choices is to use products from VMware, the 800-pound gorilla in the virtualization market, but other options include Parallels, Microsoft, QEMU and XenSource. Those developing virtual appliances can choose to go with “free” virtualization products (Microsoft and XenSource), commercial virtualization products (VMware and Parallels) or a combination.
How is a combination possible? Simply put, some companies, such as VMware, charge for the development environment (the ability to create a virtual server) and offer a run-time environment for free. In other words, a VAR will purchase the virtual server software and then distribute its package to run on a “player.” Regardless of which product family a solution provider chooses, there are several best practices for building a virtual appliance using virtual server technology.
Perhaps the biggest driving factor is what you want the virtual appliance to do. If you are using a Linux operating system and an open-source firewall to build a virtual security appliance, your requirements may differ from those for building a virtual appliance to serve up Linux desktops to remote users. Why does it matter? You need to determine the performance level desired and whether you want capabilities such as multiple sessions. That will determine if you need to use a desktop version of the virtualization software as opposed to a server version.
When building a virtual appliance, there are three primary considerations: making sure your virtual appliance offers a viable solution for the intended customer, creating an installation proc-ess that is as simple and concise as possible, and ensuring installation and update procedures do not impact existing data or host applications.
It’s important to stress to the customer that the virtual appliance is a software element that offers specific services the customer (or the VAR) can control and manage. The key element is to focus on the services offered, not so much on the hardware or software technology involved. That will help keep the sales process and subsequent training simple.
Once customers understand a virtual appliance is nothing more than a box of services that runs independently of other applications, it can make all the difference in the world if the customer needs to manage, stop, start, reset or move the virtual appliance. Solution providers should also make sure each virtual appliance is designed to be self-contained in its own virtual environment and will operate exactly the same, regardless of host machine settings, operating systems, host applications or network settings.
When defining the virtual appliance, VARs should consider configuring it to use multiple virtual hard drives. In this case, the primary virtual disk can be defined to boot the virtual appliance and will contain the guest operating system and application files. A second virtual disk can be defined to contain the application data, log files and any “nonstatic” information. A third virtual disk may be needed for a swap file (Linux/Unix environments) or for image backups.
With this approach, future operations such as backup, diagnostics, tuning and upgrades will be easier. For example, a backup of the appliance may need to contain only the contents of the second virtual drive, while an increase in swap file size for performance enhancements would affect only the third drive.
For the guest operating system and associated applications, solution providers should consider installing a minimum configuration into the virtual appliance. By installing only the components that are absolutely necessary, the virtual appliance can be kept simple, perform at its best, and be easier to troubleshoot or upgrade. The idea is to keep it simple and fast.
VARs should also make sure all software is optimized to run in a virtual environment, which means avoiding software products that are 16-bit, and attempt to make direct hardware calls (outside of the guest operating system). Those guidelines will also enhance performance and eliminate some of the strange problems 16-bit applications can introduce into a virtual environment.
When it comes to the actual building of the virtual appliance, solution providers should start from scratch with empty virtual hard drives and basic settings. That means the guest operating system should be installed into what is considered a clean system. (Some solution providers may try to save time by using an operating system that already has been virtualized, but that risks contaminating the virtual appliance with unnecessary libraries.)
The best way to accomplish this is to install the guest operating system using defaults, then remove unused features, operating system locale settings, documents and unnecessary applications. After completing the guest operating system installation and verifying its functions, install the target application or service onto the virtual appliance. Once the basics are established, documentation should be created that clearly demonstrates how to start up, shut down and administer the virtual appliance.
Because of the resources used by a virtual appliance, VARs should avoid the use of a management GUI. A text-based management interface is much less resource-intensive and can be more reliable. Advanced administration can be done via a Web-based GUI if that is available for the virtual appliance’s application. All remote administration should be set up to use a secure protocol such as HTTPS (HTTP Secure).
Solution providers also should pay close attention to the networking requirements of the virtual appliance. Unused ports should be disabled, and there should be an easy method to set initial networking parameters such as IP addresses, masks and gateways.
Final packaging of the virtual appliance should take the form of a single, installable file. Solution providers can use the .zip format, along with an automated installer to keep unpacking of the appliance as simple as possible.
For savvy VARs, virtual appliances can be a way to increase revenue; demonstrate products; build customized solutions for particular customers; or even create the latest, greatest solution and deliver it to the masses.