Four Ways Database Virtualization Makes Code Conversion Obsolete

This is part of Solutions Review’s Premium Content Series, a collection of contributed columns written by industry experts in maturing software categories. In this submission, Datometry Founder and CEO Mike Waas offers four ways database virtualization makes code conversion obsolete.

IT leaders all over the world are currently looking to replace their legacy data warehouses. Cloud databases are promising to roll up the field in the next few years in a way we haven’t seen before. However, there’s a little wrinkle: truly replacing one of these old systems requires a full-blown migration, which is one of the most notorious operations in all of IT.

Over the past years, code conversion tools have seen renewed interest. Code conversion tools translate the SQL of one system to the SQL dialect of another. In theory, this will automate a big part of the migration. The idea has been around for as long as there have been databases but has been of limited success in the past.

Database virtualization (DBV), in contrast, pursues an entirely different angle. Instead of translating static snippets of code, a DBV system works in real-time. Sitting in line, between database and application, it translates queries and data on the fly. It requires no knowledge of the applications, their location, or the complexity of their code.

How do the two methods compare? In this article we look at four critical areas and how DBV overcomes the challenges of code conversion.

Simplicty of Deployment

Code conversion needs to be applied to each individual SQL query, no matter where this code “lives”. This includes scripts, third-party applications, entire ETL pipelines, reports, and analytics. Typically, existing SQL may be scattered over a large surface across the entire enterprise.

Tracking the code down is already a non-trivial problem. But extracting, feeding it through code conversion, and re-inserting it requires significant effort. Moreover, often changes to the surrounding application code are needed too. And then, all these modified applications need to be re-deployed across the company.

In contrast, DBV leaves all applications intact. The exact location of applications is immaterial. So is the source code of the applications. Some might be written using modern programming languages, others might be legacy code for which the source is not even available anymore. Because DBV is “outside” the application, it is truly agnostic and can support just about any application.

Scalability of Migration

Code conversion needs to get applied to every piece of SQL. The effort to do so grows linearly with the number of applications. Even in cases where code conversion can output the perfect target SQL (more on its limitations below) the effort to process every application is quite considerable.

DBV in contrast is a central platform, deployed in a few central places, with redundant instances for high availability and fault tolerance. The number of moving parts is minimal. And as we’ve seen above, DBV is independent of the actual application that use it. This applies to both the kind of application but also the number of applications and users.

Correctness and Validation

Hardly any subject area gets as much scrutiny as correctness when it comes to query processing. Because code conversion alters the application, it creates room for error for the operators. Often, the SQL code that is to be re-insert after the translation requires further changes to the surrounding code which increases the risk even further.

With DBV, by eliminating the need for changes to the application much of this risk is eliminated too. But there is more. Defects may affect the translation of SQL in either methodology. However, with DBV the defect is localized to the actual software product. Deploying a fix to the central DBV instances solves the problem for all applications. There is no need to revisit individual applications to correct the problem.

Limitations and Expressiveness

This brings us to perhaps the most important difference between the two approaches: the limitations as to what type of SQL code either of them can process.

Code conversion is great at translating SQL code for which there exists an equivalent set of features in the new destination system. Typical examples for this kind of translation include differences in keywords and naming conventions. However, code conversion falls flat when there are non-trivial semantic differences between the systems. This limits code conversion in practice to anywhere between 60-70% of the overall SQL code that needs to be process. The remaining code needs to be rewritten, and often even rearchitected.

The situation is quite different with DBV. Because it receives SQL statements in real-time it can emulate dynamic elements like stored procedures, macros, or recursive queries even if the destination system does not support those natively. Theoretically, DBV has no functional limits in what it can support. Practically, however, the range of functionality needs to be traded off against the overhead an emulation would incur.