Application Virtualization

Our Pick / Multi-Value community has always prided itself on being able to run great multi-user applications in a powerful database with a small footprint.. The Pick model DBMS used to be called the Pick Operating system because we bundled all of these things into a package that was installable to make a piece of hardware an Application Engine. The box in the corner did nothing more than run business software and manipulate data. Then as the Windows and the Unix/*nix operating systems gained popularity, we shed the Operating System positioning and became one of many applications that co-exist in a more general purpose environment which manages the underlying resources. As they say, what goes around comes around, and what used to be popular will be again. What we’re seeing now is a trend back to dedicating entire operating environments to a specific purpose.

The trend toward specialization started with the Linux distro, which is really only a customized collection of hand-picked libraries pre-assembled around a preferred kernel. Most distros are feature-packed general purpose environments, but each one prides itself more for server use or more for workstation use, etc. Some distros are popular not for being big, but for being very small and doing only one thing, but doing it well. The first one of these that I used was called ShareTheNet, a complete kernel/lib distro available on a floppy that only did one thing – it allowed us to use an old i386 as a NAT router and put multiple PCs behind a single cable modem.

Now, rather than general purpose distributions, special purpose distros are being built which include a complete *nix OS, but they only include libraries and components required to accomplish specific functions. Examples of this include IPCOP, one of many software router/firewall packages, and Asterisk@Home, a PBX system for VOIP. Don’t let the @Home part fool you, there is a lot in there to make this usable by companies of many sizes – and that’s the point. Asterisk@Home is a custom package assembled with Asterisk over CentOS, and including SugarCRM and other applications to provide a more complete solution. The key word here is "solution", because the distro is no longer just a tool, it is truly a solution to solve specific problems.

These packages typically include a web server for administration, a database, and other tools for customization and patching. "Third-party" offerings frequently appear as add-ons, plug-ins, mods, patches, etc, where community-minded individuals contribute code or documentation which helps others enhance the package or extend its usefulness.

For you Pickies out there, isn’t this what we used to do when we added JET, CompuSheet, AccuPlot, or a custom SYSPROG account for system administration? Granted the process was usually, not always, done in two steps: we’d install the OS/DBMS and then add apps, tools, etc as separate account saves, or via macros that install everything as part of a bootstrap process. Some VARs rebuilt sysgen media with their apps and everything else required for a base working environment.

So how is this done now?

Virtualization and creating a custom distro are similar but different. Rather than going on-site to install your application or providing instructions for an end-user to do it on their own, you want to build a complete environment that can be installed just by inserting a CD and allowing the end-user to answer a few questions. With a distro, a bootable CD or .ISO file (image of a CD) is provided and an end-user installs this as a complete operating system into a physical box or VMware or Microsoft Virtual PC environment. With virtualization, you build the complete working environment as a VMware or VPC image, and give that image to the end-user. The user starts the OS and application as a completely self-contained executable running over their existing OS. This virtual environment is itself the application, and your business software and the infrastructure required to support it is completely isolated from the end-user’s "real" environment.

All kinds of issues start to come up when one considers this for commercial use.

• What if your application is Windows based? There are no "distros" of Windows, but Microsoft does have families of Windows products including Compact/Mobile, Home, Professional, Server, Media Center, TabletPC, and Data Center. Linux and similar *nix operating systems are free but licensing is involved with distribution of Windows. Windows can’t be scaled down as much as a Linux distro, but you can whittle out all sorts of things that aren’t required in order to streamline the deliverable.
• What about connectivity with the outside world? Your virtual environment needs to connect to the local network so it must be easily configurable, hopefully from "outside". As an application, often called an embedded appliance, your environment should always be "on" and not require any external startup once the environment is started, then anyone should be able to connect in via standard tools like a web browser, telnet client, web service, or thick-client app.
• What about support and patches, etc. Every MV environment is patched differently. If possible the patching process should be automated. Another way to do this is to script or document a process where all custom data and configurations can be backed-up to an external environment and then restored to a completely virgin environment if the user chooses to simply replace the whole thing.
• What about DBMS licensing or other per-seat licenses which are tied to the environment? Again, each product is different and the activation process of many products was not designed with this sort of virtualization in mind. The appropriate thing to do is to ship deactivated products along with scripts or documentation which will allow the end-user to get activation from the required vendor(s).

Rather than focus on the problems, consider whether the benefits are worth the effort required to achieve them.

• Virtualization facilitates distribution of demos and prototypes – completely working environments that you can set with some drop-dead mechanism to protect your assets.
• Your clients and prospects don’t need to figure out how to setup your environment just to see and use your demos – you don’t want the "ease-of-use" experience you advertise for your application to be confused with what might be a not-so-easy install process.
• Consider the reduction of Support costs due to conflicting *nix dependencies, improperly configured environments, missed installation steps, or DLL Hell resulting from installation of your own code or something added later which breaks your code. If you completely control the OS then there are no surprises.

This isn’t a solution for everyone, but considering this is the only way we used to do it, most Pickies can’t complain that the model is generally invalid either. Like the ASP SOA model, things we validated years ago are now again acceptable in the business world. Don’t be so anxious to modernize that you forget the benefits of the things that used to work, and techniques that you can employ to prove that your offering is just as modern as anything else out there.

Here is a collection of links that leads to information and virtualized apps Here is one company of many that specializes in this sort of thing (no knowledge, affiliation, or advocacy of their offerings).