Easily lost in all the commotion over VMWare’s big-bang IPO this week and today’s Xensource acquisition by Citrix is a big question – has traditional virtualization run its course?
It might be fair to wonder if I’m crazy or not, and well maybe I am … but I don’t think so.
First let me say what I mean by “run its course”. By this I obviously do not mean that there is not the possibility (or even the probability) of increasing revenues for the traditional virtualization vendors, selling traditional virtualization technology – I think these revenues will continue to grow, probably even dramatically (see Larry Dignan’s post for some thoughts on this). After all, there are many more places for traditional virtualization technology and applications yet to be done. I also do not mean that there are not additional products that will be possible around traditional virtualization technologies – there will be.
What then, do I mean?
Traditional Virtualization
First a few definitions. Probably the definition I like the best for virtualization is this:
Virtualization is the abstraction of some entity from the supporting physical infrastructure.
With that in mind, in various forms traditional virtualization has been very helpful in abstracting things like instances of operating systems from the hardware on which it runs. This has led to two very helpful use cases -
- Running multiple operating systems on a single physical server (helpful in server consolidation and compatibility emulation … in fact, I use this sort of virtualization everyday to enable me to run both OSX and Windows XP on my macbook pro laptop) and
- Rapidly provisioning particular, pre-configured operating system / application stacks combinations on banks of bare-metal servers. This latter form might even be the biggest growth area, and has already led to the service providers beginning to offer naked-vm services (such as Amazon EC2, among others).
All of these forms of virtualization are about making one physical machine appear to be multiple virtual entities (one to many). While this is a very good thing, and helps with many operational problems faced by enterprises every day of the week, it only goes so far. In fact, it almost raises more questions than it answers.
How do I manage this VM sprawl? How do I know how this is all performing? How do I know what level of service my actual customers are receiving from their actual applications? How do I ensure that these applications are reliable and able to scale? For that matter, how do I create applications that can scale as needed, that can make use of as many resources (both virtual and physical) that I want to give them? How can I trust them to do what we need done, when we need it done?
Where We Must Go
Now we’re getting to what I mean.
Traditional virtualization is not able to address most of these questions well because they do not deal with the application directly. Only a layer which enables application virtualization will be able to provide the answers for all of these questions (& more) raised by traditional virtualization.
Application fabrics provide a simply abstraction for the application developer. With an application fabric,
Each application (service) scales as needed, always works as expected, and manages itself.
Notice that application virtualization must (for all but the simplest applications) enable an application to work across many independent resources (be they virtual or physical) without drama, without complication … it just needs to be true. True for fine-grained, transactional apps as well as coarse-grained analytical apps. Time-sensitive and batch-oriented. Data and computationally intensive. C, C++, Java, and .Net. Spring and pojo.
(As a quick aside, please beware of those approaches (such as traditional grids) that leave this problem to the developer. Honestly, who do they think they’re kidding?)
So this is the essence of application virtualization – applications that can automatically consume whatever resources are needed and available, always work as expected, and manage themselves. Done as an intrinsic part of the abstraction, so it is very simple for the developer.
Building on the goodness of traditional virtualization, which unfortunately can only take us so far. To build on those helpful building blocks and take us beyond the limits of traditional virtualization, true application virtualization is an absolute necessity.
That is what we do at Appistry. That is the point of EAF (the Enterprise Application Fabric).
Welcome to our world!
Technorati Tags: application virtualization, datacenter, virtualization, VMWare
{ 2 comments }
You make an excellent point. InfoQ quoted IBM’s Gerrit Huizenga as saying “The shear number of virtual servers that gets installed makes administrating almost as painful as real servers.” By virtue of my role at Topspin I was able to see this a few years back and it’s part of the reason 3tera is in the utility computing space.
The interesting question is really whether services and products like yours and ours should be thought of as virtualization at all. While the definition of virtualization you cite is liguistically correct, the common usage within the industry is really limited to describing partitioning of a physical resource into multiple smaller consumable units. The next step in evolution, however, isn’t about partitioning at all. What our companies do is aggregate resources. Whether through Amazon’s APIs, 3tera’s virtual datacenters, or Appistry’s application fabric, our users are really interested in consuming bulk resources. As such, we face completely different challenges than VMware and Xen did in building their products. Therefore, IMHO this is a new generation of technology unto itself.
hi nice post, i enjoyed it
Comments on this entry are closed.