I read a fascinating article today by Lori MacVittie who blogs over at DevCentral. Lori wrote a phenomenal post on the subject of virtual appliances versus specialized hardware entitled “When Did Specialized Hardware Become a Dirty Word?”

This post has crystallized a lot of my thinking around this topic over the past year or so. I encourage you to read it.  What I really like about Lori’s observation is that she recognizes the organizational and cultural barriers that will mean that the adoption of virtual appliances in the infrastructure will likely not yield the expected savings or efficiencies that their proponents claim.

I want to believe that I can converge my infrastructure onto a general purpose virtual infrastructure so much — but the human factor and the IT organizational imperatives that have evolved over two generations mean that this will be an uphill climb for most (if not all) organizations. I also liked the way Lori homed in on the “general purpose CPUs” virtual appliance argument which amounts to case for “a rising tide floats all the boats.”

It should be obvious that the same technology curves that make your x86 virtual infrastructure run faster each year will also boost the performance of ASICs and specialized hardware architectures. I think it would be good for the purveyors of virtual appliances to address this head-on in their marketing materials and be able to defend their value proposition vis-a-vis that of specialized hardware devices.

There are a couple of observations that are at slightly odds with some of Lori’s conclusions that I would like to make. The first (and most minor) is that at least with the VMWare platform, I do not think reliability will suffer at all in a general purpose, shared virtual infrastructure with the advent of fault tolerant virtual machine pairs. Of course, appliances designed for fault tolerance from the beginning should be able to generate extraordinary reliability levels, but sad to say, I have seen failover issues on “fault tolerant” appliances, too.

With VMWare fault tolerance, you should be able to get similar availability at a fraction of the cost.  Moreover, leveraging VMWare’s fault tolerant capability should make the design of the software stack easier and less prone to software defects because the failover is almost entirely accomplished by the hypervisor.

I think the industry is going to see a High/Low architecture emerge — especially in a service provider environment. We’ll have the high-performance, dedicated devices running on specialized hardware that apply policy across all tenants in the shared environment for all the reasons Lori identifies. However, for the unique client- or business unit-specific policies a client needs to implement, you’ll utilize virtual appliances for those applications to deal with the functionality that is unique to that organization or client. The configurations of the virtual devices would be generated from customized templates for each tenant that would apply sub-policies as required. The number of virtual appliances would fluctuate, as required based on transaction volumes.

Where I really think virtual appliances will come into their own is in public cloud service provider environments. I think it will soon become imperative for a company that wants to grow its appliance-based market share to have three “flavors” of virtual appliance — one for Amazon EC2, one for VMWare and one for Azure.  Whether it is network security, WAN content acceleration or remote data protection, I can see the need for dedicated appliances to exist in the cloud that can interoperate with compatible appliances or environments in the client’s datacenter.

Again, that High/Low mix may come into play where for performance, reliability or political reasons, the client’s “private” primary datacenters have dedicated hardware appliances and their transient cloud application environments exploit virtual appliances for the duration of their lifecycle.  It is in the cloud where I think that the virtual appliance model will really prove its worth and open up new capabilities for the users of these devices and new markets for their developers.

I think the challenge for the developers of virtual appliances (especially in Amazon EC2, Microsoft Azure and Google Apps environments where a developer operates in very prescribed environments with significant abstraction from the underlying hardware) will be to work around the constraints and restrictions imposed by the cloud provider and still deliver compelling functionality in comparison to the dedicated appliances. I also think that a few standard design templates or approaches will emerge over the next year or so that will become accepted as the “right” way to create this functionality in EC2 or Azure. It will be interesting to see how important the cloud providers themselves view these “cloud accessories” — and what accommodations the cloud providers are prepared to make to facilitate the development of virtual appliances that augment their own cloud environment’s native capabilities.

Again, kudos to Lori for a post with a lot of great insights that resonated with me and motivated me to create this riff on her underlying observations.

Randy Arthur is Chief Technical Officer of CSC Trusted Cloud Services. Follow him on Twitter @RandyDArthur.