Virtual Appliances – More Risk than Reward?

October 29, 2009

I have to say – and I have said it before – I am not a great fan of the ‘virtual appliance’ model for delivering enterprise management software. Specifically, I have ongoing concerns about how these software appliances break compliance, security, and other important management and policy requirements.

For example:

  • Virtual appliances add an unknown operating system to the environment. It is typically a slimmed-down Linux distro, but you rarely know – it could be DR-DOS 6.2 or a pirate copy of Windows ME. This breaks any software SOE, ignoring top level decisions on OS stability, reliability, longevity, security, etc.
  • Administrators have virtually no control over virtual appliance management. Management functions are required for any software, but virtual appliances rely entirely on a middle-man for proper OS, middleware, application, and database patches & upgrades, malware detection, performance monitoring, problem analysis, etc.
  • Even when ad hoc management is possible, it is almost always manual. You can’t put agents on most virtual appliances, they don’t come with WMI, and most have only a GUI for management. So you cannot use standard tools or automation, which wastes admins’ time, risks audit non-compliance, and invites human error.
  • Security is a particular concern. Timeliness of patches, effectiveness of hardening processes, zero-day threat response, malware protection, and so on are all at the whim of the vendor, and rarely disclosed to the customer.
  • You pretty much have to pay maintenance. If you don’t, chances are you simply cannot keep a virtual appliance up-to-date yourself.

Of course, many of the same criticisms can be slated against physical appliances. I have even talked with one enterprise that will not deploy even physical management appliances because they would break the company’s hardware SOE (even though network devices, storage systems, and other ‘boxes’ are often just purpose-built appliances). However, with just an Ethernet cable connecting them to the enterprise, and a generally slimmer system profile, they seem to pose a lesser risk. They are also much simpler than virtual appliances, which add (in many cases unnecessarily) a layer of complexity and abstraction that physical appliances do not, by virtue of being encapsulated within a virtual machine. Moreover, the resources and effort to build a ‘real’ appliance is far greater than just slapping some software into a virtual machine, so physical appliance vendors seem somehow more committed, more reliable.

Is this distinction fair? Possibly not. But regardless of my own concerns, my research has shown that virtual appliances are the least-preferred of any form factor for management software, with physical appliances, niche software, and even software suites more preferred. Really, when the dreaded ‘framework’ is more popular than you, perhaps you really are an ugly duckling.

Which is not to say that virtual appliances are pointless. They are easy to implement, provide fast time-to-value, and are especially good for trials and POCs. They require little or no tuning, and the OS environment is often a bare bones install which is fast and efficient. Unlike physical appliances, they are easily scalable, and highly mobile. They can be deployed in seconds (maybe minutes) even to far-flung locations in regional offices with zero travel time and cost. And they allow even a sysop to deploy a new management server without getting the network, storage, security, or server teams involved. All of these are powerful factors in their favour.

I am also seeing, despite their potential issues, that several vendors are being very successful selling virtual appliances. KACE, for example, told me today that 26% of their total sales in Q3’09 have been of their virtual appliance, the V-KBOX; VKernel provide all their software in virtual appliance formats, and their Q3’09 sales were 205% up on Q3’08; Citrix is finding a remarkable early demand for their Netscaler VPX virtual appliance.  Meanwhile, IBM, Symantec, up.time, Reflex, SourceFire, and several others are agressively in or entering the market for management systems delivered as virtual appliances.

I also think that virtual appliances have a bright future – but in some ways I continue to see them as a beta version of what could (or should) come next.  By adding in capabilities for responsible and accountable management, they could form the basis of more fully-functional virtual service management containers. These in turn could form the basis of elastic, mobile, network-deployed, responsible cloud appliances that deliver complete end-to-end service management without regard to physical location or domain of control.

A couple of vendors are clearly headed this way, but even without this level of sophistication and maturity,  it certainly seems like vendors and buyers are increasingly embracing virtual appliances, despite their many potential flaws.

Perhaps I should too?


Tags: , , , , , , , , , ,

6 Responses to Virtual Appliances – More Risk than Reward?

  1. Carl Skow
    March 11, 2010 at 14:57

    I’m not quite following this security issue. Of course it’s different from a physical model, but honestly is analogous to any other VM in the environment. For example, we can run a vapp created directly off of a supported platform like, and have the full support of Novell, as it’s the same kernel, modules, libraries underneath; there’s just less of them.

    From the management perspective, a vApp can be a waterfall of “rip out and replace with updated vApp version” for patching, and if you can verify that all of the appliances are up to your certified gold standard version, you can insure compliance as you know all vApp systems were built the same, just service different applications.

    As long as you can build a multi-tenant solution with newer infrastructure, we can keep it completely compliant from the service perspective and siloed any way we’d like.

    In terms of the security of the hypervisior itself, this varies by manufacturer. I can assure that many high security government agencies leverage virtualization technologies, and I know VMware ESX(i) 4.X is going through EAL4+ certification right now ( ESX 3.0 already had it.

    • March 14, 2010 at 22:58

      Hey Carl,

      Unlike any other VM, the vApp consumer normally has no ability to patch it directly. They must trust the vApp provider to deliver patches quickly and reliably.

      For zero-day vulnerabilities especially, this means the supply chain for patch delivery (OS/hypervisor/other OEM vendor to vApp provider to vAPp consumer) is extended.

      I believe this added step in the patch supply chain is a significant risk.

      But you are right – it is entirely possible to secure a virtual appliance with a good provider that has a good process. Some lag between OEM patch and vApp patch availability is inevitable; but your suggestions are good ones.

      P.S. sorry it took so long to approve your comment. It was automatically held for moderation because of the links (anti-spam measure), but I was between laptops and missed the notification email.

  2. November 5, 2009 at 00:27

    Jacques, I agree on the security issues especially. It really is under-appreciated. Virtual appliances are fundamentally different from physical appliances in the way they present a wider target, and the hypervisor as you say is not impenetrable. Your preference for h/w appliances is not uncommon for these reasons (and more).

    Thanks for adding some good comments on my blog!


  3. Jacques Talbot
    November 4, 2009 at 06:27

    As William pointed out, you (we actually) should separate architectural and tactical arguments.
    Tactical arguments can always be attributed to a lack of maturity and can eventually be fixed.

    However, IMHO, the strongest architectural argument against vAppliances is security proofing. You cannot certify the vApp+Hypervisor combo. In the name of “depth defense”, it seems difficult to accept in the cloud that the hypervisor is the sole shield against the enemy, because it can have some weaknesses too.
    So I would rather user HW appliances to build the basic security boundaries in the cloud.