Delphix CEO: Why database virtualization matters

Creating a copy of a core database is typically a painful job. The CEO of Delphix, a database virtualization startup, claims it doesn't have to be that way

Page 2 of 6

Knorr: So you're not talking about scaling for a production environment; you're talking about offline copies that you want to keep coherent with the production environment, right?

Yueh: Exactly. There's a "more data" problem in that daily lifecycle maintenance, a 10-times expansion that people don't realize they've been burdened with for a long time. And when you look at the workflows around creating these copies and refreshing them for the four or five projects that are constantly running in parallel through these enterprises, you see that there is a huge problem in the op ex component, a huge IT complexity.

For example, with VMware, you can stand up a virtual machine in a couple minutes. But if you go into an enterprise and ask, "How long does it take you to refresh a database or stand up a new database for any development environment?" usually that will take, say, four teams over four weeks.

So what we did as a company is we virtualized the data tier for databases. And a database really has two pieces. You've got the server component (where the executables run) and the data files themselves. We virtualize the data files themselves so that you can consolidate these 10 copies into about half the space of one, while they all appear like 10 full copies. You can refresh or provision new data environments in as little as three clicks through the self-service model.

It's kind of like extending virtualization. The virtualization journey began at the CPU tier. But then businesses, as they roll out these private clouds, ask themselves: "How do I deal with where the real spending complexity is in my environment? My Oracle database is sitting on HP-UX, Solaris, or AIX, because those things aren't moving any time soon." So they only get partway on the virtualization journey because of the legacy environments and all the data -- the mission-critical data in relational databases.

With our product, you drop our virtual client onto VMware or onto some x86 server, we connect to the legacy environment, and suddenly we can create n number of virtual copies of these databases that you can use for all these purposes, but they're all consolidated and they're all automated through software.

Knorr: So could you use them for other production purposes as well?

Yueh: Yeah, absolutely. Boeing Credit Union, for example ... runs its ATM transaction reports from Delphix instead of from production. So what used to be a production workload has now been moved onto a virtual workload. In some ways, that use case is scale-out for the production environment because we now have a shadow environment that's staying in lockstep that you can give different kinds of workloads to.

Knorr: Right. You wouldn't want to do something heavy duty on the same copy and just bring everything to a crawl.

Yueh: Exactly. Nobody can get their money out of the ATM. It would be one of those disaster cases.

There are a couple of big industry trends. The growth of applications and the dependence on applications that drive efficiency for businesses is on a northbound track. It's kind of inescapable and unavoidable. Businesses are grappling with the fact that they have to bend around social media marketing or embrace self-service and private cloud deployment. All of those projects eventually have to touch the data in your ERP, CRM, or Salesforce systems, which are all still on relational databases in most of the big companies in the world. So we just help complete part of that journey by virtualizing the data tier.

| 1 2 3 4 5 6 Page 2