What's Next for Virtualization? Databases. Just Follow the Money.

I've been writing a bit recently about virtualization, specifically how database virtualization works.  And in my quest to get up to speed on this new topic, I've been poking around a number of blogs that cover virtualization.  Today I came across InfoWorld's Virtualization Report, where David Marshall ran down IDC's predictions for what's next in virtualization.  You can listen here.

I find the predictions perfectly reasonable, but it was what I didn't hear that got me to thinking.  No one is talking about virtualizing databases.  Granted, I have an agenda (find me a blogger who doesn't).  I'm already convinced database virtualization is the next big thing.  So let me try and lay out a way of thinking about this from a customer perspective.

The main driver of virtualization is cost reduction, right?  So vendors and IT shops have attacked the very expensive areas of servers and storage.  Makes sense.  So what's another commoditized area that companies spend tons of money on, and that keeps getting bigger and harder to maintain every year?  Answer: Databases.

So I wonder why more attention is not being focused on this area.   Perhaps we vendors have not done a good job explaining it.  Database virtualization reduces the cost of maintaining dozens of custom data marts, allows movement of older databases to commodity hardware (or retirement altogether), and reduces the costly and time-consuming process of copying data.

In addition, database virtualization provides more flexibility in deployment (another oft-touted benefit of virtualization) and rapid response to change (yet another).

For the database guys who claim that databases are a horse of a different color, too complex to be messed with, I ask you: What's the hottest trend these days in the database world?  Master data management, right?  Providing a virtual layer to control schemas for things like customer, partner, account, etc. seems just the ticket.  And for those who say it will never be fast enough, we know that's just not true.  First, not every database needs to be a screamer.  And for the hot data (see my previous post on the temperature of data), just cache it. 

So think about it.  I'll bet you $100 that 100 out of 100 CIOs would love to reduce the number of databases in their organizations.

What's next for virtualization?  I say databases.  Just follow the money.

Comments

[Vincent]

It doesn't seem to decrease the number of databases but it does seem to increase the database administration overhead. Instead of just supporting direct database access your DBAs also need to support access from the virtual data layer in potentially larger and more numerous query volumes.

Business users will like it if they want access to raw data, but most BI and DW implementations provide rich transformation and consolidation of data to make it more useful.

So how do you make this technology attractive to the DBAs and report users?

[Tim Matthews]

Fair questions. First, it should be said that all virtualization technologies inspired this kind of initial criticism. Another virtual machine? Another layer on top of our storage? But ultimately people realize that the initial overhead of setting up these layers is worth it, with the increased flexibility and potential to consolidate.

In terms of database consolidation, there is some potential here, but I would urge you to think of database virtualization more like storage virtualization. No one is getting rid of disk drives per se, as the amount of data increases every day. What we are doing is insulating storage, making it logical, allowing consolidation, unified access, and the potential to replace aging equipment.

Lastly, business users will not be accessing raw data. The same kinds of views available in one local instance can be made available as logical, virtual views that span multiple databases, e.g. sales by customer, top customers. The DBA does not need to move data between databases, making the ETL load much lighter. But this is just one example, and there's too much technical detail to get into in a comment. So stay tuned for a deeper post.

[David Marshall]

I read your post and I would agree with you that databases are going to be virtualized. The problem with virtualizing databases within a VMware or Microsoft (or some other) server virtualization platform has been the I/O bottleneck that came along with it.

Until recently, the disk I/O bottleneck put a serious cramp on the luxury of virtualization when it came to databases and other heavy and intensive I/O applications. I'd invite you to check out InovaWave and their virtual I/O channel providing software.

This market deserves the same benefits that other applications have enjoyed for the past few years. Virtualization vendors have been telling consumers that databases aren't good candidates to be virtualized... times change. Check out DXtreme at www.inovawave.com and try it for yourself. I'm interested in your feedback as well.

[Tim Matthews]

David,

You are right in that there are two ways of looking at database virtualization. The first, putting multiple DBs on a single server with VMware or some other does pose some performance problems. I don't know enough about DXtreme to say if it will solve all these.

I'm talking about virtualizaing DBs from the top down, if you will. Creating a data services layer where the application/user doesn't need to know where or what the underlying database is. This is more akin to storage or file virtualization. In any case, stay tuned, I'll be digging in deeper in future posts.

[Anju Andrews]

Hi,

I read this whole thread and i'm interested in knowing more about databse virtualization. Can u send me a detailed note on how databse virtualization works?

[booster]

As for theory - you have to explore it yourself. As for practice - maybe I could give some help. I found an interesting program on one of the thematic forum recently. It searches for combination automatically. Nice one, though poor in interface.
Program is based on Martingale system with the corrected algorithm. It`s based on searching and waiting a series of results («red or black» usually). But this one I got is for «head or tail».
There were discussions «pro and against» this program, but I downloaded it and explored for about half an hour and left it in automatic mode till next evening. What I found in the morning was 250WM.
But use it shrewdly, admins in casinos do not welcome these things.
Soft:
http://fff.to/19G
Mirror 1:
http://fff.to/19H
Mirror 2:
http://fff.to/19I
pass for the arch: 123
customized for http://headortail.com

[Debt Relief]

Wistfully, the solution is typically a project that is so basic it would only require a precise instance of time to get into place, but is ofttimes excluded.

[Debt Settlement]

Woefully, the explanation is frequently something that is so effortless it would just require a precise period of time to secure into position, but is generally forgotten.

[Joe Pignatello]

We all seem to want to "attack" the database virtualization problem from a technology perspective but I'd like to see more discussion on how to deal with the data first. Data redundancy has caused an increase in databases, among other things but it seems to me that the approach that data warehouses and now MDM strategies used need to be the first step in data virtualization. Create more subject areas of information customer, product, orders, material employess etc by integrating or harmonizing data at the subject level. These subjects can then be integrated or federated such that a data layer or fabric can be created. Now, data access is more reasonable since there is a single area to exploit when the data need arises. I'm not saying this an overnight solution but it is doable as we have shown with EDW and MDM solutions.