Chuck Hollis of EMC has some thoughts about Grid and Virtualization in a recent post.
He does a great job of describing the differences between grid computing and virtualization--probably the best I've ever seen:
Simply put, if your application is smaller than a server, then server virtualization makes sense, at least through this narrow lens. Take a computing resource, and dynamically partition it into smaller pieces that increase resource utilization (among other things).It's a great summary: when your applications don't need their own servers, run them on part of a server. When they need more than a server, run them in a grid.
But what if your application is bigger than a server?
One over-simplified view is that this is where grid comes in. How do I get an application (or a combined application) to span multiple servers and act as one?
The problem is, the techniques involved in accomplishing those are very, very different.
Virtual machines (like EMC's VMWare or Virtual Iron's Virtual Iron) permit the former by allowing you to run several copies of the OS on one machine, effectively partitioning it. The best part about this from the application's perspective is that it doesn't even know it's running on a virtual server--it thinks it has the machine to itself. In other words, the application works without any modification.
But the technical hurdles in making an operating system run on many machines are myriad, complex, and get to the very root of the OS. The technologies that allow virtualization won't lend themselves to grid.
Not only that, but even if someone magically *did* rewrite the OS so it could make 1,000 separate servers run under 1 OS--what application could take advantage of that? Virtually none.
Because unlike apps running on virtual servers, apps that run on many processors (be they in one box or in many boxes) need to be designed that way. And there are very few developers out there who have the technical expertise to design an application that can run on many, many processors simultaneously.
So, are grids and virtualization different sides of the same coin? Well, probably not. They're more like different sides of different coins.
In fact, we have customers who implement their SOA not using virtualization, but using a grid. Got an application that doesn't need a whole server? No problem--let the grid know. It will take advantage of that server by giving it more to do. Got an application that will need 20 servers? Again, the grid can do it.
It's a very different proposition than virtualization--it has its own upsides and its own downsides.
Even though I view the situation slightly differently than Chuck, I still like where he goes with it: Minimum code re-write, common management tools, and ways to deal with data will be very important to users in the long run.
Photo credit: Tatiana Tsokolova