What version are you running?

There are many aspects of the IT business that have been turned upside down the internet. One concept which is effectively being meaningless is the concept of a "version" in the sense of an application software package version number/name or an operating system version number/name.

I could tell you, for example, that I am running Ubuntu 8.04 as I write this but what does that mean? After all, this machine connects to the umbilical cord to feed every day (i.e. I connect it to the internet). Once there, it goes fishing for updates to the packages I have installed. After these bouts of feeding, I end up still running Ubuntu 8.04 but it is clearly not the same operating system as it was before the update. As well as updated end-user applications, I might have new device drivers, new background processes, I might even have a brand new brain (kernel). Am I really still running Ubuntu 8.04?

Other platforms do the same sort of thing. In these days of ready connectivity, "phoning home" for updates is very commonplace. Microsoft Windows does it. Apple iPhones do it. Playstations do it...What versions of those are you running? Not a question with a simple answer is it?

Switching tack to cloud services let me ask you this. What version of Google search are you running? The question is meaningless in a very interesting way. You are running the "version" that was on one of Google's servers at the instant you asked for the page. That's it. All other versioning machinery is behind the scenes. It is not something end-users even think about.

Marketing forces still like to make use of numbers/names of course and that is fine but as the complexity of the interconnections between software pieces grows, the version number of one component out of many ceases to be very useful to the poor technologists working with them.

What if I tell you I am running Microsoft Windows XP and I have some problem printing a web page from my application? Saying I am running Microsoft Windows XP is useful but only the start of the version information relevant to fixing the problem. A possible chain of important version information in this scenario would include service pack, patch levels, browser versions, .NET run time version, JVM version, display device driver version, printer device driver version etc. etc...Pretty soon the effective version number is a thing of considerable length, complexity and unwieldiness.

There are a number of inter-related developments that are attempting to address this. At an application development level, systems like

Subversion create versions, not of individual files, but of entire repositories of files. In one fell swoop, it gives developer the ability to completely specify every last byte of a myriad of files in one small, tidy little number called the revision number.

At an application deployment level, applications like remastersys make it possible to snapshot a complete configuration of essentially everything from the OS layer upwards, and create an installation CD from it.

Also at an application deployment level, virtualization and the concept of application "appliance" continues to grow apace. One of the great benefits of this approach from an application perspective is that developers get to lock down - to N decimal places - everything in the environment their application lives is. Finally, at an application deployment level, it doesn't take much of a leap to see how this idea its in with services like Microsoft Azure and Amazon's EC2.

The only way of dealing with the complexity of software inter-twinglements is to lock everything down. There are a finite number of ways of delivering a completely locked down configuration to a customer.

1. You could provide an entire box or boxes that house your applications.

2. You could provide software appliances to be loaded into your customer's infrastructure.

3. You could host your entire service in the cloud.

4. You could take your chances and try to deal with the inevitable differences between what you developed on/in/under/beside, and what the user wants to deploy on/in/under/beside. I.e. service pack, patch levels, browser versions, .NET run time version, JVM version, display device driver version, printer device driver version etc. etc...

Number (4) is becoming more and more complex with every passing year. Numbers 1, 2 and 3 all have pros and cons and I suspect they will all have bright futures in the years ahead.

I predict the demise of number (4) in two phases. The first phase will result in it no longer being viable to try (4) on the server side. It will live longer on the client side, hanging on until the day when commoditized multi-core processors and built-in virtual machines are par for the course.

As an application developer, I look forward to attending the wake.

ITWorld DealPost: The best in tech deals and discounts.