Sometimes you make a connection between two concepts, and it helps.
Forgive me if others have already made the connection between grid and virtualization, but it popped up today in an interesting discussion with a customer, so I thought I'd share it.
The question was simple enough: "when should I be thinking grid, and when should I be thinking server virtualization?".
Now, keep in mind, I am frequently accused of dramatically oversimplifying things.
I really see them as two sides of the same coin, and with more in common than you might think.
It's All About Containers
Applications and databases need to run in containers. Historically, we've thought about that as a physical stack of a server, storage, operating system and some associated tools. One application usually required one physical container.
Server virtualization (specifically VMware) improved on that model by creating logical containers. Every application has a virtual server, and its image of the operating system, but -- many containers could run on the same physical server/storage stack at the same time.
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).
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? Now I need container needs to present a logical container that might be made of multiple servers.
What's in Common?
Given that IT organizations will end up having both -- applications that are smaller than a server, and applications that are larger than a server, it's a useful exercise to think what's in common, rather than what's different. And the list is pretty similar.
- Both abstract an application from the underlying resources.
- Both need the ability to dynamically react to the need for less or more resources.
- Both need similar capabilities to be invoked, orchestrated and service-level managed.
- Both need a common data space to do their work -- no hard-binding of information to application will work here.
And, if we go a bit further
- Both will need to act as entities in a SOA environment: some services will require a fraction of a server's resource, others will require multiple servers to gang up.
- Both will ultimately successful if they force an absolute minimum of code re-write, and support the model of "re-use what you've got".
- Both will benefit from common management tools that support both traditional (non-virtualized and/or non-grid architectures) as well as the newer variants.
- Not to scare you, but both require a substantial re-thinking of how information is protected. If you're doing traditional backup and recovery, you won't be happy in the new world of virtualization and grid. If you're doing more advanced forms of information protection (e.g. replication), you'll be even less happy.
So Where Does That Leave Us?
I think it makes sense -- in the long term -- to think of abstracted computing environments, and not virtualization and grid specifically. To do so could result in multiple IT stacks being built, followed by the inevitable reconciliation and reintegration.
I also think it makes sense to think primarily about next-gen management tools using this lens. OK, maybe they've got a plan for grid, but what about server virtualization? Or vice versa? I think that -- before long -- both will be a staple of the IT landscape, so we should think appropriately.
And, when vendors are talking about what's the latest thing in backup, or replication, or high availability, make sure you understand how this investment could be used in either a grid environment, a virtualized environment, or both.