JumalaSika ltd - Fotolia
It's a programming nightmare when developers have to share a database. One developer makes a change in data, and another developer thousands of miles away stays up all night trying to figure out why
One developer changing shared data always creates problems for other developers. I know -- I've been one of those developers, and I've had those late nights. I've also learned from my mistakes and learned the value of database virtualization.
These days, when I'm coding, I require a personal copy of the databases my code will use. When I'm through with the databases, I notify the company's database administrator to delete the instances that are no longer needed. That's the good news. The bad news is I've sinned. To be honest, I have no idea how many zombie databases I've left behind in the past.
I'm not the only one who has created zombie databases. There are still a lot of developers out there who get a copy of a database, do some work, and then leave the DB up and running, maybe for eternity. They don't intend it, but they do. Given that an industrial-strength database can be terabytes in size, that's a lot of dead disk space littering around the IT landscape. And it's like throwing money in the street. A dormant database uses storage that should be allocated to productive use.
So, what's to be done? The answer is database virtualization.
Database virtualization in practice
As the name implies, a virtual database is a representation of a concrete database. Database virtualization gives each developer a distinct copy of a given database without creating an unnecessary storage burden. A virtual database is not a byte-by-byte copy of the source database.
Rather, the way a virtual database (see callout 1) works is it interacts with the source database for reading purpose only (see callout 2). When a developer attempts to alter the state of the database by writing or deleting data, that change delta is stored separately, dedicated to the virtual database instance (see callout 3). Then, the virtual database -- realizing a state change is in force -- will work from the delta data instead of the original data when appropriate.
The benefit of database virtualization is each developer is storing only the delta changes against the original data. In most cases, the delta data will take up significantly less disk space than a full-fledged copy. Also, because each developer isn't actually copying files to instantiate the virtual database, they can have their own copy of working data in minutes, rather than the hours it can take to copy over large databases.
In addition to saving time, database virtualization reduces network traffic. It takes a mass transfer of bytes over the wire to get a full copy of a database. When you eliminate the need for a copy, you eliminate that network traffic.
Database virtualization and DevOps
Database virtualization brings together two essential facets of the DevOps sensibility: speed and versatility. Modern DevOps is about being able to pivot at near-instantaneous speeds. Typically, database provisioning blocks work from flowing down the continuous delivery pipeline quickly. By nature, database administration is sensitive and time-consuming. As mentioned above, spinning up a database with standard techniques can take hours, if not days.
Organizations must also consider the administration overhead in terms of resource allocation and security concerns. The days spent getting a developer up and running on a full database copy can turn a two-week sprint into a one-month undertaking. The fast, efficient provisioning database virtualization provides is key to a well-functioning DevOps organization.
What about ROI?
Database virtualization saves money. Delphix, a purveyor of database virtualization technology in Redwood City, Calif., reported some customers are reducing database deployment times by as much as 80%. Actifio, based in Waltham, Mass., applies its data virtualization technology to system backup. The company reported it helped a Defense Department agency reduce back storage requirements by 50% and cut down backup time from eight to 10 hours to minutes, according to an Actifio case study.
More companies are jumping on board database virtualization -- not only to alleviate replication
This is the future
We're going to see a lot more database virtualization bend over the horizon. Right now, just keeping developers from bumping into each other when they write data-intensive code is a big win. There will be more benefits down the line, particularly in terms of security. Just as database virtualization gives a developer data on an as-needed basis, organizations can use the technology to give end users only the data they need and in a way that masks the schemas and configurations in the source database.
Real-time data masking is a big deal. Other uses will surely emerge. The important thing to remember is database virtualization brings a degree of flexibility, safety and cost saving to DevOps in general and development using databases, in particular. And many more developers might get to bed a lot earlier.