Server virtualization created cloud computing. Without the ability to run multiple logical server instances on a single physical server, the cloud computing economics we know today wouldn’t be possible. Most assume that server virtualization as we know it today is a fundamental enabler of the cloud, but it is only a crutch we need until cloud-based application platforms mature to the point where applications are built and deployed without any reference to current notions of servers and operating systems.
At that point, the value of server virtualization will go down substantially. This fact is not lost on virtualization leader VMware (s vmw), whose CEO Paul Maritz, less than two years after joining, has positioned the company to cannibalize its own server virtualization business with a move toward platform-as-a-service computing.
At Structure 2010, Maritz said that “clouds at the infrastructure layer are the new hardware.” The unit of cloud scaling today is the virtual server. When you go to Amazon’s (s amzn) EC2 you buy capacity by the virtual server instance hour. This will change in the next phase of the evolution of cloud computing. We are already starting to see the early signs of this transformation with Google App Engine, which has automatic scaling built in, and Heroku with its notion of dynos and workers as the units of scalability.
Developers working on top of Google App Engine and Heroku never have to think about servers, virtual or physical. In a few years, clouds at the application platform layer will be the new hardware. At that time, traditional operating systems and server virtual machines will become much less important to the cloud.
First and foremost, server virtualization generates overhead. VMware performance tests suggest that the overhead is in the 8 to 12 percent range. However, when several virtual machines run on the same server and start competing for hardware and network resources, the overhead is substantially higher. This is waste. It’s expensive. It’s bad for the environment.
Some would argue that this is a necessary, small overhead that provides security and enables great efficiencies in the data center. That’s true in the sense that without virtualization there is no easy way to take many enterprise applications architected in the 80s and 90s, bolted onto a Windows or Linux operating system and relying on resources such as files and sockets, and make them securely run on one physical server. The argument fails, however, when applied to most modern applications, which rely on network-accessible resources such as databases and Web services as opposed to local resources such as files and processes.
Aiding this trend, startups are building custom application virtualization layers that free applications from servers, obviating the need for virtualizing Windows or full-featured Linux OSes. At Structure, Tom Mornini, CTO of Engine Yard, and I spent a fascinating part of an hour with pen and paper drawing diagrams of what the new software stack looks like. Although Engine Yard’s scaling model is still focused on servers, this is an indication of their enterprise go-to-market strategy. Enterprises are still much more comfortable thinking and buying in terms of servers.
Right now, many PaaS companies deploy on virtualized servers because they are small startups that don’t own their own hardware. In the very near future, when a large cloud provider such as Amazon offers a PaaS, that provider will have the option to deploy at least a meaningful portion of the PaaS workloads of their customers against machines running a lean, stripped OS and/or a tiny hypervisor providing the barest minimum isolation from the hardware and no server virtualization layer the way the term is understood today. Multi-tenancy isolation will be achieved at the platform-as-a-service layer, not at the virtual machine layer.
The biggest hindrance to deploying these types of PaaS offerings on public clouds is trust — something Werner Vogels, CTO of Amazon, emphasized in a conversation. Right now AWS trusts the server virtualization tier to provide security and isolation. Technically, this is not harder to do at the PaaS layer. In fact, it is easier — you just have to remove or trap dangerous APIs — but I expect it will still take at least a year or two before the volume of PaaS usage makes it worthwhile for large public cloud providers to go through the effort of eliminating server virtualization overhead.
Enterprise private clouds will need server virtualization for a while, but I expect that market to peak in three years and then begin a steady decline brought about by the commoditization of basic server virtualization we are already seeing and the shift of new development to PaaS. The same will happen with traditional server operating systems. It’s not a question of if, but when.
A year after Maritz took over the reins, VMware bought SpringSource, which offered an application framework, server and management tools with a significant following in the Java developer community. Partnerships with Google around App Engine and Salesforce.com around VMforce quickly followed — putting VMware in the Java PaaS game. VMware has seen the future clearly and is preparing to move up the stack to PaaS offerings.
This was spelled out in May by VMware CTO Steve Herrod: “We are committed to making Spring the best language for cloud applications, even if that cloud is not based on VMware vSphere.” Recently, GigaOM reported that VMware may be talking to Engine Yard, the Ruby on Rails PaaS provider. Whether a deal happens or not, I’m impressed by VMware’s bold approach under Maritz.
Soon we will be able to throw away the server virtualization crutch and, like in that memorable moment from Forrest Gump, we will be able to run leaner and more scalable applications in the cloud on next-generation platforms-as-a-service. For the time being, my call to action is for application developers to stop writing code that directly touches any hardware or operating system objects and try the current generation of platforms-as-a-service.