Virtual Appliances – More Risk than Reward?
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?
Andi.
[...] Mann recently wrote an interesting post about virtual appliances . He uses the domain name pleasediscuss.com for his blog so I figured I’d do just that. More [...]
Could you please explain what you mean exactly by “require a lot less maintenance” because this seems to ignore the obvious maintenance issues with any such appliance – by its very nature it is tied to a particular workload & activity (not multi-purpose, multi-functioning), dependent on the release cycle of a single vendor (for all stack components), is a complete unknown in terms of performance and capacity planning with not reference model elsewhere in the industry, and the quality of its IT management/monitoring/diagnostics capabilities are generally coupled to the appliance vendors own in-house skills (generally weaker than industry thought leaders in the particular domain). Your view of maintenance seems to be one of “no maintenance possible” at least from the customers perspective which might be fine in a ideal work but the enterprise space is anything but ideal (or standard) and such appliances fail to scale on many levels in the wild including mind share.
This comment was originally posted on William Vambenepe’s blog
I should add that maintenance to me (and to most customers I work with) centers largely around the Application rather than the (App)liance itself. The key goal in maintaining a system is preserving reliability of the application in relation to change – change that is dynamic (workloads, activities) and encompasses more than just static config files related to the os. It is pretty hard maintaining a system that does not allow me to adjust to changing requirements, operating contexts and processes.
This comment was originally posted on William Vambenepe’s blog
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.
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!
Andi.
[...] Virtual Appliances – More Risk than Reward? [...]