The Problem With Virtual Appliances

Ok, this one has been a long time coming for me – it’s in no way any kind of response to Mike D’s recent post about VMware, SaaS, and the Virtual Appliance Marketplace – that post simply reminded me that I need to get this off my chest.

The great thing about Virtual Appliances (VA’s) is that an application vendor can configure the OS to their liking, and tune their app to match. But the worst thing about VA’s, is that an _application_ vendor can configure the OS to their liking, and tune their app to match. In my experience, what ISV’s don’t know about operating systems (as they are used in the enterprise) could fill a several tomes (obviously I’m talking about ISV’s who don’t also produce operating systems themselves).

Now I’ll be the first to admit that problem mainly pertains to the enterprise. We have engineering teams dedicated to ensuring a minimal number of operating systems are deployed in the environment, to reduce complexity and overhead. By that I mean a reduction in the number of patching, monitoring, backup and auditing agents and configurations, fewer security standards, less support staff, less driver verification work, hardware certification work etc etc. I’m sure I really don’t need to explain this concept. So in the server world, this usually entails 1 versions of Windows, 1 version of Linux, and 2 EUNUCHS UNIX variants (usually because of the obscene cost and proportional criticality of big iron).

Given that the majority of VA’s are Linux based, I’m going to concentrate on that. The principles apply to whatever flavour of OS a VA may use however.

So, in line with my earlier statement, it would be monumentally naive to think that VA’s are somehow a better, nay, viable option for the enterprise at this point in time. Even if the VA was running the same version of Linux that is being run internally, it won’t have the same OS configuration. It likely will not have the same versions of packages (OpenSSH, Tomcat, Apache, Java etc) or OS utilities (fsck etc) that have been signed off internally for production use. It likely won’t have the same kernel version that has been signed off internally for production use. It won’t have the requisite monitoring, backup or auditing agents. And without any of these things, it sure as hell isn’t going anywhere near a production environment. What’s easier for me in the enterprise – to take an application installer and drop it onto my existing coporate standard build, or to take a virtual appliance, reverse engineer a diff from my corporate standard (because you know the application vendor won’t have documented what they did to the OS in any detail), try to bring it into line with my corporate standard while ensuring the application doesn’t break… I could go on, but I won’t.

VA’s are also not a very good idea for application vendors, because it puts them in a a somewhat contradictory situation of either minimising and tuning the OS so much to try and class it as a “black box” that the burden of OS security and patching falls entirely back on them (so they now need to employ an OS guru), or leaving the OS as vanilla as possible in which case what was the point of lumping your app with the OS again? So you didn’t have to write a fucking installer?

Finally, there is the problem that VMware of all people is the most guilty – consistency of the VA platform. Right now, there are at least 5 VA’s publicly available from VMware, and contained therein are 5 different versions of Linux. There’s VIMA (RHEL 5.2 x64), there’s the RCLI (Debian 3.1), VCAP (Ubuntu 7.10), VMware Studio (Ubuntu 7.04), and vCenter on Linux (CentOS 5.0). Now sure some of those are tech previews / beta’s / not-for-production-use / whatever… I’m not complaining about the Enterprise supportability of the OSes, I’m asking what kind of a message is it sending. That any old OS is good enough for a VA? That VMware themselves don’t even have an internal standard on this? Appalling.

Now despite all the above, I love the concept of VA’s. It just needs to be implemented correctly if it’s ever going to make it into the enterprise, and the correct way to do that is how rPath have been doing it for some time, or how Suse are doing it with Suse Studio. One might even imagine that VMware Studio will one day offer the ability to add “plugins” which would just be applications, so that Enterprises can create their own JeOS templates using whatever Linux build they like, and simply drop the app in. Now there’s an idea.


5 Responses to “The Problem With Virtual Appliances”

  1. Mike Laverick Says:

    I think you raise some excellent points here – quite aside to the issue of corporate standards etc… Two things that irks me about VAs. Firstly, this .OVF format – its different in Vi3.5 as opposed to vSphere4. VA’s listed in the market place and downloadable from the vSphere Client – won’t import because it doesn’t recognise the older .OVF format. Think about “Open VM format” – its meant to be standard but its all ready bloody broken! Second bugbear. The whole “encapsulation” and everything-is-a-just-a-file. Yeah, well a vmx file in workstation is different from server is different from ESX, is different from ESX3 to ESX4. There 6 different types of virtual disks in ESX alone – and the formats in workstation aren’t the same. So much for portability – say hello to command-line tools (like vmkfstools) and conversion utilities – and that’s just ONE vendor. I would love to get a industry standard just on the VM files (I go along with Scott Lowe on this) but I just know we won’t get it – and even we do it will be out of date – and deviated from by some vendor… [END RANT]

  2. The Problem With Virtual Appliances | The Black Ball Says:

    […] original here:  The Problem With Virtual Appliances Share and […]

  3. gorto Says:

    Top article – it could well explain why concept of VAMs have been around for many (3+) years but hardly ever taken up – too many pitfalls to overcome.

  4. Mike DiPetrillo Says:

    I like your last idea of putting a plug-in option in VMware Studio so you can roll your own base build. I also like what the guys at rPath are doing. It is a little embarrassing that we have so many options. Time to revisit that. I guess this is all what standards are for. There’s a ways to go there.

    Thanks for getting all of this off your chest.

  5. stu Says:

    Thanks for taking the time comment guys… lucky I didn’t think about those points you bring up Mr Laverick, there may have been a few more expletives in there 🙂

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: