In our previous post of “DBcloudbin for dummies“, we described the basics of how an enterprise application infrastructure is architected. Now, it is time to go slightly deeper on how DBcloudbin helps to solve some of the challenges.
“Let’s talk about costs“. IT infrastructure is expensive regardless of whether it is deployed on-premises or ‘rented’ as a Cloud service. Database infrastructure is at the top level of expenditures, due to its special criticality, requirements of performance and some level of lack of competency (there is a tendency of packaging all the database software and hardware in an appliance provided by the same manufacturer in a market where the alternatives are very few; Oracle controls the vast majority of the high and mid Enterprise market and moving from one database technology to other is very challenging). When we are talking about critical infrastructure, it is required to be at least replicated, so let’s multiply everything by two (or more, since replicating data sums up additional costs).
Designing and developing applications is also expensive, requires specialized human resources with relevant wages and those scarce resources are normally invested on adding new functionality in the company LoB applications for improving our business. Those applications are architected to store data in databases and use the common database interface language (SQL) for accessing it. If this data is simple data (a string with your name and personal details for instance) it consumes not that much space. But it that data includes a high-resolution picture of yourself, it may consume as much space as thousands of ‘simple data’ records. Why store it at the database? Well, it is simpler and easier from an software engineering perspective. There may be many technical reasons for it. So, many applications are designed that way, storing what we call BLOBs (Binary Large Objects) at the database.
When the application keeps collecting data in its normal use, database tends to grow. After some time, the database size can be several terabytes. If we analyze the data, most of this size is occupied by those BLOBs (and in many cases the data is historical, not frequently accessed, but we need to keep it, and protect it). This generates high expenditures in infrastructure, backup and maintenance. However, fixing the problem is not that easy. We cannot just delete that data, of course. We may try to move it somewhere else, but we would break our application logic. The application SQL sentences would not be able to access that data and we would need to re-engineer the application. Can we? In many cases we cannot (cost, resources, skills, risk, ….)
This is where DBcloudbin comes to solve it! We automatically inspect the application data model in the database and generate what we call a ‘transparency layer’ (it is a data virtualization layer). This is a thin layer in the database that has the interesting property that is able to solve the same SQL queries that the original data model of our application, with the same semantic. So, if we reconfigure our application for using the transparency layer (this is a very basic application setting change), it will work the same way as before.
The important difference is that after this, we can freely move that BLOB data to an external object storage (either Cloud or on-premise) and the application will still be able to access it exactly as before, using the same SQL query. So, the data is out, no longer exploding our database, but from a business user perspective there is no change at all. Same application, same access, some operations. In addition, we handle the extracted data in a way that it can be replicated, versioned and protected with no need for executing recurring backup jobs on the externalized data. So, since our database will shrink, our backups will do as well. Smaller backups is much less cost (in backup infrastructure) and time for executing it. Even more important, if we have a crash in our database, restoring is also faster.