If developers will not write “virtualization aware” applications, who will? The future of application development platforms may be at stake…

Right now developers are packaging up applications in virtual machines and deploying them. That’s according to, well, every survey you find related to virtualization and cloud computing. Joe McKendrick, citing the latest Evans Data Cloud Development Survey, noted that “sixty-one percent of 400 developers in Evans Data Corp’s recent Cloud Development Survey report that at least some of their IT resources will move to the public cloud within the next year.”

But even given the number of developers deploying applications in virtualized environments, internal and external, it’s probably true that they aren’t writing “virtualization aware” applications.

Why? Because “virtualization aware” applications require some specific development at the operating system/driver layers. Layers that very few developers ever touch, especially those who develop atop existing application “platforms” such as Java EE, Microsoft, a LAMP stack, or Ruby. Developers writing applications that target these environments rarely, if ever, write as low as even the TCP socket layer. Diving deeper into the operating system/driver layer is simply not something they’re likely to do. Yet the advantages of writing to these layers is higher efficiency of the application as well as increased performance, because it effectively bypasses the additional layers of abstraction introduced by virtualization technology.

Even if a developer wanted to write a virtualization aware application it’s unlikely they could. Application platform and deployment environments have abstracted development so far from the specific layers of the network stack that need to be virtualization aware that it’s quite impossible a developer could write such code and still have it deployable in traditional application platform environments.

So if developers won’t or can’t write virtualization aware applications, how can virtualization aware applications ever see the light of day?

It willl be up to the operating system and application platform vendors: Oracle, Microsoft, IBM, and open source communities, to embrace and extend these platforms to be themselves virtualization aware. In doing so, the benefits of a virtualization aware platform will propagate up the stack and make it possible for developers to write more efficient applications for virtualized environments. Consider, for example, a cloud computing provider startup called Makara. It is necessarily a PaaS vendor because it has extended the traditional environment in order to provide developers and by extension customers visibility into cloud-based applications without requiring specific user-agents or other technical mechanisms used to “work around” traditional limitations.

Makara has leveraged virtualization to revolutionize application management. Unlike traditional application management that works by installing software agents on top of the application layer, Makara takes advantage of a hypervisor and uses the virtual layer under the application to gain significant software development leverage. In the same way that the hypervisor is able to manage virtual servers without installing agents on them, Makara is able to manage applications without installing agents on them.

It’s this kind of innovative solution to one of challenges (visibility) introduced by virtualization that will, in the long term, win over developers and organizations if application platforms do not begin to move toward becoming virtualization aware. The reason some may balk at that prospect, is that such awareness can require code specific to the virtualization technology. Virtualization awareness isn’t (nor is it likely to be) a generic framework API to which application platform vendors can write generic, portable code. That means that application packaging would no longer be portable across all environments, which greatly decreases the value proposition for many platforms.

It also means politics may come into play, with virtualization vendors courting (and vice-versa) application platform vendors for strategic partnerships that lock out other vendors from the game. Control of the application stack, ultimately, could be one of the most highly sought after strategic points of influence in the market. Take VMware’s acquisition of SpringSource and subsequent commentary on what is planned for the new acquisition:

VMware and SpringSource plan to deliver compelling new solutions that enable companies to more efficiently build, run and manage applications within both internal and external cloud architectures.

Then consider this excerpt from a virtualization-aware blogger on the acquisition which notes a similar movement “up the stack” of virtualization awareness:

 VMware is willing to create a more integrated application layer, through virtualization hooks in the SpringSource framework, that will make new Java-based applications VMware-aware.

There’s clearly a move toward controlling the application stack and toward a virtualization-platform specific PaaS that will (hopefully) be enabled with more visibility and options than your standard package and deploy strategy. What’s interesting is that PaaS may not remain external only, if VMware follows through on such plans. That means VMware – and other virtualization vendors, if they chose to follow suit, can make a convincing argument for replacing traditional web application platforms in the enterprise. That’s a big market, and one that’s certainly already moving toward virtualization anyway. Partnerships and/or acquisitions will almost certainly shape the future of application development platforms both in and outside the enterprise.

And I bet you thought the application platform wars were well and truly over and that there was very little room left upon which platforms could compete. Thanks to virtualization, the next few years could be very interesting…