Database Virtualization for Business Continuity

I happened across Ken Oestreich's Fountainhead blog, where he recounts the following from a conversation with a sales rep:

"He's noted that "Virtualization" is being inaccurately  subsumed to mean the software hypervisors purveyed by VMware.

You know, I couldn't agree more.  VMware is certainly the best known virtualization product, and a good jumping off point for discussions, but I think people need to understand that this is a bigger trend, as IDC is covering.

The problem with only understanding server virtualizaiton is that you limit your thinking to hardware consolidation.  And there are so many other benefits.  One that I've been paying attention to recently is business continuity (nee disaster recovery).

When you think about it, this is a great fit for database virtualization.  What happens when my database goes kaput?  When you virtualize, you have options.  You can redirect to another database.  Or, you could even have a backup Web Service that would provide the data (perhaps master data, position data, sales data).  The virtualization layer insulates the users and applications from outage.

Last year, Ipedo introduced a feature called dynamic failover redirection, where Ipedo XIP can automatically look to a pre-defined replica if the primary data source is not available. This boosts uptime and minimizes business disruption by delivering real-time information to users from wherever it resides. 

Think of it as failover at the the view level - read virtual level - rather than at the database level.  Another interesting aspect of the ever expanding world of virtualization.

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.

A Discussion on Virtualization with Stephen Hayward

Had a good conversation with Stephen Hayward of ProjectX around data virtualization.  Stephen did a good job summarizing the discussion and providing some background, which you can see in this entry  Or go right to the podcast.

What Does Data Temperature Mean, and What's It Got to do with Data Virtualization?

I was reading a post from Dan Linstedt from last year on the temperature of data.  This is a very interesting concept, and so intuitive I wondered why I had never heard it before.

You should read the whole of Temperature of Data for RDBMS, and DW 2.0, but here are Dan's definitions, summarized:

• Hot = accessed all the time, or extremely important data requiring sub-second response times
• Medium = is data accessed most of the time, but where response times can be anywhere from 1 second to 10 or 15 seconds
• Lukewarm Data = data that is accessed rarely; rarely may be (for example) once every 30 minutes or twice every 4 hours. 
• Cold Data = historical context that is hardly ever accessed, but when requested, must have a response time equal to that of a couple minutes

What's really interesting about these ratings is that they can serve as a guide to proper data placement, and hence can inform how one should use data virtualization. 

If you have data that's Hot, it should either be cached, or the application should hit the source directly.  If you have data that is Medium, then it need not be cached, since query federation can easily hit these time frames.  Likewise with Lukewarm data.  Cold Data might even be put off to tape or cheap storage with a low query priority and a never-cache setting.

As Dan points out, definitions will vary by company (and maybe even within companies), but the framework can be universally applied.  We'll continue to dig into this concept and show how it could work in practice.  Think about it, and I'm sure you'll warm up to the idea.