An oft referenced problem in the Windows world is .Dll Hell (*). It occurs when many applications depend upon the code in a shared .dll (a dynamic link library, which is basically code that is linked at runtime rather than compile time), an often ideal scenario given that you can upgrade security faults in one single location rather than recompiling and distributing static linked library using applications, or searching for disparate private copies scattered across volumes. Problems start to happen, however, if the dll is changed in a way that breaks some of the dependent consumers (for instance one of the applications rolls out a new version that changed the external API), causing inconsistencies or outright failures in other applications.

[* - Sidenote: The Wikipedia article linked from DLL Hell claims that the term was "introduced to the general public by Rick Anderson" in 2000. This is, of course, complete and utter nonsense -- it was a very common piece of terminology many years earlier, and an MSDN article hardly introduces it to the "general public". I come across these sorts of historical revisionisms on Wikipedia far too many times. Is it a Wikiality? I suppose I "introduced SVG to the general public" when I wrote a "paper" for MSDN Magazine, so I should go claim my crown...]

While the problem already existed for classic-code dlls that were stored in a shared location (usually for space-saving reasons), it really became a problem with OCX/COM, where the activation architecture basically demanded that you use the shared copy.

In spirit, similar problems occur even with high-level platforms such as Apache, or even just modules like PHP, where a version change can break a lot of applications that run atop it or depend upon it, causing significant heartache, and making deployment issues much more complex (particularly when you have multiple dependent applications, some of them more adaptable than others) .

There have been many declarations of an "end to DLL hell!", with Microsoft pushing various approaches and strategies, to varying success.

With .NET, the solution is generally "share nothing", to the point that even the various versions of the .NET runtime exist as islands, with a .NET 2.0 application having all of its libraries local (often version linking, so if the same library exists in many applications, but the versions differ slightly, it will be loaded separately and mapped individually), even if they're components used by dozens of applications, using the .NET 2.0 framework island and runtime, while a .NET 1.1 application exists in its own little world, and the same for a .NET 1.0 app. There still exists a classic "shared activation" model via the global assembly cache (GAC); however it's a little used bit of infrastructure.

Storage space is incredibly cheap, and memory space is becoming a non-issue, so this sort of approach has a lot of merit.

Why not take it a level higher? With massively powerful servers, seemingly endless memory, and free virtual server products (from both VMWare and Microsoft), we're entering an era when it is entirely possible, and often ideal, to release your product as a complete virtual server.

Of course, I'm repeating myself now, but this idea really appeals to me.

Some time back, for instance, I was considering making a commercial, corporate web application timesheet tracking system (I've made some of these before. One particular one - an AJAXish DHTML solution I made back in the late 90s - I still think beats out most of what I see today), however a hosted model wouldn't fly with most customers given the amount of information that could be garnered from their timesheets: Many customers would want to host it themselves. Yet then you face the dilemma of releasing a product that can exist within their current architecture and skillset, a particularly onerous task given the many dependencies of a modern web application.

Inevitably you'd be putting yourself out of contention for a lot of customers because you used X instead of Y, and would be endlessly fielding support issues when their platform changed faster (or slower) than your application did.

So why not release your web application (or any type of application) on an "appliance" virtual machine, as it's now getting named? The same goes for application "consumption": If you're a Windows shop, instead of hosting your wiki on Windows, or far worse limiting your choices to the small selection of options that exist for your particular ecosystem of dependencies, perhaps you could just deploy a Wiki appliance with the perfectly ideal configuration of database server, web server, host operating system, and modules.

Configure your appliance to only allow port 80 traffic in (or better yet work on an appliance platform where the accessible ports on each virtual machine can be configured, perhaps by a separate "firewall" virtual machine), and live in an application model, with whatever version of MySQL, Postgresql, or Apache you want, custom configured in a way that perfectly matches your requirements.

Virtual machines have so many advantages, not the least of which is the ability to move them between hardware with minimal hassle. Indeed, I had exactly this scenario recently, where the Team Foundation Server application tier was running on a box that was getting a little overloaded...well it was just a virtual machine, so it was nothing more than pausing the state, moving it to another virtual server hosting box, and starting it up. This balanced the load better, and was completely transparent to the users.

There are downsides that would have to be taken into account - some shops might want a better backup solution than pausing the virtual machine and archiving the entire virtual hard drive (which is, I should mention, a wonderful capability -- the entire "machine" in one single, relatively small file, atomically copyable and restorable. In development I've used this endless to save various platform configurations, restoring to exactly the one that is pertinent for a particular need), however there are endless possible, application specific solutions to this sort of problem.

There's also the issue that Microsoft doesn't take kindly to releasing virtual machines based on their software, so perhaps this is a model that works best when the software you're depending upon is freely distributable (within the confines of the license).