Rise of the Virtual Machines

UPDATE 2: Since my last update, I discovered Mainframe2 another pretty amazing take on virtualization.

UPDATE: Since I wrote this post, I discovered Docker, another very interesting direction in virtual machines.

"Virtualization" is a term that's used pretty regularly – but exactly what do we mean when we use that term? There's roughly three levels of virtualization in use today:

  1. Hardware and CPU emulation. This is the lowest level of virtualization. Most recent implementations emulate a standard PC architecture and run machine code. Despite the recent growth in this area (VMWare, Parallels), this type of virtualization actually dates back to 1972 when IBM released VM/370 for mainframes.
  2. Byte code emulation. This higher level emulation implements an abstract computing environment (registers, memory, instructions) only – there is no true hardware emulation. This type of VM assumes it is running in the context of an operating system that provides all of the facilities hardware peripherals would normally provide. The Java VM, Microsoft's CLR, Python, Ruby and Perl are all examples of this type of VM.
  3. Sandboxing. This high level virtualization modifies the behavior of operating system calls to implement a container ("sandbox") in which normal applications become isolated from other applications and system resources as a matter of policy. Some examples are Apple's App SandboxiOS App Sandbox and Linux Containers.

What all three of these techniques have in common is that they mediate access between an application (or operating system) and it's execution environment. The goals are to increase security, manage resources more reliability and efficiently, and to simplify deployments. Theses benefits are behind the rapid rise of hardware virtualization over the last 5 years.

What's interesting is the parallels between virtualization and the web. A virtualization instance (or virtual machine – VM) creates a virtual environment for each application/operating system to operate within for both security and efficiency reasons. Web browsers also do the same thing with Javascript – each web page has it's own execution environment. You could call it level 2.5 virtualization as it it shares aspects of level 2 and 3 virtualization.

Virtualization can be a mind bending exercise – especially when you start looking at things like JSLinux. JSLinux is a hardware VM implemented in Javascript that runs inside of a web page. The demo is pretty amazing – it boots a relatively stock Linux kernel. The mind bending part is when you realize this is a level 1 VM implemented inside a level 2.5 VM. Technically, you should be able to run a web browser inside of JSLinux and launch yet another nested VM instance.

The Blue Pill

Where is all of this going? With almost 4 different types of VMs and proofs of concept that intermix them in reality altering ways (The Matrix anyone?) it seems we haven't reached the apex of this trend yet.

One path this could follow is Arc. Arc takes the browser in a slightly different direction from JSLinux. Arc takes Virtual Box and packages it into a browser plugin which is then combined with a specification for specing web downloadable virtual machines. This makes the following possible: install the Arc plugin into your browser, visit a web page with an Arc VM on it and the Arc plugin downloads the spec, assembles and launches the VM and you wind up securely running a native application via the web.

In other words, visiting a web page today could turn into launching a virtualized application tomorrow.

While there are clear efficiency and security benefits to this, there's also a huge developer benefit: developers would be able to implement web applications in almost any conceivable fashion. They can choose the operating system, the GUI toolkit and anything else they like as the basis of their application. The situation where the web tends to be the lowest common denominator gets turned on its head. Developers are now freed to develop with whatever tools provide the best experience and value to the end-user.

This fanciful scenario implies a possible future trend: the death of standards. Web standards exist and are adopted because they benefit developers – they create a homogenous ecosystem which is easier to write for and deploy into. But, if virtualization takes us to the point there the characteristics of the execution environment are so isolated from the application that they have no impact on it, why bother with standards?

If this outcome comes about, the irony will be that the Java VM shot too low when it first arrived on the scene claiming "write once, run anywhere". Maybe we are really going to end up with "create anything, run anywhere".