Virtual hardware have been around for decades. Mainframes have been able to host multiple operating systems and IBM is doing good business selling boxes capable of hosting thousands of linux instances.  The economics of such co-location is very compelling.

Each user of such an virtual OS instance thinks it is alone but is in fact sharing with others. If done well it reduces the amount of hardware sitting idly waiting for work. Something which was distressingly prevalent back when every single server application needed its own hardware.

Times have moved on. To the regret of SUN Microsystems which was a leading casualty of the move from physical to virtual hardware. But all the box vendors have taken a hit.

But still it is the case that applications tend to have their separate virtual box. The argument spring from several points. Developers develop from particular versions of software libraries and so depend on exact versions of application servers. A virtual OS instance tend to have only one instance of an application server and so you end of with one OS instance per application. Plus more for redundancy and DR.

The off-shot is that to run your application you end up also running a stack of other software too. Software which is not part of your business logic. Without doing any bit of useful work, all this software still needs to hum along and consume precious hardware resources. And that’s with virtualization hopefully packing everything efficiently on to the hardware so as not to waste it.

Then there is all those system instances that need to be configured and maintained.

The virtualization of hardware saved a lot of space and service work in the server room. I recall having to go in there to load CDs and reboot servers. With virtualization this is all gone.

Still I have to work with operating systems and applications servers.

I want to find a way to get rid of those too.

Just like hardware was virtualized so that multiple application easily could run on the same hardware.  It is time for application servers to be virtualized also.

How should something like that work ?

A virtual application server. It should be able to run any number of different applications simultaneously. Currently it is good practice to have separate AS instances per application. For a virtual AS this no longer makes sense.

Physical hardware can run any number of virtual OSes (resources permitting) so the virtual AS should be able to run any number of applications.

This would be something quite different from a java application running on Tomcat. A collection of java classes, supported by libraries. But which versions of those libraries ? The developer depends of very specific versions. Is not accidental that one Tomcat instance per application is preferred. The whole programming model demands it. So something new is needed.

One can argue that with hyperlinks the whole internet is such a virtual application server, in that all functions are available everywhere over URLs. Web services essentially work along these lines. But that still leaves the problem of all the application server instances. One for every web service. But if we could have one application server that could act as any web service. Simultaneously.

This ties into an objection I have against AWS. Setting up an application in Amazon’s cloud infrastructure requires configuring instances of OS and and application server. And selecting the size and version of those instances. This suggests to me more scope for virtualization. True, it gives me a precise level of control, much like what I’d have if I hosted everything myself. But I don’t want it.

When I drive a car I don’t want care about the surface of the road. I just want to get from point A to point B by car.

There is another trend going on now. Thick clients. Or apps, in the form that that most us encounter. Web services which have been consumed by other applications rather than thin clients have been around for a while, but the massive profusion of apps on tablets and cellphones is recent.

Many of these apps are stand-alone; There is no server component to their functionality. An App version of Solitaire can be solitary in every sense. But many, perhaps most do have it. So to create an app is to also create a server-side application to go with it. Possibly one server application for every app, maybe more; but in many cases one server application can serve multiple apps. Googles API is an example of this. In any case a lot of server applications are required, with functionality tailored to the requirements of the app. The app designer can avail themselves of API s, like that of Google mentioned above or other forms of more or less generic web services. But in all those cases the app designer is constrained by someone elses design. To not be limited the app designers will have to have a server application completely of their own design.

Here the virtual application server can come into its own.